Error 502 Bad Gateway en Nginx: Causas y Soluciones

📅 Publicado el 15 de octubre, 2026 · Por Equipo RedServicio

El error 502 bad gateway nginx es de esos fallos que cualquier administrador web termina conociendo de cerca: tu sitio deja de cargar y el navegador escupe un «Bad Gateway» que no dice gran cosa si no sabes de dónde viene. Aquí vamos a ver qué significa, qué lo provoca normalmente y cómo diagnosticarlo paso a paso mirando los logs de Nginx y PHP-FPM. Con un poco de método, la web suele volver en minutos.

¿Qué es el error 502 Bad Gateway y por qué ocurre en Nginx?

El código de estado HTTP 502 Bad Gateway indica que Nginx, actuando como proxy o intermediario, recibió una respuesta inválida (o directamente ninguna) del backend al que intentó reenviar la petición. En la arquitectura típica de hosting, Nginx va delante como servidor web frontal y delega el trabajo dinámico en un backend, normalmente PHP-FPM. Aunque no siempre: puede ser Apache, Node.js, Gunicorn u otro servicio.

Dicho de otro modo: el problema casi nunca está en Nginx en sí. Está en la comunicación entre Nginx y ese proceso de backend. Si PHP-FPM está caído, saturado o tarda demasiado, Nginx se queda sin nada válido que devolver al navegador del visitante. Y ahí, el 502.

Cuidado con confundirlo con errores parecidos. El 504 Gateway Timeout significa que el backend tardó demasiado en contestar; el 500 es un error interno genérico del servidor. El 502, en cambio, apunta específicamente a una respuesta defectuosa o ausente del proceso intermedio.

Causas más comunes del error 502 Bad Gateway en Nginx

Entendido el concepto, lo que toca es averiguar cuál de estos escenarios aplica a tu servidor. Los más frecuentes:

• PHP-FPM detenido o bloqueado: el servicio se cayó o no arrancó tras un reinicio. Es la causa número uno en servidores con Nginx.
• Socket o puerto incorrecto en la configuración: Nginx intenta conectarse a un socket Unix (por ejemplo, /run/php/php8.2-fpm.sock) o a un puerto TCP (127.0.0.1:9000) que no coincide con el que realmente escucha PHP-FPM.
• Agotamiento de recursos: RAM insuficiente, límite de procesos pm.max_children alcanzado o CPU saturada. PHP-FPM acaba rechazando conexiones nuevas.
• Permisos del socket Unix: si el usuario de Nginx (habitualmente www-data) no puede leer o escribir en el socket, la comunicación falla aunque ambos servicios estén activos. Un detalle pequeño que da quebraderos de cabeza desproporcionados.
• Procesos zombis o memory leaks: aplicaciones con fugas de memoria terminan agotando los workers disponibles del backend.
• Actualizaciones recientes: cambias la versión de PHP y no actualizas el bloque location ~ \.php$ de Nginx, que sigue apuntando al socket de una versión antigua. Lo he visto más veces de las que debería.

Cómo diagnosticar el error 502: revisa los logs de Nginx y PHP-FPM

Antes de tocar configuración alguna, consulta los registros. Son, con diferencia, la fuente más fiable para saber qué está pasando exactamente.

Paso 1: revisa el error log de Nginx. Suele estar en /var/log/nginx/error.log. Puedes ver las últimas líneas en tiempo real con:

tail -f /var/log/nginx/error.log

Busca mensajes como «connect() failed (111: Connection refused) while connecting to upstream» (el backend no está escuchando) o «connect() failed (13: Permission denied)» (problema de permisos en el socket).

Paso 2: comprueba el estado de PHP-FPM. Verifica si el servicio está activo y reinícialo si hace falta:

systemctl status php8.2-fpm
sudo systemctl restart php8.2-fpm

Paso 3: revisa el log de PHP-FPM, habitualmente en /var/log/php8.2-fpm.log. Ahí aparecerán avisos de saturación como «server reached pm.max_children setting», señal clara de que toca ajustar la configuración de procesos o ampliar recursos.

