Error 504 Gateway Timeout: qué significa y cómo solucionarlo

¿Qué es el error 504 Gateway Timeout?

El 504 Gateway Timeout es un código de estado HTTP que significa que un servidor actuando como gateway o proxy no recibió una respuesta a tiempo del servidor upstream. El proxy esperó a que el upstream respondiera, pero tardó demasiado, así que el proxy se rindió y devolvió un error 504 a tu navegador.

El RFC 9110 lo define así: «El código de estado 504 (Gateway Timeout) indica que el servidor, mientras actuaba como gateway o proxy, no recibió una respuesta a tiempo de un servidor upstream al que necesitaba acceder para completar la petición» (RFC 9110 §15.6.5).

La palabra clave es gateway. Un error 504 siempre involucra al menos dos servidores: al que te conectaste (el proxy/gateway) y el que está detrás (el upstream/origen) que no logró responder. Los proxies más comunes incluyen Nginx como proxy reverso, Cloudflare, AWS Application Load Balancer (ALB) y CloudFront.

Cómo se ve el error 504

El texto depende de la capa que se rindió:

• 504 Gateway Time-out con «nginx» debajo: nginx (lo escribe con guion)
• 504 Gateway Time-out · The server didn't respond in time.: la página por defecto de HAProxy
• Gateway Timeout · The gateway did not receive a timely response from the upstream server or application.: Apache delante de PHP-FPM (mod_proxy_fcgi). Si Apache hace de proxy de un backend HTTP, muestra en su lugar Proxy Error · Error reading from remote server (un 502).
• ERROR · The request could not be satisfied · 504 ERROR: Amazon CloudFront
• Error 524: A timeout occurred: la versión de Cloudflare; llegó a tu servidor, pero la respuesta no llegó a tiempo
• Esta página no funciona · example.com ha tardado demasiado tiempo en responder. · Error de HTTP 504: Chrome, cuando el 504 no trae página propia

Sea cual sea el texto, la causa es la misma: un proxy esperó al servidor que tiene detrás y la respuesta no llegó a tiempo. (Chrome usa la misma frase «ha tardado demasiado tiempo en responder» cuando tu navegador no pudo conectar en absoluto, pero entonces el título es «No se puede acceder a este sitio web» y el código es ERR_CONNECTION_TIMED_OUT, no Error de HTTP 504: consulta ERR_CONNECTION_TIMED_OUT.)

Cómo ocurre el error 504 Gateway Timeout

Para entender el error 504, necesitas comprender la cadena de timeout entre tu navegador y el servidor de origen. Una solicitud web típica pasa por múltiples capas, y cada capa tiene su propia configuración de timeout.

Este es un flujo típico de una petición: Navegador → CDN (Cloudflare) → Balanceador de carga → Nginx → PHP-FPM → Base de datos. Si la consulta a la base de datos tarda 90 segundos y el fastcgi_read_timeout de nginx es de 60 segundos, nginx deja de esperar y devuelve un 504 al balanceador, que lo pasa de vuelta por el CDN hasta tu navegador.

El servidor que devuelve el 504 suele ser un proxy intermedio, no la propia aplicación. La aplicación puede seguir trabajando en la petición, o puede estar atascada.

Fuentes: Cloudflare 524, ajustes de origen de CloudFront, Google Cloud y la documentación de cada servidor. El max_execution_time de PHP (30 segundos) no produce un 504: un script que lo alcanza se detiene con un error fatal, que se ve como un 500. Y en Linux no cuenta el tiempo de espera a la base de datos ni a otras operaciones de E/S, así que un script atascado en una consulta lenta puede durar mucho más.

Causas comunes del error 504 Gateway Timeout

Los motivos habituales por los que un proxy se cansa de esperar:

