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.

La definición oficial proviene de la RFC 9110 (HTTP Semantics), Sección 15.6.5, que establece: "El código de estado 504 (Gateway Timeout) indica que el servidor, mientras actuaba como gateway o proxy, no recibió una respuesta oportuna de un servidor upstream al que necesitaba acceder para completar la solicitud."

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 mensaje de error 504 varía según el navegador, servidor web y CDN. Estas son las mensajes más comunes que encontrarás.

• 504 Gateway Timeout

• 504 Gateway Time-out (predeterminado de Nginx — usa guión)

• HTTP Error 504 — Gateway Timeout

• Esta página no funciona — [dominio] tardó demasiado en responder (Chrome / Edge)

• Gateway Timeout (Firefox)

• Error 504

• 504 Gateway Time-out — The server didn't respond in time (Apache con mod_proxy)

• Error 524: A timeout occurred (específico de Cloudflare — técnicamente no es 504, pero la causa raíz es la misma)

• ERROR — The request could not be satisfied — 504 ERROR (AWS CloudFront)

Sin importar el texto mostrado, la causa subyacente siempre es la misma: un servidor proxy esperó a que el servidor upstream respondiera y el upstream no respondió dentro de la ventana de timeout configurada.

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 de solicitud típico: 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 proxy_read_timeout de Nginx está configurado en 60 segundos, Nginx deja de esperar y devuelve un 504 al balanceador de carga, que lo pasa de vuelta a tu navegador.

El servidor que devuelve el 504 siempre es el intermediario (proxy o gateway), nunca el servidor de origen en sí. El servidor de origen simplemente no respondió a tiempo — puede que aún esté procesando la solicitud, o puede haberse caído completamente.

Causas Comunes del Error 504 Gateway Timeout

Entender la causa raíz es el camino más rápido hacia la solución. Estas son las razones más comunes por las que un servidor devuelve 504, ordenadas por frecuencia.

• Servidor de origen lento — Scripts PHP ejecutando consultas complejas a la base de datos, generando reportes o llamando APIs de terceros lentas pueden exceder el timeout del proxy. Esta es la causa #1 de los errores 504.

• Sobrecarga del servidor — CPU al 100%, sin memoria (OOM kills) o todos los workers de PHP-FPM ocupados. El servidor de origen está activo pero demasiado saturado para responder a tiempo.

• Cuello de botella en la base de datos — Consultas SQL lentas, índices faltantes, bloqueos de tablas o pools de conexiones agotados. La aplicación se congela esperando la base de datos, y el proxy expira.

• Valores de timeout mal configurados — proxy_read_timeout de Nginx configurado muy bajo para un backend que legítimamente necesita más tiempo (ej: generador de reportes o manejador de carga de archivos).

• Problemas de red entre proxy y origen — Pérdida de paquetes, alta latencia o problemas de enrutamiento entre centros de datos. Común en configuraciones multi-región o nube híbrida.

• Firewall o security group bloqueando tráfico — Security groups de AWS no permitiendo tráfico en puertos efímeros, reglas de iptables bloqueando conexiones internas o un WAF bloqueando solicitudes upstream legítimas.

• Falla de resolución DNS en el proxy — El proxy no puede resolver el hostname del upstream. En Nginx, esto ocurre al usar variables en proxy_pass sin una directiva resolver.

• Timeout del CDN — Cloudflare tiene un límite fijo de 100 segundos en los planes Free/Pro/Business. Si tu servidor de origen tarda más de 100 segundos, Cloudflare devuelve Error 524 sin importar tu configuración de Nginx.

• Ataque DDoS — Una avalancha de solicitudes agota los recursos del servidor, haciendo que el origen sea demasiado lento para responder al tráfico legítimo dentro de la ventana de timeout del proxy.

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 y actualiza — La mayoría de los errores 504 son temporales. Espera 30-60 segundos, luego fuerza la actualización de la página con Ctrl+Shift+R (Windows/Linux) o Cmd+Shift+R (Mac).

• Verifica si el sitio está caído para todos — Usa la herramienta de HTTP Headers de DNS Robot para verificar el código de respuesta del servidor desde una ubicación externa. Si devuelve 504 para todos, el problema es del servidor.

• Prueba en modo incógnito o con otro navegador — Esto descarta extensiones del navegador, páginas de error en caché y problemas de configuración local.

• Prueba una red diferente — Cambia de Wi-Fi a datos móviles, o desactiva tu VPN. Problemas de enrutamiento entre tu proveedor de internet y el servidor pueden a veces causar 504.

• Limpia tu caché DNS — Registros DNS obsoletos pueden dirigir solicitudes al servidor equivocado. En Windows: ipconfig /flushdns. En Mac: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

• Revisa la página de estado o redes sociales del sitio — El sitio puede haber publicado sobre una caída conocida o ventana de mantenimiento.

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_connect_timeout 300;
    proxy_send_timeout    300;
    proxy_read_timeout    300;
    send_timeout          300;
}

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

Para Apache con mod_proxy, agrega ProxyTimeout 300 en tu VirtualHost o usa ProxyPass / http://backend:8080/ timeout=300 para configuración por backend.

