HTTP 502 suele indicar que un proxy o servidor web no ha obtenido una respuesta válida del servicio situado detrás, normalmente PHP-FPM. WordPress puede generar la carga que desencadena el fallo, pero el propio 502 nace una capa antes.
Guarda las cabeceras de la respuesta y la hora antes de reiniciar servicios. Un reinicio puede recuperar la web y, al mismo tiempo, borrar las pistas de un proceso caído o un grupo de workers agotado.
Identifica quién generó el 502
Revisa las cabeceras y el diseño del cuerpo para distinguir Cloudflare, un proxy del alojamiento, Nginx, Apache o un balanceador. Si hay CDN, prueba el origen mediante un método autorizado por el proveedor.
Registra:
estado público y del origen
URL y duración de la petición
identificador de petición o Ray ID
registros del servidor y PHP a la misma hora
si funcionan los archivos estáticosNo expongas la IP de origen ni debilites el cortafuegos para hacer la prueba.
Compara peticiones estáticas y PHP
Solicita una imagen o CSS conocidos y después wp-login.php y la página afectada. Si los recursos estáticos funcionan y todo PHP devuelve 502, la causa apunta a PHP-FPM, su socket o el servicio upstream.
Si solo falla una ruta de WordPress, investiga la carga PHP y el tiempo de esa petición. Si fallan todas las webs de la cuenta, es más probable que exista un problema de capacidad compartida o configuración del servicio.
Comprueba dominios vecinos únicamente cuando estés autorizado.
Revisa los registros del proxy y PHP-FPM
Busca mensajes como «connection refused», «upstream prematurely closed connection», «no live upstreams», salida de un worker, fallo de segmentación o timeout.
Relaciona el PID y la hora entre registros. Un error fatal de PHP suele producir una respuesta de aplicación; un proceso que se desploma puede dejar al proxy sin ninguna cabecera válida.
Protege los registros porque las rutas y los parámetros de petición pueden contener información sensible.
Comprueba si faltan workers de PHP
Todos los procesos pueden estar ocupados en peticiones lentas, haciendo que las nuevas conexiones esperen o fallen. Revisa procesos activos y máximos, longitud de la cola, CPU y RAM.
Aumentar el número de workers consume más memoria. Calcula el pico por proceso y la capacidad total del servidor antes de modificar el pool.
Localiza la ruta, consulta o API externa que mantiene ocupados los procesos. Añadir capacidad no debería ocultar un trabajo sin límites.
Verifica la configuración del socket o puerto
Nginx o Apache deben conectarse al mismo socket Unix o puerto TCP donde escucha PHP-FPM. Tras cambiar de versión PHP, la antigua ruta del socket puede dejar de existir.
Compara el propietario y los permisos del socket con el usuario del servidor web. No uses permisos de escritura universal como reparación.
En cPanel o Plesk utiliza los controles compatibles del controlador PHP para que el panel no sobrescriba después la configuración.
Busca caídas de procesos
Consulta los registros del sistema y PHP para detectar procesos terminados por falta de memoria, fallos de segmentación o extensiones defectuosas. El sistema operativo puede matar PHP sin dejar ninguna entrada en WordPress.
Desactiva o actualiza la extensión responsable mediante los controles del alojamiento después de reproducir el problema en pruebas. No retires de producción extensiones necesarias sin revisar qué webs dependen de ellas.
Comprueba espacio e inodos: los servicios también fallan cuando no pueden escribir sockets o registros.
Separa un 502 de la CDN de uno del origen
Cloudflare puede devolver 502 si no logra conectar con el origen o si este envía una respuesta inválida. Relaciona el identificador del evento con el registro de acceso del servidor.
Si no aparece ninguna petición en el origen, revisa DNS, ruta de red, cortafuegos o TLS entre el edge y el servidor. Si el origen registra su propio 502, el problema está en la pila local.
No abras una regla amplia de cortafuegos sin comprobar los requisitos de red vigentes del proveedor.
Repara y verifica con carga
Corrige el socket, el servicio PHP, la capacidad del pool, la extensión que cae o la ruta lenta demostrada por las pruebas. Reinicia solo el servicio necesario y documenta el estado anterior.
Repite peticiones PHP, acciones administrativas y la ruta original mientras observas los workers. El mantenimiento recurrente debería alertar por colas de PHP, caídas de procesos y tasa de 502 para intervenir antes de que los fallos intermitentes se conviertan en una caída completa.