Saltar al contenido
JS BRAND LAB

VPS · Problemas

Error 502 Bad Gateway en nginx: causas y cómo solucionarlo

Un 502 Bad Gateway significa que nginx está vivo pero no consigue una respuesta válida de la aplicación que hay detrás (Node, Django, PHP-FPM…). Casi siempre la aplicación está caída, se quedó sin memoria, escucha en otro puerto o no tiene permiso sobre el socket. Se resuelve mirando tres sitios, en este orden: el servicio, el registro de nginx y el recurso que falta (memoria o disco).

Actualizado el 2026-11-10 · Por Rómulo Felizola · Read in English

Paso 1: ¿está viva la aplicación?

systemctl status miapp
journalctl -u miapp -n 50 --no-pager
ss -ltnp | grep 3020
curl -I http://127.0.0.1:3020

Cambia miapp y 3020 por tu servicio y tu puerto. Si el curl a la aplicación directa también falla, el problema no es nginx: es la aplicación. Si responde bien, el fallo está entre nginx y ella (puerto equivocado, socket, permisos).

Paso 2: lee lo que dice nginx

tail -n 30 /var/log/nginx/error.log
nginx -t

Las frases clave: «connect() failed (111: Connection refused)» (nada escucha en ese puerto, la aplicación está caída), «No such file or directory» (la ruta del socket no existe) y «Permission denied» (nginx no puede abrir el socket).

Las causas que más vemos

  • La aplicación se cayó y nadie la reinició. Solución: ejecutarla como servicio de systemd con Restart=always.
  • Se quedó sin memoria. Mira dmesg | grep -i 'out of memory'. Si pasa a menudo, la solución es más RAM o un límite por servicio para que una sola aplicación no tumbe a las demás.
  • Despliegue a medias: se copiaron los archivos pero no se reinició el servicio, o el nuevo código no arranca. journalctl lo dice.
  • Puerto o socket distinto del que espera nginx tras cambiar la configuración.
  • Disco lleno: la aplicación no puede escribir y se cae. Mira VPS sin espacio en disco.

Cómo lo tenemos configurado nosotros

Cada aplicación de nuestro servidor es un servicio de systemd que se reinicia solo, con un tope de memoria, de modo que una aplicación que se desboca no se lleva por delante a las demás:

[Service]
User=miapp
WorkingDirectory=/srv/miapp
Environment="NODE_ENV=production"
Environment="PORT=3020"
Environment="HOSTNAME=127.0.0.1"
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=5
MemoryMax=400M
NoNewPrivileges=true

La aplicación escucha solo en 127.0.0.1 y nginx le hace de proxy. Con Restart=always, si el proceso muere vuelve a levantarse a los 5 segundos y el 502 dura lo que tarda en arrancar. El paso a paso completo del montaje está en cómo desplegar una web en un VPS con nginx.

Preguntas frecuentes

¿502 y 504 son lo mismo?

No. El 502 es una respuesta inválida o ninguna conexión con la aplicación; el 504 (Gateway Timeout) es que la aplicación tarda demasiado en responder. Se diagnostican igual, pero el 504 apunta más a una aplicación lenta o saturada que a una caída.

¿Reiniciar nginx lo arregla?

Casi nunca: nginx suele estar bien. Reinicia o arregla la aplicación. Antes de tocar nginx, ejecuta nginx -t para comprobar su configuración.

¿Puede ser un problema del proveedor?

Es raro. En nuestro caso, la caída de 17 horas de octubre fue por nuestro propio disco lleno, no por el proveedor. Descarta primero tu servidor.

Sigue leyendo