• Una petición lenta: una consulta pesada a la base de datos, un informe o una llamada a una API de terceros lenta tarda más que el timeout del proxy.
• Un servidor sobrecargado: CPU al 100 %, falta de memoria o todos los workers de PHP-FPM ocupados, de modo que las peticiones nuevas esperan en cola hasta que el proxy se rinde.
• Cuellos de botella en la base de datos: consultas lentas, índices que faltan, tablas bloqueadas o un pool de conexiones agotado.
• Timeouts demasiado bajos: los 60 segundos de nginx se quedan cortos para un backend que legítimamente necesita más (una exportación, una importación, una subida grande).
• Problemas de red entre el proxy y el origen: pérdida de paquetes o un firewall que descarta en silencio los paquetes del proxy (un firewall que los rechaza da un 502).
• El límite fijo de un CDN: Cloudflare espera 125 segundos en Free, Pro y Business, permita lo que permita tu nginx, y luego muestra el Error 524.
• Una avalancha de tráfico: un pico o un ataque satura los workers y las peticiones normales no se responden a tiempo. (Un servidor que sabe que está sobrecargado puede responder con un 503.)

Solución para visitantes: qué puedes hacer

Si ves un error 504 en el sitio web de otra persona, el problema está en su servidor — no en tu dispositivo. Sin embargo, hay algunas cosas que vale la pena intentar.

• Espera un minuto y recarga: muchos 504 duran solo lo que dura un momento de ajetreo en el servidor.
• Comprueba si está caído para todos: el Website Down Checker abre la página desde 11 lugares. Si ellos también reciben un 504, es del sitio.
• Prueba otra red: datos móviles en lugar de Wi-Fi, o sin VPN, por si el proxy o la VPN que usas es el gateway que agota el tiempo.
• Mira la página de estado o las redes sociales del sitio: los sitios con mucho tráfico suelen avisar de las caídas.

Solución 1: aumentar configuraciones de Timeout (Nginx y Apache)

La solución más común para errores 504 es aumentar los valores de timeout en tu proxy reverso. Si tu backend legítimamente necesita más de 60 segundos (el valor predeterminado), el proxy necesita saber que debe esperar más.

# nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_read_timeout 300;
    proxy_send_timeout 300;
}

# nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    include fastcgi_params;
}

# Leave proxy_connect_timeout / fastcgi_connect_timeout at their defaults:
# nginx caps them at about 75 seconds, and a dead backend should fail fast.

En Apache, añade ProxyTimeout 300 en tu VirtualHost o usa ProxyPass / http://backend:8080/ timeout=300 para un solo backend.

Importante: los timeouts de lectura y de envío miden el intervalo entre dos operaciones de lectura o escritura consecutivas, no el tiempo total de la transferencia. Así, proxy_read_timeout 300 significa «si no llegan datos durante 300 segundos», no «la respuesta entera debe terminar en 300 segundos». Recarga tras cambiarlos: sudo nginx -t && sudo systemctl reload nginx.

Detrás de un CDN, su propio límite sigue vigente: Cloudflare corta a los 125 segundos (de Free a Business) y CloudFront a los 30 por defecto, así que subir nginx por encima no cambia nada para los visitantes que llegan por el CDN.

Solución 2: optimizar scripts lentos y consultas a la base de datos

Si tu backend consistentemente excede el timeout, aumentar el valor del timeout solo enmascara el problema. La solución real es hacer que el backend responda más rápido.

• Encuentra consultas lentas — Activa el log de consultas lentas de MySQL (slow_query_log = 1, long_query_time = 1) o usa EXPLAIN ANALYZE en las consultas sospechosas. Agrega índices faltantes, evita SELECT * y pagina conjuntos de resultados grandes.
• Agrega caché — Usa Redis o Memcached para almacenar en caché resultados de consultas costosas. Una consulta que tarda 5 segundos en cada carga de página debería estar en caché.
• Mueve trabajo pesado a tareas en segundo plano — Generación de reportes, envío de correos, procesamiento de imágenes e importaciones de datos deben ejecutarse en una cola de tareas (Celery, Sidekiq, Bull), no en el ciclo de solicitud HTTP.
• Optimiza llamadas a APIs — Si tu backend llama APIs de terceros lentas, agrega timeouts a esas llamadas e implementa circuit breakers para que una API lenta no bloquee todas las solicitudes.
• Reduce consultas N+1 — Las consultas generadas por ORMs frecuentemente hacen cientos de llamadas individuales a la base de datos. Usa eager loading o consultas por lotes para reducir viajes de ida y vuelta.

