El error 504 Gateway Timeout se produce cuando un servidor que actúa como puerta de enlace o proxy no recibe a tiempo una respuesta de otro servidor. Suele ocurrir cuando la aplicación que procesa las solicitudes del sitio web es lenta, está sobrecargada o tiene problemas de conectividad.
Si estás visitando un sitio web, espera un momento y actualiza la página. Si administras el sitio, empieza por revisar los registros del servidor y de la aplicación para identificar dónde se produce la demora.
Aquí tienes siete formas prácticas de investigar y solucionar el error.
¿Qué causa un error 504 Gateway Timeout?
Muchos sitios web utilizan varios servidores o servicios para gestionar las solicitudes.
Por ejemplo, un navegador puede conectarse a Nginx o a una CDN, que después reenvía la solicitud a un servidor de aplicaciones.
Si esa aplicación tarda demasiado en responder, la puerta de enlace puede devolver un error 504 en lugar de la página solicitada.
Entre las causas habituales se encuentran:
- Servidores de aplicaciones sobrecargados o que no responden.
- Consultas lentas a bases de datos o solicitudes a API externas.
- CPU, RAM o procesos de trabajo de la aplicación insuficientes.
- Problemas de red entre la puerta de enlace y el servidor que procesa las solicitudes.
- Límites de tiempo de espera del proxy o de la aplicación.
- Una CDN o una infraestructura de alojamiento mal configuradas.
Un error 504 suele ser un problema del servidor, aunque los problemas específicos de una conexión a veces pueden afectar a visitantes individuales.
1. Actualiza el sitio web y comprueba si está disponible
Si solo estás visitando un sitio web, espera un momento y actualiza la página.
Una sobrecarga temporal del servidor o una solicitud interrumpida a la aplicación pueden resolverse sin intervención.
También puedes probar con otro navegador o red para comprobar si el problema está relacionado con tu conexión.
Si el error afecta a todo el mundo, por lo general tendrá que investigarlo el propietario del sitio web o el proveedor de alojamiento.
Evita enviar repetidamente pagos, pedidos o formularios. Es posible que la operación se haya completado aunque la puerta de enlace haya agotado el tiempo de espera antes de devolver la respuesta.
2. Revisa los registros del servidor y de la aplicación
Si administras el servidor, los archivos de registro son el mejor punto de partida.
En Nginx, consulta el registro de errores:
sudo tail -n 50 /var/log/nginx/error.logBusca mensajes similares a este:
upstream timed out (110: Connection timed out)Esto indica que Nginx esperó demasiado a que se completara una operación en un servidor de origen.
A continuación, revisa los registros de la aplicación para determinar por qué tardó en responder.
También puedes examinar un servicio gestionado por systemd:
sudo journalctl -u myapp -n 50Sustituye myapp por el nombre real de tu servicio.
3. Comprueba el uso de CPU, RAM y disco
Un servidor con mucha carga puede tener dificultades para procesar las solicitudes dentro del tiempo de espera de la puerta de enlace.
Comprueba la memoria:
free -hComprueba el espacio en disco:
df -hSupervisa los procesos:
topBusca señales de saturación sostenida de los recursos, memoria agotada, sistemas de archivos llenos o procesos con una actividad inusualmente alta.
Estos resultados no demuestran por sí solos por qué se agotó el tiempo de espera de la solicitud, pero pueden ayudarte a identificar cuellos de botella en el rendimiento.
4. Investiga los tiempos de espera de Nginx y de los servidores de origen
Si Nginx actúa como proxy inverso, comprueba si la aplicación de origen responde dentro de los límites de tiempo de espera configurados.
Para servidores de origen HTTP, la configuración puede incluir:
location / {
proxy_pass http://127.0.0.1:3000;
proxy_read_timeout 60s;
}La opción proxy_read_timeout controla cuánto tiempo espera Nginx entre lecturas sucesivas del servidor de origen, no la duración total de la solicitud.
Antes de aumentarla, prueba directamente el servidor de origen:
curl --max-time 15 -i http://127.0.0.1:3000/Sustituye la dirección por el punto de conexión real de tu aplicación. Algunas rutas de la aplicación pueden requerir autenticación o devolver una respuesta válida distinta de HTTP 200.
Si la propia aplicación es lenta, aumentar el tiempo de espera de Nginx puede limitarse a ocultar el problema subyacente.
Si está realmente justificado ampliar el tiempo de espera, revisa también la configuración de la aplicación. Las aplicaciones basadas en PHP-FPM y FastCGI utilizan directivas de Nginx distintas de las de los servidores de origen HTTP conectados mediante proxy.
Después de cambiar la configuración, valídala antes de recargar Nginx:
sudo nginx -t
sudo systemctl reload nginxRecarga Nginx solo si la prueba de configuración se completa correctamente.
5. Comprueba Cloudflare o tu CDN
Si tu sitio web utiliza Cloudflare u otra red de distribución de contenidos, determina si el tiempo de espera se agota en la CDN o en tu servidor de origen.
Consulta la información sobre errores de tu CDN y compárala con los registros de tu servidor de origen.
Un error 504 puede proceder de un servicio situado detrás de tu servidor de origen o de otra capa de la ruta que sigue la solicitud.
Cloudflare tiene sus propios límites de tiempo para las conexiones y las respuestas, por lo que aumentar un tiempo de espera de Nginx no necesariamente anulará un límite impuesto por la CDN.
Evita desactivar las funciones de seguridad o caché sin identificar primero el origen del tiempo de espera agotado.
6. Investiga las consultas lentas a bases de datos y las API externas
A veces, el servidor web funciona correctamente, pero la aplicación está esperando a otro servicio.
Algunos ejemplos habituales son:
- Una consulta a la base de datos que tarda demasiado.
- Una API externa que responde con lentitud.
- Grupos de procesos de trabajo de la aplicación saturados.
- Tareas en segundo plano que compiten por los recursos.
- Bloqueos de la base de datos que retrasan las solicitudes.
Revisa los registros de la aplicación, los registros de consultas lentas y las métricas de los servicios para identificar la demora.
Si la causa es una consulta a la base de datos, investiga los índices, los planes de ejecución de consultas y el uso de las conexiones.
Para las llamadas a API externas, configura tiempos de espera razonables y una gestión adecuada de errores. Si la aplicación lo permite, puede ser mejor procesar de forma asíncrona las tareas de larga duración.
7. Contacta con tu proveedor de alojamiento
Si no consigues resolver el error 504 Gateway Timeout, contacta con tu proveedor de alojamiento y facilítale la información que hayas recopilado.
Indica el dominio afectado, cuándo comenzó el problema, si ocurre de forma intermitente y cualquier mensaje de registro relevante.
Menciona los cambios recientes en la configuración de la aplicación, la base de datos, la CDN o el proxy inverso.
Un proveedor de alojamiento puede ayudarte a investigar las restricciones de recursos y los problemas de infraestructura que quedan fuera de tu ámbito de administración.
Errores de puerta de enlace 502 y 504: ¿en qué se diferencian?
Estos errores están relacionados, pero indican problemas diferentes en los servidores de origen.
| Error | Significado |
|---|---|
| 502 Bad Gateway | Una puerta de enlace recibió una respuesta no válida de un servidor de origen |
| 504 Gateway Timeout | Una puerta de enlace no recibió a tiempo la respuesta necesaria de un servidor de origen |
Por ejemplo, una aplicación que cierra una conexión inesperadamente puede provocar un error 502, mientras que una que tarda demasiado en responder puede causar un 504.
Cómo prevenir los errores 504 Gateway Timeout
No todos los tiempos de espera agotados pueden evitarse, pero una buena gestión de la infraestructura ayuda a reducir su frecuencia.
- Supervisa los tiempos de respuesta de la aplicación y el uso de recursos.
- Investiga las consultas lentas a la base de datos.
- Utiliza una caché adecuada para el contenido que se solicita con frecuencia.
- Configura tiempos de espera razonables para los servidores de origen y la aplicación.
- Supervisa los servicios que procesan las solicitudes y la disponibilidad de los procesos de trabajo.
- Prueba los cambios importantes de configuración antes de aplicarlos.
Aumentar los límites de tiempo de espera debe ser una decisión meditada, no el primer paso para investigar el problema.
Preguntas frecuentes
Sí. HTTP 504 es un código de estado del servidor que indica que una puerta de enlace o un proxy no recibió a tiempo la respuesta de un servidor de origen.
Por lo general, no. La caché del navegador no soluciona el problema de un servidor que procesa las solicitudes si está sobrecargado o no responde. Sin embargo, probar con otro navegador o conexión puede ayudar a descartar problemas locales.
Puede serlo. Una sobrecarga temporal o una solicitud lenta a la aplicación pueden resolverse rápidamente, mientras que los tiempos de espera agotados de forma recurrente indican un problema que debe investigarse.
Sí. WordPress y otras aplicaciones pueden experimentar errores 504 cuando las consultas a la base de datos, el procesamiento de PHP o los servicios de origen tardan demasiado.
Solo si la aplicación necesita legítimamente más tiempo y los demás límites de la infraestructura lo permiten. Primero, determina por qué se retrasa la respuesta de la aplicación.
Conclusión
Un error 504 Gateway Timeout significa que una puerta de enlace esperó demasiado a que respondiera un servidor de origen.
Los visitantes pueden comprobar si el problema es temporal, mientras que los administradores deben examinar los registros, los recursos del servidor, el rendimiento de la aplicación y la configuración del proxy.
La solución más fiable consiste en identificar el origen de la demora, en lugar de aumentar a ciegas los límites de tiempo de espera o reiniciar servicios.