Importante: Estos timeouts miden el tiempo entre dos operaciones de lectura/escritura consecutivas, no el tiempo total de transferencia. Entonces proxy_read_timeout 300 significa "si no llegan datos durante 300 segundos", no "la respuesta completa debe terminar en 300 segundos." Después de cambiar los valores de timeout, recarga la configuración: sudo nginx -t && sudo systemctl reload nginx.

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.2-fpm.log

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

Mensajes comunes en los logs que causan 504:

"upstream timed out (110: Connection timed out)" (Nginx) — El servidor upstream no respondió dentro del proxy_read_timeout. Aumenta el timeout o soluciona el upstream lento.

"server reached pm.max_children" (PHP-FPM) — Todos los procesos worker de PHP están ocupados. Aumenta pm.max_children en la configuración del pool de PHP-FPM.

"connect() failed (111: Connection refused)" (Nginx) — El servidor upstream no está corriendo o no está escuchando en el puerto esperado. Reinicia el backend.

"Too many connections" (MySQL) — El límite de conexiones de la base de datos se agotó. Aumenta max_connections en la configuración de MySQL u optimiza el pool de conexiones.

Solución 5: Ajustar Configuraciones de PHP-FPM

Después de cambiar las configuraciones de PHP-FPM, reinicia el servicio: sudo systemctl restart php8.2-fpm. Asegúrate de que el fastcgi_read_timeout de Nginx sea siempre mayor o igual al max_execution_time de PHP. De lo contrario, Nginx se rinde antes de que PHP termine, creando un error 504.

Solución 6: Verificar Configuración del CDN y Proxy

Usuarios de Cloudflare: Si estás en un plan Free, Pro o Business y tu servidor de origen tarda más de 100 segundos, siempre recibirás Error 524. Las únicas opciones son: optimizar tu backend para responder dentro de 100 segundos, mover tareas largas a trabajos en segundo plano, o actualizar a Enterprise.

Usuarios de AWS CloudFront: Aumenta el timeout de respuesta de origen en las configuraciones de origen de tu distribución. El valor predeterminado de 30 segundos a menudo es demasiado bajo para contenido dinámico.

Usa la herramienta de HTTP Headers de DNS Robot para verificar los encabezados de respuesta e identificar qué capa está devolviendo el 504. Busca encabezados como server: cloudflare, server: awselb/2.0 o server: nginx para identificar el proxy.

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.

• Aumenta la memoria PHP — Agrega define('WP_MEMORY_LIMIT', '512M'); a wp-config.php. Muchos plugins necesitan más que los 128MB predeterminados.

• 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.

• Desactiva wp-cron — El cron virtual de WordPress se ejecuta en cada carga de página y puede acumular tareas. Agrega define('DISABLE_WP_CRON', true); a wp-config.php y configura un cron job real en el servidor: */5 * * * * curl -s https://tusitio.com/wp-cron.php > /dev/null 2>&1.

504 vs 502 vs 503 vs 408: ¿Cuál Es la Diferencia?

La distinción crítica: el 502 significa que el proxy recibió una respuesta mala, mientras que el 504 significa que el proxy no recibió ninguna respuesta. El 503 no requiere un proxy — cualquier servidor puede devolverlo cuando está sobrecargado. El 408 es un timeout del lado del cliente (clase 4xx), donde el servidor se cansó de esperar al cliente.

Si ves un 502 y un 504 al mismo tiempo, el servidor upstream probablemente se está cayendo. El 502 ocurre cuando el proxy recibe una respuesta parcial o corrupta de un proceso que está muriendo, y el 504 ocurre cuando el proceso está completamente sin respuesta.

¿El Error 504 Afecta el SEO?

Respuesta corta: un 504 breve no tiene impacto en el SEO. Un 504 prolongado puede causar desindexación.

Minutos a horas: Sin impacto. Google entiende los errores temporales del servidor y no penaliza inmediatamente. Si Googlebot no rastrea durante la caída, ni siquiera lo notará.

Horas a días: Google reduce la frecuencia de rastreo para sitios que devuelven errores 5xx para evitar agregar carga a un servidor con problemas. Las páginas pueden aparecer como "Error del servidor (5xx)" en el informe de Indexación de Páginas de Google Search Console.

Días a semanas: Los errores 504 persistentes pueden llevar a la desindexación de las páginas afectadas. Los rankings bajan significativamente. Según John Mueller de Google: si un servidor está caído por un día, las cosas pueden estar "en flujo" durante una a tres semanas después de la recuperación.

Recuperación: Una vez que el servidor es estable nuevamente, Google re-rastrea y re-indexa las páginas automáticamente. Usa la herramienta de Inspección de URL de Google Search Console para solicitar la reindexación de páginas importantes. El tiempo de recuperación depende del tamaño del sitio y cuánto tiempo duraron los errores.

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 monitoreo — Usa monitoreo de uptime (UptimeRobot, Pingdom o la herramienta Ping de DNS Robot) para detectar errores 504 antes de que tus usuarios los reporten.

• 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.