Respuesta breve: un 504 Gateway Timeout significa que un servidor upstream (PHP, o un proxy delante) no respondió a tiempo y la petición se cortó. Algo tardó demasiado: una consulta lenta, una llamada externa colgada o una operación pesada en una petición web.
Qué suele agotar el tiempo
- Una importación, exportación o copia por navegador en lugar de línea de comandos.
- Una API externa lenta o que no responde, llamada durante la generación de la página.
- Una consulta que recorre muchas más filas de las que debería, a menudo en una tabla grande.
- Operaciones masivas: regenerar miniaturas, actualizar muchos productos.
- Un timeout de CDN o proxy más corto de lo que necesita el origen.
Encuentra la operación lenta
Activa WP_DEBUG_LOG y revisa los registros del servidor y de PHP-FPM por lo que se ejecutaba al saltar el timeout. Usa Query Monitor en la página lenta para exponer una consulta sin índice o sin límites y el plugin que la dispara. Si una acción concreta lo provoca —una importación, un informe—, eso acota la búsqueda de inmediato.
Sube el tiempo solo donde corresponde
Para una migración puntual real puedes subir temporalmente los timeouts del proxy y de PHP. Pero en una página que cargan visitantes reales, un timeout mayor solo mantiene un proceso ocupado más tiempo y reduce cuántas visitas atiendes. La solución duradera es hacer rápida la operación, o mover las tareas realmente largas a WP-CLI o a un proceso programado.
Verifica
Reproduce la acción exacta que agotó el tiempo en condiciones realistas y confirma que ahora termina holgadamente dentro del límite, no justo por debajo. Si era una API externa, confirma que la web degrada con elegancia en lugar de colgarse cuando ese servicio va lento.
CRITERIO DE INCIDENTE WP REPAIR
Reconstruye el incidente antes de corregirlo
Un 504 es la pasarela abandonando mientras el upstream sigue sin terminar. La reparación es hallar la operación o dependencia lenta, no ampliar todos los timeouts.
- 1
Anota ruta o acción exacta y duración del timeout del gateway.
- 2
Correlaciona logs de proxy, PHP-FPM, aplicación y consultas lentas.
- 3
Identifica importaciones, informes, APIs o consultas sin límites asociadas.
- 4
Saca trabajos largos de la petición web o añade timeouts limitados y observables a dependencias.
Qué debe quedar verificado
- La operación original termina con margen seguro.
- Las peticiones normales responden mientras se ejecuta.
- Las dependencias externas agotan tiempo y degradan de forma predecible.
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 →SOBRE ESTE SÍNTOMA
Preguntas frecuentes de esta guía.
¿Es un 504 el mismo problema que un error 503?+
No. Un 504 significa que un servidor ascendente, típicamente PHP o un proxy delante de él, no respondió dentro del tiempo permitido, apuntando a algo que toma demasiado tiempo para ejecutar. Un 503 generalmente significa que el servidor no podía manejar la petición en absoluto, a menudo debido a un archivo de mantenimiento atascado o recursos agotados, no una operación lenta.
¿Debería aumentar el límite de tiempo de espera cada vez que veo un 504?+
Sólo para una tarea única genuina como una migración. El aumento del tiempo de espera en una página real los visitantes cargan sólo mantiene a un trabajador ocupado más tiempo y reduce la cantidad de visitantes que el servidor puede manejar a la vez, no arregla la operación lenta subyacente.
¿Cuál es la manera correcta de ejecutar una gran importación o exportación sin golpear un 504?+
Ejecutarlo a través de WP-CLI o un proceso de fondo programado en lugar de a través del navegador. Importaciones, exportaciones y copias de seguridad activadas por el navegador son exactamente el tipo de operaciones de larga duración que comúnmente superan el tiempo de espera proxy o PHP.
¿Cómo puedo averiguar qué consulta o plugin está causando realmente el tiempo de espera?+
Habilitar WP_DEBUG_LOG y comprobar el servidor y los registros PHP-FPM de lo que se estaba ejecutando cuando se produjo el tiempo de espera, luego utilizar una herramienta como Query Monitor en la página lenta para exponer una consulta no indizada o sin límite e identificar el plugin que lo dispara.