Paso 4: confirma qué socket o puerto escucha PHP-FPM con sudo ss -tlnp | grep php o revisando el parámetro listen del archivo www.conf. Compáralo con la directiva fastcgi_pass de tu configuración de Nginx. Si no coinciden, ahí tienes el fallo.

Con estos cuatro pasos, en la mayoría de los casos, tendrás una idea muy precisa de dónde viene el problema.

Soluciones paso a paso para corregir el error 502 Bad Gateway en Nginx

Encontrada la causa, arreglarlo suele ser cosa de minutos. Yo seguiría este orden, de lo más obvio a lo más rebuscado:

1. Mira si el backend está vivo: ejecuta systemctl status php-fpm (o el servicio que toque). Si está caído, arráncalo de nuevo con systemctl restart php-fpm.
2. Verifica el socket o puerto: comprueba que la directiva fastcgi_pass de tu bloque location apunta al mismo socket que tiene configurado PHP-FPM. Por ejemplo: fastcgi_pass unix:/run/php/php8.2-fpm.sock;
3. Revisa los logs: échale un ojo a /var/log/nginx/error.log y al log de PHP-FPM. Un mensaje tipo «connect() failed» casi siempre delata un socket mal apuntado o permisos que no llegan.
4. Ajusta los permisos: asegúrate de que el usuario de Nginx (normalmente www-data) puede leer y escribir en ese socket. Se define en www.conf con listen.owner y listen.group.
5. Sube los timeouts: si el backend tarda en contestar, añade al bloque de configuración: proxy_read_timeout 120; y fastcgi_read_timeout 120;
6. Comprueba los recursos del servidor: con free -m y df -h descarta memoria agotada o un disco lleno. Dos causas de caída del proceso PHP muchísimo más frecuentes de lo que parece.

Después de cada cambio, valida la sintaxis con nginx -t y aplica con systemctl reload nginx. Así recargas la configuración sin tirar el servicio.

Cómo prevenir el error 502: buenas prácticas de configuración y monitoreo

Prevenir sale más barato que apagar incendios, sobre todo en producción. Vale la pena —nunca mejor dicho— invertir un rato en esto:

• Configura bien el gestor de procesos de PHP-FPM: ajusta pm.max_children, pm.start_servers y pm.max_spare_servers según la memoria que de verdad tenga tu servidor, no según lo que decía un tutorial.
• Activa reinicios automáticos: con systemd, añade Restart=on-failure en la unit de PHP-FPM. Si el servicio se cae, se levanta solo.
• Implementa un health check: un script sencillo que haga curl a tu web cada minuto y te avise por correo o Telegram si recibe un 502. Cinco líneas de bash te ahorran llamadas de clientes a deshoras.
• Limita el tamaño de las peticiones: la directiva client_max_body_size evita que una subida enorme sature el backend.
• Mantén todo actualizado: Nginx y PHP en versiones soportadas. Las viejas acumulan fugas de memoria que acaban, tarde o temprano, en un 502.
• Registra y analiza los logs: con GoAccess o el monitoreo del propio panel puedes ver patrones antes de que el fallo sea visible para tus usuarios.

¿Administras varios sitios? Entonces centraliza el monitoreo con Uptime Kuma, Zabbix o algún servicio externo, y configura alertas con umbrales razonables. Si no, te acabarás acostumbrando a los falsos positivos y no harás caso ni del real.

Conclusión: mantén tu servidor Nginx libre de errores 502

El 502 Bad Gateway en Nginx casi nunca es culpa de Nginx. Es el síntoma de un backend que no responde: servicio caído, permisos incorrectos, timeouts demasiado justos o recursos agotados. Con el método de diagnóstico que hemos recorrido —comprobar el estado del backend, revisar logs, validar sockets y ajustar timeouts— la mayoría de incidencias se resuelven en poco más de un café.

A largo plazo, lo que marca la diferencia entre una web estable y una que pierde visitas por caídas inesperadas es la combinación de configuración bien dimensionada, reinicios automáticos y monitoreo constante. Y si prefieres dedicarte a tu proyecto en lugar de pelearte con la infraestructura, en RedServicio.net nuestro hosting incluye servidores optimizados, monitoreo proactivo de servicios y soporte técnico 24/7, para que tu sitio funcione como debe. Siempre.