ssl - redireccionar - ¿Cómo redirecciono las solicitudes https:// a http:// en NGINX?

redireccionar http a https nginx

Question

¿Hay alguna manera de redirigir las solicitudes https: // a http: // agregando una regla en el archivo vhost del dominio? Estoy usando NGINX.

Answer 1

¿Por qué es algo así útil? A primera vista, no estaba seguro de si podría hacerse. Pero presentó una pregunta interesante.

Puede tratar de poner una declaración de redirección en su archivo de configuración y reiniciar su servidor. Dos posibilidades pueden suceder:

1. El servidor emitirá la redirección, lo que parezca querer.
2. El servidor primero hará el intercambio https, y ENTONCES emitirá la redirección, en cuyo caso, ¿cuál es el punto?

Agregaré más si encuentro algo más concreto.

ACTUALIZACIÓN: (un par de horas más tarde) Puede intentar esto. Debe poner esto en su archivo nginx.conf -

server {
       listen 443;
       server_name _ *;
       rewrite ^(.*) http://$host$1 permanent;
 }

Envía una redirección permanente al cliente. Supongo que está utilizando el puerto 443 (predeterminado) para https.

server {
    listen      80;
    server_name _ *;
    ...
}

Agregue esto para que sus peticiones HTTP normales en el puerto 80 no se alteren.

ACTUALIZACIÓN: 18 de diciembre de 2016 - server_name _ debe usarse en lugar de server_name _ * en versiones de nginx> 0.6.25 (gracias a @Luca Steeb)

Answer 2

Esto me ayudó:

server {
    listen 443;
    server_name server.org www.server.org;
    rewrite ^ http://$server_name$request_uri? permanent;
}

Answer 3

La única regla simple ya se explica en la publicación que está sobre mí:

server {
    listen ip:443;
    server_name www.example.com;
    rewrite ^(.*) http://$host$1 permanent;
}

Answer 4

esta pregunta se habría adaptado mejor al sitio serverfault.com.

Una mejor forma de hacer el redireccionamiento a http:

server {
   listen 443;
   return 301 http://$host$request_uri;
}

Esto evita tanto la cláusula ''si'' como la expresión regular en la reescritura que son características de las otras soluciones hasta la fecha. Ambos tienen implicaciones de rendimiento, aunque en la práctica tendrías que tener bastante tráfico antes de que importara.

Dependiendo de su configuración, es probable que también desee especificar una IP en la cláusula de escucha, y tal vez una cláusula de nombre de servidor en el cuadro anterior. Como es, se aplicará a todas las solicitudes del puerto 443 para todos los nombres de dominio. Por lo general, desea una IP por dominio con https, por lo que vincular lo anterior a una IP es más importante que vincularlo a un nombre de dominio, pero hay variaciones en eso, por ejemplo, donde todos los dominios son subdominios de un dominio.

EDITAR: TLS está cerca del universal ahora, y con él Identificación del nombre del servidor (SNI) que permite sitios HTTPS en múltiples dominios que comparten una sola IP. Hay una buena reseña here

Answer 5

rewrite y if debe evitarse con Nginx. La famosa línea es "Nginx no es Apache": en otras palabras, Nginx tiene mejores formas de manejar URL que reescribir. return sigue siendo técnicamente parte del módulo de reescritura, pero no lleva la sobrecarga de la rewrite , y no está tan cargado de advertencias como if .

Nginx tiene una página completa sobre por qué if es "malo" . También proporciona una página constructiva que explica por qué rewrite y if son malas y cómo puede evitarlo. Esto es lo que la página tiene que decir con respecto a rewrite y if :

Esta es una forma incorrecta, engorrosa e ineficaz.

Puede resolver este problema correctamente usando return :

server {
    listen 443 ssl;

    # You will need a wildcard certificate if you want to specify multiple
    # hostnames here.
    server_name domain.example www.domain.example;

    # If you have a certificate that is shared among several servers, you
    # can move these outside the `server` block.
    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/cert.key;

    # 301          indicates a permanent redirect.  If your redirect is
    #              temporary, you can change it to 302 or omit the number
    #              altogether.
    # $http_host   is the hostname and, if applicable, port--unlike $host,
    #              which will break on non-standard ports
    # $request_uri is the raw URI requested by the client, including any
    #              querystring
    return 301 http://$http_host$request_uri;
}

Si espera una gran cantidad de bots que no envían un encabezado Host , puede usar $host lugar de $http_host , siempre y cuando se adhiera a los puertos 80 y 443. De lo contrario, deberá llenar dinámicamente un sustituto $http_host . Este código es eficiente y seguro siempre que aparezca en la raíz del server (en lugar de en un bloque de location ), a pesar de usar if . Sin embargo, necesitaría usar un servidor predeterminado para que esto sea aplicable, lo que debería evitarse con https.

set $request_host $server_name:$server_port;
if ($http_host) {
    set $request_host $http_host;
}

Si desea aplicar SSL / TLS para rutas específicas, pero prohíba lo contrario:

server {
    listen 443 ssl;
    server_name domain.example;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/cert.key;

    location / {
        return 301 http://$host$request_uri;
    }

    location /secure/ {
        try_files $uri =404;
    }
}

server {
    listen 80;
    server_name domain.example;

    location / {
        try_files $uri =404;
    }

    location /secure/ {
        return 301 https://$http_host$request_uri;
    }
}

Si su servidor no está en comunicación directa con el cliente, por ejemplo, si usa CloudFlare, las cosas se complican un poco. Deberá asegurarse de que cualquier servidor en comunicación directa con el cliente agregue un encabezado X-Forwarded-Proto apropiado a la solicitud.

Usar esto es una proposición desordenada; para una explicación completa, vea IfIsEvil . Para que esto sea útil, el bloque if no puede estar dentro de un bloque de location , por una variedad de razones complejas. Esto fuerza el uso de la rewrite para la prueba de URI. En resumen, si tiene que usar esto en un servidor de producción ... no lo haga. Piénselo de esta manera: si ha superado a Apache, ha superado esta solución.

/ secure, / secure /, y todo en / secure / hará cumplir https, mientras que todos los demás URI harán cumplir http. El constructo (?! ) PCRE es una afirmación de búsqueda anticipada negativa . (?: ) es un grupo no capturante .

server {
    # If you''re using https between servers, you''ll need to modify the listen
    # block and ensure that proper ssl_* statements are either present or
    # inherited.
    listen 80;
    server_name domain.example;

    if ($http_x_forwarded_proto = https) {
        rewrite ^(?!/secure)/ http://$http_host$request_uri? permanent;
    }
    if ($http_x_forwarded_proto != https) {
        rewrite ^/secure(?:/|$) https://$http_host$request_uri? permanent;
    }
}

Answer 6

location / {
    if ($scheme = https) {
        rewrite ^(.*)? http://$http_host$1 permanent;
    }
}