Error 502 Bad Gateway en WordPress con Nginx: Guía Paso a Paso

El error 502 Bad Gateway es de esos fallos que sacan de quicio a cualquiera que administre un WordPress sobre Nginx. Aparece cuando Nginx, actuando como proxy o servidor web, recibe del proceso PHP-FPM una respuesta inválida, o directamente no recibe nada. Resultado: tu web cae entera y los visitantes se encuentran una página en blanco con ese mensaje, «502 Bad Gateway». Lo bueno es que casi siempre se arregla en cuestión de minutos, si sabes dónde mirar. Aquí te contamos qué lo provoca, cómo diagnosticarlo y qué soluciones concretas aplicar, paso a paso. Y si prefieres no pelear con el servidor, en RedServicio (redservicio.net) hay ayuda profesional para recuperar tu sitio enseguida.

Qué significa el error 502 Bad Gateway en WordPress con Nginx

El código HTTP 502 indica que un servidor que hace de gateway o proxy (aquí, Nginx) recibió una respuesta inválida de un servidor upstream. En una arquitectura típica de WordPress con Nginx, el flujo va así: el navegador del visitante manda la petición a Nginx, y Nginx la pasa a PHP-FPM mediante un socket Unix o una conexión TCP para que ejecute el código PHP de WordPress. Cuando PHP-FPM no responde, se cuelga, devuelve algo malformado o el socket no está disponible, Nginx no tiene más remedio que soltarle al visitante el 502.

Ojo, no lo confundas con errores parecidos. El 504 Gateway Timeout significa que PHP-FPM tardó demasiado en contestar (el proceso se quedó esperando), mientras que el 502 apunta a una comunicación fallida o rechazada desde el principio. Y esa diferencia ya es la primera pista de diagnóstico: un 504 suele delatar timeouts o scripts lentos; un 502, un servicio caído o mal configurado.

Causas más comunes del error 502 en Nginx y PHP-FPM

Después de años trasteando con servidores WordPress, estas son las causas que explican la gran mayoría de los casos:

• PHP-FPM detenido o colgado: el servicio php-fpm no está corriendo, o se bloqueó porque un proceso agotó los recursos. Es la causa número uno, sobre todo tras un reinicio del servidor en el que PHP-FPM no arrancó solo.
• Socket Unix incorrecto o con permisos erróneos: la directiva fastcgi_pass en Nginx apunta a una ruta de socket que no coincide con la real del pool de PHP-FPM (por ejemplo, Nginx apunta a /run/php/php8.2-fpm.sock pero la versión instalada genera php8.1-fpm.sock).
• Agotamiento de memoria: WordPress o algún plugin se come toda la RAM disponible y PHP-FPM mata los procesos workers. Nginx se queda sin nadie que atienda peticiones.
• Límite de procesos workers alcanzado: con picos de tráfico, la configuración pm.max_children del pool se satura y las nuevas peticiones se quedan sin atender.
• Actualizaciones de PHP o de paquetes mal hechas: subir la versión de PHP sin ajustar la configuración de Nginx es una fuente clásica de 502.
• Plugins o temas defectuosos: un plugin con un bug grave puede provocar cierres (segfaults) de los procesos PHP.

Cómo diagnosticar el error 502 revisando logs de Nginx y PHP-FPM

Antes de tocar nada, mira los logs. Casi siempre te dicen la causa exacta en la primera o segunda línea. Empieza por el error log de Nginx.

Revisa el archivo /var/log/nginx/error.log así:

1. Entra a tu servidor por SSH.
2. Ejecuta tail -50 /var/log/nginx/error.log para ver los últimos 50 errores.
3. Busca entradas del tipo «connect() failed (111: Connection refused) while connecting to upstream» o «recv() failed».

Ese «Connection refused» casi siempre significa que PHP-FPM no está escuchando en el socket o puerto que Nginx intenta usar. Y si el log menciona «No such file or directory», la ruta del socket en fastcgi_pass está mal.

Luego toca el turno al log de PHP-FPM, normalmente en /var/log/php8.2-fpm.log (ajusta la versión según tu instalación). Busca líneas que digan «server reached pm.max_children» o señales de tipo SIGSEGV, que delatan saturación o fallos de memoria. Conviene echar un vistazo también al log de errores de PHP y de WordPress (wp-content/debug.log, si tienes WP_DEBUG activado) por si el culpable es un plugin.

