Errores 502 y 504 en WordPress:

Un error 502 o 504 puede aparecer durante unos segundos y desaparecer después. A veces afecta solo al panel de administración, una operación concreta o determinadas horas del día. Esa intermitencia hace que sea tentador aumentar recursos o reiniciar servicios sin investigar qué está fallando.

Pero un 502 o un 504 no identifica por sí solo la causa. El error puede estar relacionado con PHP-FPM, el servidor web, una consulta lenta, una tarea pesada, un proxy inverso o un límite de tiempo. También puede ser una consecuencia de un pico de tráfico o de un proceso que consume más recursos de los disponibles.

La forma más segura de resolverlo es separar las capas de la petición y recopilar datos antes de cambiar la configuración.

Qué significa un error 502

El código 502 indica que un servidor que actúa como puerta de enlace o proxy ha recibido una respuesta no válida del servidor situado detrás.

En una instalación WordPress, la cadena puede incluir:

• El navegador.
• Un CDN o proxy inverso.
• Nginx o Apache.
• PHP-FPM.
• WordPress.
• La base de datos.
• Un servicio externo utilizado por un plugin.

Un 502 puede aparecer cuando PHP-FPM no responde correctamente, se reinicia, no tiene procesos disponibles o devuelve una respuesta que el servidor web no puede procesar. También puede estar provocado por un problema entre el proxy y el servidor de origen.

El código no demuestra que WordPress sea el origen del fallo. Solo indica que una capa intermedia no ha recibido la respuesta esperada.

Qué significa un error 504

El código 504 indica que un servidor intermedio ha esperado una respuesta durante un tiempo determinado y ha agotado el plazo.

En WordPress puede ocurrir cuando:

• Una consulta a la base de datos tarda demasiado.
• Un plugin ejecuta una operación pesada.
• Una importación o exportación supera el tiempo disponible.
• PHP está esperando una respuesta externa.
• El servidor está saturado.
• El timeout del proxy es inferior al tiempo necesario para completar una operación legítima.

Un 504 tampoco demuestra que la web esté caída por completo. Puede afectar a una sola petición mientras el resto del sitio sigue funcionando.

Diagnóstico paso a paso

1. Anota cuándo y dónde aparece

Antes de cambiar nada, registra el comportamiento del error.

Anota:

• Fecha y hora exactas.
• URL o acción que provoca el error.
• Si ocurre en la web pública, en wp-admin o en ambos.
• Si afecta a todos los usuarios o solo a algunos.
• Si ocurre desde una red concreta.
• Si desaparece al repetir la operación.
• Si coincide con una copia, importación, actualización o tarea programada.
• El código recibido: 502, 504 u otro.

También conviene conservar la respuesta completa o una captura. Un error mostrado por Cloudflare, Nginx, Apache o el proveedor puede aportar pistas sobre qué capa lo está generando.

2. Comprueba si el problema es general o de una operación concreta

No es lo mismo que falle toda la web a que falle una acción concreta.

Prueba, sin repetir la operación de forma excesiva:

• La portada.
• Una entrada publicada.
• Una página que no utilice funciones especiales.
• El acceso a WordPress.
• La pantalla de edición.
• Una búsqueda.
• Un formulario.
• La acción exacta que produjo el error.

Si solo falla una importación, un informe, una búsqueda o la edición de un contenido concreto, puede existir una operación lenta o un problema de datos. Si fallan también páginas estáticas y peticiones sencillas, hay que prestar más atención al servidor web, PHP-FPM, la red o los recursos disponibles.

3. Revisa los registros del servidor web y de PHP

Los registros suelen ser más útiles que el mensaje genérico del navegador.

Busca en el mismo intervalo de tiempo:

• Errores de Nginx o Apache.
• Errores de PHP.
• Reinicios de PHP-FPM.
• Mensajes de procesos agotados.
• Conexiones rechazadas.
• Timeouts.
• Errores de permisos.
• Fallos de resolución o conexión con servicios externos.

No basta con abrir el último error del registro. Hay que relacionarlo con la hora y la URL afectada.

Una secuencia de errores de conexión con PHP-FPM apunta a una capa diferente que una consulta SQL lenta o un max_execution_time agotado. El texto exacto puede variar según el servidor y el proveedor.

4. Comprueba PHP-FPM y sus límites

PHP-FPM gestiona los procesos que ejecutan PHP. Si no hay procesos disponibles o si se terminan de forma inesperada, el servidor web puede devolver errores 502.

Revisa, si tienes acceso a estos datos:

• Número de procesos activos.
• Procesos ocupados y libres.
• Límite de procesos configurado.
• Cola de peticiones pendientes.
• Reinicios del servicio.
• Errores de memoria.
• Tiempo de ejecución.
• Límite de peticiones por proceso.

Aumentar el número de procesos no siempre soluciona el problema. Cada proceso consume memoria y, si el servidor no tiene margen suficiente, el cambio puede provocar más presión sobre el sistema.

Antes de aumentar límites, comprueba si una operación concreta está bloqueando los procesos o si existe una fuga de memoria.

5. Comprueba la memoria y la carga del servidor

Un servidor sin memoria disponible puede terminar procesos, ralentizar la base de datos o hacer que PHP deje de responder.

Relaciona el momento del error con:

• Memoria disponible.
• Uso de CPU.
• Carga del sistema.
• Procesos en ejecución.
• Espacio libre en disco.
• Inodos disponibles.
• Tráfico recibido.
• Límites de la cuenta de hosting.