Solución 3: verificar recursos del servidor (CPU, RAM, disco)

Si el servidor de origen está sobrecargado, no puede procesar solicitudes lo suficientemente rápido, y el proxy expira esperando. Verifica qué está consumiendo recursos.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Check active network connections
ss -s

Si la CPU o RAM está al 90%+, necesitas optimizar tu aplicación, terminar procesos fuera de control o actualizar tu servidor. Si el espacio en disco está lleno, limpia archivos de log antiguos, respaldos o archivos temporales — un disco lleno puede hacer que las bases de datos fallen silenciosamente y causar errores 504 en cascada.

Solución 4: revisar logs de error

Los logs de error te dicen exactamente por qué el proxy devolvió 504. Siempre revisa los logs antes de adivinar la causa.

# Nginx error log (look for "upstream timed out")
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log       # Debian/Ubuntu
tail -50 /var/log/httpd/error_log          # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.3-fpm.log

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Mensajes de log habituales detrás de un 504:

«upstream timed out (110: Connection timed out) while reading response header from upstream» (nginx): el backend tardó más que proxy_read_timeout (o fastcgi_read_timeout). Acelera el backend o sube el timeout si la espera es legítima.

«upstream timed out (110: Connection timed out) while connecting to upstream» (nginx): nginx ni siquiera pudo conectar a tiempo: un firewall que descarta paquetes o un backend demasiado ocupado para aceptar conexiones.

«server reached pm.max_children setting» (PHP-FPM): todos los workers están ocupados, así que las peticiones esperan en la cola. Sube pm.max_children solo si hay RAM para ello; si no, busca las peticiones lentas que retienen los workers.

«Too many connections» (MySQL): se agotó el límite de conexiones. Las conexiones nuevas fallan al instante (un 500, como el «Error establishing a database connection» de WordPress), mientras que las consultas que las retienen suelen ser las lentas detrás de tus 504.

Solución 5: ajustar configuraciones de PHP-FPM

En las apps PHP (WordPress, Laravel, Magento), mantén los timeouts encadenados, cada capa un poco más larga que la de detrás: el fastcgi_read_timeout de nginx ≥ el request_terminate_timeout de PHP-FPM ≥ el max_execution_time de PHP.

Tras cambiar los ajustes de PHP-FPM, reinícialo (sudo systemctl restart php8.3-fpm, ajustando la versión). Si el fastcgi_read_timeout de nginx es más corto que los límites de PHP, nginx se rinde primero y los visitantes ven un 504 mientras PHP sigue trabajando.

Solución 6: verificar configuración del CDN y proxy

Si tu sitio está detrás de un CDN como Cloudflare o AWS CloudFront, el CDN tiene sus propios ajustes de timeout que pueden imponerse a la configuración de tu servidor.

Cloudflare: en Free, Pro y Business, si tu origen no ha empezado a responder en 125 segundos, Cloudflare se rinde y muestra el Error 524 (Cloudflare). El consejo del propio Cloudflare: acelera la petición, pasa los trabajos largos a segundo plano o sírvelos desde un subdominio solo DNS (nube gris); los planes Enterprise pueden subir el límite.

CloudFront: sube el response timeout del origen en los ajustes de origen de la distribución (AWS). AWS recomienda arreglar primero el origen lento. En peticiones GET y HEAD, CloudFront reintenta el origen (3 intentos de conexión por defecto), así que el origen puede ver la misma petición varias veces antes de que el visitante reciba el 504.

Para saber qué capa envió el 504, mira los encabezados de respuesta en el HTTP Header Checker: server: awselb/2.0 es un balanceador de AWS, x-cache: Error from cloudfront es CloudFront y server: nginx es nginx. Detrás de Cloudflare todas las respuestas dicen server: cloudflare, así que ahí la pista es el propio código (524 o 504).

Solución 7: soluciones específicas para WordPress

Los sitios WordPress son particularmente propensos a errores 504 debido a plugins pesados, sobrecarga en la base de datos y límites de hosting compartido. Estas son soluciones específicas.

