nginx 502 «Bad Gateway» errores cuando se establece como un proxy sobre SSL/HTTPS

Un pequeño experimento ha demostrado que para mi uso, nginx es un gran proxy de cacheo. Tan bueno que me pregunté qué pasaría si empezara a encadenar los servidores (proxy A —> proxy B —> servidor nginx C, todo sobre HTTPS/SSL).

La respuesta fue… 502 Errores de Gateway malos (502 Bad Gateway).

Lo configuré y luego usé Integrity by PeacockMedia (gratis/donationware en la Mac App Store) para probar el sitio. Si no has oído hablar de él antes, Integrity es algo así como un verificador de enlaces rotos para MacOS, rápido y muy fácil de usar. De todos modos… inmediatamente arrojó un montón de errores 502 para las versiones HTTPS del sitio.

Lo comprobé tratando de cargar manualmente una página a través de HTTPS en un navegador web, y por supuesto, error 502.

——

Resultó que mi problema era que acababa de cambiar de un simple proxy_pass https://123.45.67.89; en la ubicación a todo el asunto del «upstream backend», con algo como esto:

upstream backend {
     server 123.45.67.89;
     server 12.34.56.789 backup;
}
server {
     listen 443;
     server_name example.com;
     location / {
         proxy_pass https://backend;
     }
}
 

Eso no funciona del todo, y la razón resultó ser que hay que especificar el puerto en la sección «upstream backend» si no es el puerto 80. No es suficiente que la línea proxy_pass empezara con https – también tuve que decirle explícitamente que usara el puerto 443.

Así que la versión de trabajo era, por supuesto, la siguiente:

upstream backend-ssl {
     server 123.45.67.89:443;
     server 12.34.56.789:443 backup;
}
server {
     listen 443;
     server_name example.com;
     location / {
         proxy_pass https://backend-ssl;
     }
}
 

Eso no quiere decir que sea la única causa de los 502 errores cuando se trata del proxy de cacheo de nginx (los tiempos muertos son otra causa común por lo que entiendo).

Pero si acabas de implementar el bit upstream, vale la pena comprobar si tienes el mismo problema.

Si no, vale la pena echar un vistazo a tu registro de errores para ayudar a reducir las cosas. Normalmente se encuentra en el directorio de registros: si usas Ubuntu /var/log/nginx/error.log es donde suele estar.

6 Comentarios | Diga un comentario

  1. ishwar en octubre 1, 2014 - haga clic aquí para responder
    Gracias, tuve el problema exacto.
  2. Acabas de salvarme la vida.
  3. Faruk en noviembre 20, 2019 - haga clic aquí para responder
    ¡Muchas gracias! Me ha ahorrado mucho tiempo.
  4. Jason en abril 13, 2020 - haga clic aquí para responder
    ¡Muchas gracias! Muy útil.
  5. dinesh kannan en septiembre 1, 2020 - haga clic aquí para responder
    Funciona, hombre, gracias.
  6. Yu-Cheng,Chen en noviembre 1, 2021 - haga clic aquí para responder
    He pasado mucho tiempo probando otros métodos, pero ninguno ha funcionado. ¡muchas gracias!

Diga un comentario

Puedes usar un alias y un correo electrónico falso. Sin embargo, si eliges usar un correo electrónico real, se admiten los "gravatars". Lee la política de privacidad para más detalles.