En un hosting compartido puede haber límites que no se ven desde WordPress. El proveedor puede limitar procesos, memoria, conexiones o tiempo de CPU aunque la web no parezca especialmente grande.

Los síntomas de saturación y los de una consulta lenta pueden parecerse. Por eso es importante mirar las métricas y los registros del mismo periodo.

6. Revisa la base de datos

Una consulta lenta puede mantener ocupado un proceso PHP hasta que el proxy agota su tiempo de espera.

Comprueba:

• Consultas lentas, si el proveedor las registra.
• Tablas muy grandes.
• Revisiones y transitorios acumulados.
• Búsquedas sin índices adecuados.
• Importaciones en curso.
• Plugins que realizan consultas en cada petición.
• Bloqueos o conexiones agotadas.
• Errores de conexión con MySQL o MariaDB.

No borres tablas, revisiones o transitorios sin copia y sin entender su función. Una limpieza indiscriminada puede eliminar datos necesarios o no resolver la causa real.

Si el error solo aparece al guardar o consultar determinados contenidos, compara el tamaño y la estructura de esas operaciones con las que funcionan correctamente.

7. Investiga plugins, temas y tareas pesadas

Una actualización, un plugin nuevo o una tarea automática pueden cambiar el tiempo necesario para completar una petición.

Presta atención a:

• Plugins instalados o actualizados recientemente.
• Tema activo y código personalizado.
• Importadores y exportadores.
• Generadores de informes.
• Optimizadores y rastreadores.
• Copias de seguridad.
• Sincronizaciones con servicios externos.
• Tareas de WP-Cron.
• Procesos lanzados desde el panel.

Desactivar un plugin puede servir como prueba, pero registra antes el estado de la web y evita hacerlo a ciegas en producción. Si el problema desaparece, todavía hay que determinar qué operación concreta provocaba el bloqueo y si existe una configuración o actualización que lo corrija.

8. Comprueba el proxy, CDN y timeouts

Cuando hay Cloudflare, un balanceador, un CDN o un proxy inverso, la petición puede atravesar varios límites de tiempo.

Comprueba:

• Qué componente está generando el 502 o 504.
• Tiempo de espera del proxy.
• Tiempo de espera del servidor web.
• Tiempo de respuesta del origen.
• Estado del CDN.
• Reglas de caché y bypass.
• Cambios recientes en DNS o certificados.
• Respuestas directas del servidor de origen, si es posible.

Aumentar el timeout puede ser correcto para una operación conocida y legítima, pero también puede ocultar una consulta ineficiente o una tarea que no debería ejecutarse durante una petición web.

Primero hay que saber qué está esperando el servidor y por qué.

9. Reproduce el error con una prueba controlada

Una reproducción controlada ayuda a separar una incidencia constante de un pico puntual.

Utiliza una única operación conocida y registra:

• URL solicitada.
• Hora de inicio.
• Hora de finalización.
• Código HTTP.
• Tiempo de respuesta.
• Tamaño de la respuesta.
• Registros generados.
• Consumo de recursos durante la prueba.

No conviene lanzar muchas peticiones para intentar provocar el error. Una prueba agresiva puede agravar la saturación y contaminar los registros.

Si el fallo solo ocurre con una cuenta, una IP, una cookie o un tipo de contenido, ese dato puede ser más útil que repetir la misma petición desde el navegador.

10. Decide si necesitas ajustar recursos

Aumentar recursos puede ser necesario, pero debería ser una conclusión basada en datos.

Antes de migrar o contratar más capacidad, intenta responder:

• ¿Se ha alcanzado un límite concreto?
• ¿El problema coincide con un pico de tráfico real?
• ¿Hay procesos PHP agotados?
• ¿La base de datos tiene consultas lentas?
• ¿El disco o la memoria están al límite?
• ¿Una tarea concreta consume los recursos?
• ¿El proxy tiene un timeout incompatible?
• ¿El problema aparece después de un cambio identificable?

Si el cuello de botella es una consulta o un plugin, más CPU puede retrasar el síntoma sin resolverlo. Si el servidor llega regularmente a sus límites con una carga legítima, entonces sí puede ser necesario cambiar el plan, ajustar la configuración o valorar otra arquitectura.

Qué datos conviene recopilar antes de pedir ayuda

Para que otra persona pueda investigar el problema, prepara:

• URL afectada.
• Código recibido.
• Fechas y horas con zona horaria.
• Capturas o respuestas completas.
• Registros relacionados.
• Cambios recientes.
• Plugins y tema modificados.
• Métricas de CPU, memoria y disco.
• Configuración de PHP-FPM disponible.
• Si hay CDN, proxy o balanceador.
• Si afecta a todos los usuarios o a una operación concreta.

Evita enviar contraseñas, tokens, cookies de sesión o copias completas de bases de datos. Los registros también pueden contener información personal y deben compartirse con cuidado.

Un 502 o un 504 no es un diagnóstico

Estos códigos indican que una petición no ha recibido la respuesta esperada dentro de la cadena de servidores. No explican por sí solos si el problema está en PHP-FPM, WordPress, la base de datos, el proxy, el hosting o una tarea concreta.

La solución más segura empieza por localizar la capa afectada, comparar los momentos en los que aparece el error y revisar los datos disponibles antes de aumentar recursos.

A veces el problema se resuelve ajustando un límite. En otros casos hay que corregir una consulta, retirar una tarea pesada, actualizar un componente o cambiar la forma en la que se ejecuta una operación. Sin diagnóstico, migrar a un servidor más grande puede ser solo una forma más cara de conservar el mismo problema.