Estoy ejecutando una aplicación Sinatra detrás de pasajeros / nginx. Estoy tratando de que responda a las llamadas http y https. El problema es que cuando ambos están definidos en el bloque del servidor, las llamadas https se responden normalmente, pero http produce un error de 400 "La solicitud HTTP simple se envió al puerto HTTPS". Esto es para una página estática, así que supongo que Sinatra no tiene nada que ver con esto. ¿Alguna idea sobre cómo solucionar este problema?
Aquí está el bloque del servidor:
server {
listen 80;
listen 443 ssl;
server_name localhost;
root /home/myhome/app/public;
passenger_enabled on;
ssl on;
ssl_certificate /opt/nginx/ssl_keys/ssl.crt;
ssl_certificate_key /opt/nginx/ssl_keys/ssl.key;
ssl_protocols SSLv3 TLSv1;
ssl_ciphers HIGH:!aNULL:!MD5;
location /static {
root /home/myhome/app/public;
index index.html index.htm index.php;
}
error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
error_page 500 /500.html;
access_log /home/myhome/app/logs/access.log;
error_log /home/myhome/app/logs/error.log;
}
my.example.com:443
no funcionó. Cambiar eso en cambio ahttps://my.example.com
funcionó. Extraño, nunca tuve este problema con apache.ssl on;
le dice a NGINX que sirva CUALQUIER contenido a través de SSL. Utilice el indicador "ssl" al final de su,listen 443;
por ejemplo,listen 443 ssl;
si su servidor entrega tráfico tanto http como https, y elimine lassl on;
directiva.Respuestas:
Me encontré con un problema similar. Funciona en un servidor y no en otro servidor con la misma configuración de Nginx. Encontré la solución que Igor responde aquí http://forum.nginx.org/read.php?2,1612,1627#msg-1627
Si. O puede combinar servidores SSL / no SSL en un servidor:
fuente
ssl off;
ssl on;
(no es necesario agregar ssl off). Además, como no recuerdo qué versión de Nginx, ya no es necesario usarladefault
enlisten 443
línea. Entonces, la configuración de OP estaba bien, solo es necesario eliminarlassl on
y debería funcionar.ssl on
? La respuesta de @ MichaelJ.Evans a continuación es una solución mucho mejor.Las respuestas anteriores son incorrectas en el sentido de que la mayoría anula la prueba "es esta conexión HTTPS" para permitir el servicio de las páginas a través de http independientemente de la seguridad de la conexión.
La respuesta segura usando una página de error en un código de error http 4xx específico de NGINX para redirigir al cliente a reintentar la misma solicitud a https. (como se describe aquí /server/338700/redirect-http-mydomain-com12345-to-https-mydomain-com12345-in-nginx )
El OP debe usar:
fuente
nginx['custom_gitlab_server_config'] = "error_page 497 https://$host:$server_port$request_uri;"
funcionóEl error lo dice todo en realidad. Su configuración le dice a Nginx que escuche en el puerto 80 (HTTP) y use SSL. Cuando apunta su navegador
http://localhost
, intenta conectarse a través de HTTP. Dado que Nginx espera SSL, se queja del error.La solución alternativa es muy sencilla. Necesitas dos
server
secciones:fuente
Tuve exactamente el mismo problema, tengo la misma configuración que su ejemplo y lo hice funcionar eliminando la línea:
ssl on;
Para citar el doc:
fuente
Según el artículo de wikipedia sobre códigos de estado . Nginx tiene un código de error personalizado cuando se envía tráfico http al puerto https (código de error 497)
Y de acuerdo con nginx docs en error_page , puede definir un URI que se mostrará para un error específico.
Por lo tanto, podemos crear una uri a la que se enviarán los clientes cuando se genere el código de error 497.
nginx.conf
Sin embargo, si un cliente realiza una solicitud a través de cualquier otro método que no sea GET, esa solicitud se convertirá en un GET. Por lo tanto, para preservar el método de solicitud por el que entró el cliente; usamos redirecciones de procesamiento de errores como se muestra en los documentos de nginx en error_page
Y es por eso que usamos la
301 =307
redirección.Usando el archivo nginx.conf que se muestra aquí, podemos hacer que http y https escuchen en el mismo puerto
fuente
Aquí hay un ejemplo para configurar HTTP y HTTPS en el mismo bloque de configuración con soporte para ipv6 . La configuración se prueba en Ubuntu Server y NGINX / 1.4.6, pero debería funcionar con todos los servidores.
No incluya lo
ssl on
que pueda causar un400
error. La configuración anterior debería funcionar para¡Espero que esto ayude!
fuente
si usa phpmyadmin agregue: fastcgi_param HTTPS activado;
fuente
De hecho, puedes hacer esto con:
Esto resolvió mi problema al usar nginxvhosts; ahora puedo usar SSL y HTTP simple. Funciona incluso con puertos combinados.
fuente