Con el diagnóstico claro, ya sabes si el problema viene del servicio, del socket, de la memoria o del código. En las siguientes secciones de la guía atacamos la solución de cada escenario.

Soluciones paso a paso: reiniciar servicios y ajustar configuración

Con el diagnóstico sobre la mesa, toca aplicar la solución que corresponda. Si PHP-FPM está caído, reinícialo sin esperar:

1. Reinicia PHP-FPM según tu versión: sudo systemctl restart php8.1-fpm (ajusta la versión a la que tengas instalada).
2. Verifica que escucha en el socket correcto: sudo ss -lxnp | grep fpm.
3. Recarga Nginx sin cortar conexiones activas: sudo nginx -t && sudo systemctl reload nginx.

¿El error aparece solo en picos de tráfico? Entonces el sospechoso habitual es el límite de procesos de PHP-FPM. Abre el pool www.conf y revisa pm.max_children, pm.start_servers y pm.max_spare_servers. Para calcular max_children hay una regla sencilla: divide la RAM disponible para PHP entre el consumo medio de un proceso WordPress (entre 50 y 80 MB, normalmente). Un servidor con 4 GB dedicados a PHP y procesos de 64 MB admite unos 60 children. Ni más ni menos.

Cuando el origen es un timeout, toca ajustar el bloque de PHP de Nginx:

• fastcgi_read_timeout 300; para operaciones largas como importaciones o actualizaciones de plugins.
• fastcgi_buffers 16 32k; y fastcgi_buffer_size 64k; si el log muestra errores de buffer upstream.

Y si el culpable es un plugin o tema defectuoso, ve a lo práctico: renombra la carpeta wp-content/plugins por FTP o SSH y desactívalos todos de golpe. Si el sitio vuelve a funcionar, reactívalos uno a uno hasta dar con el conflictivo. Es tedioso, lo sé, pero funciona. En RedServicio (redservicio.net) pueden ayudarte a identificar el código responsable si la depuración se complica.

Ajustes avanzados en Nginx para prevenir el error 502 Bad Gateway

Prevenir es, sobre todo, configurar Nginx y PHP-FPM de forma coordinada. Empieza haciendo el socket Unix resiliente: define en el pool de PHP-FPM listen = /run/php/php8.1-fpm.sock con permisos listen.owner = www-data y listen.group = www-data, y usa exactamente esa ruta en fastcgi_pass. Una letra que no coincide ahí y ya tienes otro 502 servido.

Conviene añadir redundancia frente a reinicios del backend mediante upstream:

• upstream php_backend { server unix:/run/php/php8.1-fpm.sock; }
• server 127.0.0.1:9000 backup; si dispones de un pool TCP secundario.

Automatiza la vigilancia. Que el error 502 bad gateway no te pille desprevenido otra vez:

• Configura pm.status_path = /status y monitoriza los procesos activos con un cron o con Netdata.
• Usa monit o un script simple que compruebe curl -s -o /dev/null -w «%{http_code}» https://tudominio.com y reinicie PHP-FPM si devuelve 502.
• Habilita slowlog en PHP-FPM para detectar plugins lentos antes de que saturen el pool.

Por último, limita la carga. Un sistema de caché a nivel de Nginx (FastCGI Cache) reduce drásticamente las peticiones que llegan a PHP y, con ello, el riesgo de saturar el pool. Un rate limiting básico con limit_req_zone protege, de paso, frente a ataques de fuerza bruta que disparan el consumo de recursos.

Conclusión: mantener tu WordPress estable con Nginx

El error 502 bad gateway es siempre un síntoma, nada más: Nginx no ha recibido una respuesta válida de PHP-FPM. La buena noticia es que casi todos los casos se resuelven con método. Revisar el estado del servicio, verificar que socket y fastcgi_pass coinciden, comprobar límites de memoria y timeouts, aislar plugins problemáticos. Con los ajustes avanzados de esta guía (dimensionado correcto del pool, monitorización activa y caché en Nginx) puedes pasar de reaccionar ante avisos a evitar que se produzcan.

Si necesitas asistencia para aplicar estos cambios, o prefieres que alguien con más experiencia revise tu servidor, en RedServicio (redservicio.net) encontrarás soporte profesional especializado en WordPress, Nginx y administración de servidores. Y dos hábitos que no tienen precio: copias de seguridad recientes y documentar cada cambio en la configuración. Con eso, tu sitio aguantará incluso los picos de tráfico más exigentes.