Respuesta breve: un error 502 Bad Gateway significa que tu servidor web (a menudo Nginx) pidió la página al proceso de PHP y recibió algo inválido, o nada. El fallo está en la conexión entre ambas capas, no normalmente en tus entradas o tu base de datos.
En qué se diferencia de un 500
Un 500 suele indicar que la aplicación o el servidor fallaron al atender la petición. Un 502 normalmente indica que una pasarela no recibió una respuesta válida del servicio upstream: el proceso se cayó, agotó su tiempo o fue terminado por superar un límite de memoria. La distinción importa porque la solución está en los recursos y la configuración de procesos, no en el código de tu tema.
¿Constante o intermitente?
Es lo primero que hay que establecer. Un 502 constante suele seguir a un reinicio de PHP, un mal despliegue o una mala configuración de CDN/proxy. Un 502 intermitente que aparece bajo carga casi siempre significa capacidad: el pool de procesos PHP-FPM está agotado, o las peticiones superan el tiempo de espera del gateway. Correlaciona la hora con el tráfico; un 502 solo en horas punta es un problema de dimensionamiento, no un bug.
Lee los dos registros
Mira el registro de errores del servidor web para el mensaje de gateway, y el de PHP-FPM para “server reached max_children” o procesos terminados. Juntos te dicen si te quedaste sin procesos, alcanzaste un timeout o te caíste en una petición concreta. Revisa también /wp-content/debug.log por un error fatal dentro de una petición larga.
Encuentra la operación lenta o que falla
Identifica si lo dispara una acción: guardar una entrada larga, lanzar una importación, abrir un informe o una página que llama a una API externa lenta. Una única petición a un tercero colgada puede ocupar un proceso hasta que el gateway se rinde. Mueve las tareas realmente largas (copias, importaciones) a la línea de comandos o a un proceso programado en lugar de una petición web.
Qué no hacer, y cómo verificar
Recargar una y otra vez un 502 añade más peticiones atascadas a un pool saturado y alarga la caída. Subir todos los tiempos de espera sin encontrar la operación lenta solo convierte un fallo rápido en uno lento. Para verificar, reproduce la acción concreta que fallaba con una concurrencia realista y confirma que la web ahora degrada con elegancia en lugar de mantener las peticiones abiertas.
CRITERIO DE INCIDENTE WP REPAIR
Reconstruye el incidente antes de corregirlo
Un 502 describe un intercambio fallido entre pasarela y upstream, no un único fallo PHP. Correlacionar proxy, servidor web y PHP-FPM distingue proceso caído, timeout, socket o configuración upstream incorrecta.
- 1
Determina si el 502 es constante, de una ruta o dependiente de carga.
- 2
Haz coincidir la hora del gateway con eventos de PHP-FPM y del sistema.
- 3
Revisa socket o host upstream después de despliegues y reinicios.
- 4
Identifica llamadas externas o peticiones largas que ocupan procesos hasta que la pasarela abandona.
Qué debe quedar verificado
- La ruta original funciona repetidamente y con concurrencia realista.
- Los logs del gateway y PHP-FPM no muestran nuevos fallos upstream.
- Las dependencias externas fallan rápido o degradan de forma controlada.
Fuentes técnicas oficiales
Esta guía explica el diagnóstico. Si la web está afectada ahora, la intervención debe preservar una vía de vuelta y verificar el recorrido real del negocio.
Ver el servicio de reparación urgente →