Estoy usando nginx en la nube de Rackspace después de un tutorial y después de haber buscado en la red y hasta ahora no puedo solucionar esto.

Quiero que www.mysite.com vaya a mysite.com de manera normal en .htaccess por SEO y otras razones.

Mi /etc/nginx/sites-available/www.example.com.vhost config:

server {
       listen 80;
       server_name www.example.com example.com;
       root /var/www/www.example.com/web;

       if ($http_host != "www.example.com") {
                 rewrite ^ http://example.com$request_uri permanent;
       }

También he intentado

server {
       listen 80;
       server_name example.com;
       root /var/www/www.example.com/web;

       if ($http_host != "www.example.com") {
                 rewrite ^ http://example.com$request_uri permanent;
       }

También lo intenté. Tanto los segundos intentos dan errores de bucle de redireccionamiento.

if ($host = 'www.example.com' ) {
rewrite ^ http://example.com$uri permanent;
}

Mi DNS está configurado de forma estándar:

site.com 192.192.6.8 A type at 300 seconds
www.site.com 192.192.6.8 A type at 300 seconds

(las IP y carpetas de ejemplo se han utilizado como ejemplos y para ayudar a las personas en el futuro). Yo uso Ubuntu 11.

Solución HTTP

De la documentación , "la forma correcta es definir un servidor separado para example.org":

server {
    listen       80;
    server_name  example.com;
    return       301 http://www.example.com$request_uri;
}

server {
    listen       80;
    server_name  www.example.com;
    ...
}

Solución HTTPS

Para aquellos que desean una solución que incluya https://...

server {
        listen 80;
        server_name www.domain.com;
        # $scheme will get the http protocol
        # and 301 is best practice for tablet, phone, desktop and seo
        return 301 $scheme://domain.com$request_uri;
}

server {
        listen 80;
        server_name domain.com;
        # here goes the rest of your config file
        # example 
        location / {

            rewrite ^/cp/login?$ /cp/login.php last;
            # etc etc...

        }
}

Nota: Originalmente no lo he incluido https://en mi solución ya que usamos balanceadores de carga y nuestro servidor https: // es un servidor de pago SSL de alto tráfico: no mezclamos https: // y http: //.

Para verificar la versión nginx, use nginx -v.

Eliminar www de url con redireccionamiento nginx

server {
    server_name  www.domain.com;
    rewrite ^(.*) http://domain.com$1 permanent;
}

server {
    server_name  domain.com;
    #The rest of your configuration goes here#
}

Por lo tanto, debe tener DOS códigos de servidor.

Agregue el www a la url con nginx redirect

Si lo que necesita es lo contrario, para redirigir de domain.com a www.domain.com, puede usar esto:

server {
    server_name  domain.com;
    rewrite ^(.*) http://www.domain.com$1 permanent;
}

server {
    server_name  www.domain.com;
    #The rest of your configuration goes here#
}

Como puede imaginar, esto es todo lo contrario y funciona de la misma manera que el primer ejemplo. De esta manera, no obtienes marcas de SEO, ya que es una redirección y movimiento permanente. ¡No se fuerza WWW y se muestra el directorio!

Algunos de mis códigos se muestran a continuación para una mejor vista:

server {
    server_name  www.google.com;
    rewrite ^(.*) http://google.com$1 permanent;
}
server {
       listen 80;
       server_name google.com;
       index index.php index.html;
       ####
       # now pull the site from one directory #
       root /var/www/www.google.com/web;
       # done #
       location = /favicon.ico {
                log_not_found off;
                access_log off;
       }
}

En realidad, ni siquiera necesitas una reescritura.

server {
    #listen 80 is default
    server_name www.example.com;
    return 301 $scheme://example.com$request_uri;
}

server {
    #listen 80 is default
    server_name example.com;
    ## here goes the rest of your conf...
}

Como mi respuesta es obtener más y más votos, pero también lo anterior. Nunca debe usar a rewriteen este contexto. ¿Por qué? Porque nginx tiene que procesar e iniciar una búsqueda. Si usa return(que debería estar disponible en cualquier versión nginx), detiene directamente la ejecución. Esto se prefiere en cualquier contexto.

Redireccione ambos, no SSL y SSL a su contraparte no www:

server {
    listen               80;
    listen               443 ssl;
    server_name          www.example.com;
    ssl_certificate      path/to/cert;
    ssl_certificate_key  path/to/key;

    return 301 $scheme://example.com$request_uri;
}

server {
    listen               80;
    listen               443 ssl;
    server_name          example.com;
    ssl_certificate      path/to/cert;
    ssl_certificate_key  path/to/key;

    # rest goes here...
}

La $schemevariable solo contendrá httpsi su servidor solo está escuchando en el puerto 80 (predeterminado) y la opción de escuchar no contiene la sslpalabra clave. No usar la variable no te dará ningún rendimiento.

Tenga en cuenta que necesita incluso más bloques de servidor si usa HSTS, porque los encabezados HSTS no deben enviarse a través de conexiones no cifradas. Por lo tanto, necesita bloques de servidor sin cifrar con redireccionamientos y bloques de servidor cifrados con redireccionamientos y encabezados HSTS.

Redireccionar todo a SSL (configuración personal en UNIX con IPv4, IPv6, SPDY, ...):

#
# Redirect all www to non-www
#
server {
    server_name          www.example.com;
    ssl_certificate      ssl/example.com/crt;
    ssl_certificate_key  ssl/example.com/key;
    listen               *:80;
    listen               *:443 ssl spdy;
    listen               [::]:80 ipv6only=on;
    listen               [::]:443 ssl spdy ipv6only=on;

    return 301 https://example.com$request_uri;
}

#
# Redirect all non-encrypted to encrypted
#
server {
    server_name          example.com;
    listen               *:80;
    listen               [::]:80;

    return 301 https://example.com$request_uri;
}

#
# There we go!
#
server {
    server_name          example.com;
    ssl_certificate      ssl/example.com/crt;
    ssl_certificate_key  ssl/example.com/key;
    listen               *:443 ssl spdy;
    listen               [::]:443 ssl spdy;

    # rest goes here...
}

Supongo que puedes imaginar otros compuestos con este patrón ahora solo.

¿Más de mis configuraciones? Ve aquí y aquí .

Puede descubrir que desea utilizar la misma configuración para más dominios.

El siguiente fragmento elimina www antes de cualquier dominio:

if ($host ~* ^www\.(.*)$) {
    rewrite / $scheme://$1 permanent;
}

Necesita dos bloques de servidor.

Póngalos en su archivo de configuración, por ejemplo /etc/nginx/sites-available/sitename

Digamos que decide tener http://example.com como la dirección principal para usar.

Su archivo de configuración debería verse así:

server {
        listen 80;
        listen [::]:80;
        server_name www.example.com;
        return 301 $scheme://example.com$request_uri;
}
server {
        listen 80;
        listen [::]:80;
        server_name example.com;

        # this is the main server block
        # insert ALL other config or settings in this server block
}

El primer bloque de servidor contendrá las instrucciones para redirigir cualquier solicitud con el prefijo 'www'. Escucha las solicitudes de la URL con el prefijo 'www' y redirige.

No hace nada más.

El segundo bloque de servidor contendrá su dirección principal, la URL que desea usar. Todos los demás ajustes van aquí como root, index, location, etc. Compruebe el archivo por defecto para estos otros ajustes se pueden incluir en el bloque de servidor.

El servidor necesita dos registros DNS A.

Name: @ IPAddress: your-ip-address (for the example.com URL)

Name: www IPAddress: your-ip-address (for the www.example.com URL)

Para ipv6, cree el par de registros AAAA usando su dirección-ipv6.

Aquí se explica cómo hacerlo para varios nombres de servidor de www a no-www (lo usé para subdominios):

server {
        server_name 
             "~^www\.(sub1.example.com)$"
             "~^www\.(sub2.example.com)$"
             "~^www\.(sub3.example.com)$";
         return 301 $scheme://$1$request_uri ;
}

1. Mejor práctica: separado servercon código rígidoserver_name

La mejor práctica con nginx es usar un separado serverpara una redirección como esta (no compartida con la serverde su configuración principal), para codificar todo y no usar expresiones regulares en absoluto.

También puede ser necesario codificar los dominios si está usando HTTPS, ya que debe saber por adelantado qué certificados proporcionará.

server {
    server_name www.example.com;
    return  301 $scheme://example.com$request_uri;
}
server {
    server_name www.example.org;
    return  301 $scheme://example.org$request_uri;
}
server {
    server_name example.com example.org;
    # real configuration goes here
}

2. Usando expresiones regulares dentro server_name

Si tiene varios sitios y no le interesa el rendimiento máximo, pero desea que cada uno de ellos tenga la misma política con respecto al www.prefijo, puede usar expresiones regulares. La mejor práctica de usar un separado serveraún se mantendría.

Tenga en cuenta que esta solución se vuelve complicada si usa https, ya que debe tener un solo certificado para cubrir todos sus nombres de dominio si desea que esto funcione correctamente.

non- wwwto wwww / regex en un single dedicado serverpara todos los sitios:

server {
    server_name ~^(?!www\.)(?<domain>.+)$;
    return  301 $scheme://www.$domain$request_uri;
}

wwwa non- wwww / regex en un single dedicado serverpara todos los sitios:

server {
    server_name ~^www\.(?<domain>.+)$;
    return  301 $scheme://$domain$request_uri;
}

wwwa non- wwww / regex en un sitio dedicado solo serverpara algunos sitios:

Puede ser necesario restringir la expresión regular para cubrir sólo un par de dominios, entonces usted puede usar algo como esto para solo www.example.org, www.example.comy www.subdomain.example.net:

server {
    server_name ~^www\.(?<domain>(?:example\.org|example\.com|subdomain\.example\.net))$;
    return  301 $scheme://$domain$request_uri;
}

Prueba de expresiones regulares con nginx

Puede probar que la expresión regular funciona como se esperaba pcretesten su sistema, que es exactamente la misma pcrebiblioteca que su nginx usará para expresiones regulares:

% pcretest 
PCRE version 8.35 2014-04-04

  re> #^www\.(?<domain>(?:example\.org|example\.com|subdomain\.example\.net))$#
data> test
No match
data> www.example.org
 0: www.example.org
 1: example.org
data> www.test.example.org
No match
data> www.example.com
 0: www.example.com
 1: example.com
data> www.subdomain.example.net
 0: www.subdomain.example.net
 1: subdomain.example.net
data> subdomain.example.net
No match
data> www.subdomain.example.net.
No match
data> 

Tenga en cuenta que no tiene que preocuparse por los puntos finales o el caso, ya que nginx ya se encarga de eso, según el nombre del servidor nginx regex cuando el encabezado "Host" tiene un punto final .

3. Asperjar ifdentro de serverHTTPS existente :

Esta solución final generalmente no se considera la mejor práctica, sin embargo, todavía funciona y hace el trabajo.

De hecho, si está utilizando HTTPS, entonces esta solución final puede resultar más fácil de mantener, ya que no tendría que copiar y pegar un montón de directivas SSL entre las diferentes serverdefiniciones, y en su lugar podría colocar los fragmentos solo en los servidores necesarios, lo que facilita la depuración y el mantenimiento de sus sitios.

no wwwa www:

if ($host ~ ^(?!www\.)(?<domain>.+)$) {
    return  301 $scheme://www.$domain$request_uri;
}

wwwa no- www:

if ($host ~ ^www\.(?<domain>.+)$) {
    return  301 $scheme://$domain$request_uri;
}

codificar un solo dominio preferido

Si desea un poco más de rendimiento, así como la consistencia entre múltiples dominios que un solo serverpuede usar, aún podría tener sentido codificar explícitamente un solo dominio preferido:

if ($host != "example.com") {
    return  301 $scheme://example.com$request_uri;
}

Referencias

• http://nginx.org/r/server_name
• http://nginx.org/r/return
• http://nginx.org/en/docs/http/server_names.html

Esta solución proviene de mi experiencia personal. Utilizamos varios cubos de Amazon S3 y un servidor para redirigir non-wwwa wwwnombres de dominio para que coincidan con la política de encabezado "Host" de S3 .

Usé la siguiente configuración para el servidor nginx :

server {
    listen 80;
    server_name ~^(?!www\.)(?<domain>.+)$;
    return 301 $scheme://www.$domain$request_uri;
}

Esto coincide con todos los nombres de dominio apuntados al servidor comenzando con lo que sea pero www.y redirige a www.<domain>. De la misma manera, puede hacer una redirección opuesta de wwwa non-www.

Combiné la mejor de todas las respuestas simples, sin dominios codificados.

Redirección permanente 301 de no www a www (HTTP o HTTPS):

server {
    if ($host !~ ^www\.) {
        rewrite ^ $scheme://www.$host$request_uri permanent;
    }

    # Regular location configs...
}

Si prefiere no HTTPS, no www a HTTPS, redireccione www al mismo tiempo:

server {
    listen 80;

    if ($host !~ ^www\.) {
        rewrite ^ https://www.$host$request_uri permanent;
    }

    rewrite ^ https://$host$request_uri permanent;
}

Redirigir no www a www

Para dominio único:

server {
        server_name example.com;
        return 301 $scheme://www.example.com$request_uri;
}

Para todos los dominios:

server {
        server_name "~^(?!www\.).*" ;
        return 301 $scheme://www.$host$request_uri;
}

Redirigir www a no www Para dominio único:

server {
        server_name www.example.com;
        return 301 $scheme://example.com$request_uri;
}

Para todos los dominios:

server {
         server_name "~^www\.(.*)$" ;
         return 301 $scheme://$1$request_uri ;
}

prueba esto

    if ($host !~* ^www\.){
        rewrite ^(.*)$ https://www.yoursite.com$1;
    }

Otra forma: Nginx no-www a www

server {
  listen       80;
  server_name  yoursite.com;
  root /path/;
  index index.php;
  return       301 https://www.yoursite.com$request_uri;
}

y www a no-www

server {
  listen       80;
  server_name  www.yoursite.com;
  root /path/;
  index index.php;
  return       301 https://yoursite.com$request_uri;
}

Formato único:

server {
  listen 80;
  server_name "~^www\.(.*)$" ;
  return 301 https://$1$request_uri ;
}

location / { 
    if ($http_host !~ "^www.domain.com"){ 
        rewrite ^(.*)$ $scheme://www.domain.com/$1 redirect; 
    } 
}

No estoy seguro si alguien se da cuenta de que puede ser correcto devolver un 301, pero los navegadores se ahogan al hacerlo

rewrite ^(.*)$ https://yoursite.com$1; 

es más rápido que:

return 301 $scheme://yoursite.com$request_uri;

Blog fantasma

Para que el método recomendado de nginx return 301 $scheme://example.com$request_uri;funcione con Ghost, deberá agregar su bloque de servidor principal:

proxy_set_header    X-Real-IP           $remote_addr;
proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
proxy_set_header    Host                $http_host;
proxy_set_header    X-Forwarded-Proto   $scheme;
proxy_set_header    X-NginX-Proxy       true;

proxy_pass_header   X-CSRF-TOKEN;
proxy_buffering     off;
proxy_redirect      off;  

Si no desea codificar el nombre de dominio, puede usar este bloque de redireccionamiento. El dominio sin el www principal se guarda como variable $domainque se puede reutilizar en la instrucción de redireccionamiento.

server {
    ...
    # Redirect www to non-www
    if ( $host ~ ^www\.(?<domain>.+) ) {
       rewrite ^/(.*)$ $scheme://$domain/$1;
    }
}

REF: Redirigir un subdominio con una expresión regular en nginx

if ($host ~* ^www.example.com$) {
    return 301 $scheme://example.com$request_uri;
}

Si tiene problemas para que esto funcione, es posible que deba agregar la dirección IP de su servidor. Por ejemplo:

server {
listen XXX.XXX.XXX.XXX:80;
listen XXX.XXX.XXX.XXX:443 ssl;
ssl_certificate /var/www/example.com/web/ssl/example.com.crt;
ssl_certificate_key /var/www/example.com/web/ssl/example.com.key;
server_name www.example.com;
return 301 $scheme://example.com$request_uri;
}

donde XXX.XXX.XXX.XXX es la dirección IP (obviamente).

Nota: ssl crt y la ubicación de la clave se deben definir para redirigir correctamente las solicitudes https

No olvide reiniciar nginx después de realizar los cambios:

service nginx restart