• Identifica plugins lentos — Desactiva todos los plugins y reactívalos uno por uno. Si no puedes acceder a wp-admin, renombra la carpeta plugins vía SSH: mv wp-content/plugins wp-content/plugins_disabled. Usa el plugin Query Monitor para identificar consultas lentas a la base de datos.
• Instala un plugin de caché — WP Super Cache, W3 Total Cache o WP Rocket reducen el procesamiento del servidor al servir HTML estático en lugar de ejecutar PHP en cada solicitud.
• Usa caché de objetos — Instala Redis o Memcached y un plugin de object cache para WordPress. Esto almacena en caché los resultados de consultas a la base de datos en memoria, reduciendo la carga de MySQL.
• Limpia la base de datos — Elimina revisiones antiguas de publicaciones, transients, comentarios de spam y metadatos huérfanos. Usa WP-Optimize o WP-Sweep. Agrega define('WP_POST_REVISIONS', 5); para limitar revisiones futuras.
• Pasa wp-cron a un cron real — las visitas a la página activan WP-Cron, que ejecuta las tareas pendientes en una petición loopback que ocupa un worker de PHP propio. Añade define('DISABLE_WP_CRON', true); a wp-config.php y haz que el servidor ejecute wp cron event run --due-now cada 5 minutos.

504 vs 502 vs 503 vs 408: ¿cuál es la diferencia?

Estos códigos de error HTTP se confunden a menudo. Esto es lo que significa realmente cada uno.

La distinción clave: un 502 significa que el proxy recibió una respuesta rota, o que la conexión fue rechazada o cerrada; un 504 significa que el temporizador del proxy se agotó mientras el upstream seguía en silencio. Un 503 no necesita proxy: cualquier servidor puede enviarlo cuando está sobrecargado. Un 408 es un timeout del lado del cliente (clase 4xx), en el que el servidor se cansó de esperar al cliente.

Si ves 502 y 504 a la vez, el backend probablemente está sufriendo: las peticiones que agotan el tiempo dan 504 y los workers que se caen o los matan dan 502.

Si te sale el 502 y no el 504, nuestra guía del 502 Bad Gateway repasa los mensajes del log de errores de nginx que lo explican, incluido un caso real de este sitio.

¿El error 504 afecta el SEO?

La documentación de Google describe qué hacen los errores 5xx (documentación de Google sobre rastreo):

• El rastreo se ralentiza en todo el sitio, en proporción al número de URL que devuelven errores de servidor.
• Las páginas indexadas se mantienen al principio, pero las URL que devuelven un error de servidor de forma persistente acaban eliminándose.
• El rastreo se recupera poco a poco cuando el servidor vuelve a responder con 2xx.

Cómo prevenir errores 504 Gateway Timeout

La prevención es mejor que apagar incendios. Estas prácticas mantendrán tu servidor respondiendo dentro de los límites de timeout.

• Configura monitorización — un monitor de disponibilidad que cargue las páginas clave cada pocos minutos detecta los 504 antes de que te avisen tus usuarios.
• Alinea tu cadena de timeout — Asegúrate de que timeout del CDN ≥ timeout del proxy ≥ timeout de la aplicación. Valores desalineados causan errores 504 impredecibles.
• Implementa health checks — Los balanceadores de carga y proxies deben verificar la salud de los servidores upstream y redirigir el tráfico lejos de instancias que no responden.
• Usa caché agresivamente — Almacena en caché activos estáticos, respuestas de API y consultas a la base de datos. Una respuesta en caché nunca es lo suficientemente lenta para causar un 504.
• Auto-escala — Usa escalamiento horizontal (más instancias) para que los picos de tráfico no sobrecarguen un solo servidor.
• Mueve trabajo pesado a segundo plano — Mueve procesamiento de archivos, generación de reportes, envío de correos e importaciones masivas a colas de tareas en segundo plano. Nunca hagas trabajo pesado dentro de una solicitud HTTP.
• Monitorea consultas lentas — Activa el log de consultas lentas en MySQL/PostgreSQL. Configura alertas para consultas que excedan 1 segundo.
• Mantén las dependencias saludables — Monitorea las APIs de terceros de las que depende tu backend. Agrega timeouts y circuit breakers para que una API lenta no cause errores 504 en cascada para todos los usuarios.