¿Qué es el Error 504 (Gateway Timeout)?

El 504 apareció en el RFC 2068, la especificación de HTTP/1.1 de enero de 1997. El RFC 1945 de HTTP/1.0, de mayo de 1996, ya tenía el 502, pero no el 504. Hoy lo define el RFC 9110, de junio de 2022, en el apartado 15.6.5: la pasarela «did not receive a timely response» del servidor que necesitaba.

La cadena de pasarelas está explicada en la entrada sobre el error 502. El texto varía según el software (nginx titula su página «504 Gateway Time-out»), pero el código es el mismo.

Cada capa que reenvía una petición decide cuánto espera a la siguiente. Si la aplicación tarda más, esa capa corta y responde con un 504. Cloudflare cita como motivos una consulta de datos grande, un proceso largo o un servidor sin recursos.

Valores por defecto según cada fabricante (consultados el 13.11.2026):

• nginx: 60 segundos en proxy_read_timeout y fastcgi_read_timeout, contados entre dos lecturas.
• Apache httpd: ProxyTimeout toma el valor de TimeOut, 60 segundos.
• AWS Application Load Balancer: 60 segundos de inactividad (idle timeout) y 10 para abrir la conexión.
• Amazon CloudFront: 30 segundos de espera por la respuesta del origen; en peticiones GET y HEAD lo vuelve a intentar hasta tres veces.
• Cloudflare: 125 segundos; en el plan Enterprise, hasta 6.000.
• PHP: 30 segundos en max_execution_time, que fuera de Windows mide tiempo de CPU; la espera a la base de datos no cuenta.

Gana el límite más corto. Con nginx a 60 segundos y CloudFront a 30, corta antes CloudFront. En una petición POST, el visitante ve su 504 a los 30 segundos; en GET y HEAD, CloudFront repite el intento hasta tres veces y el 504 llega hacia los 90. Subir el límite en una capa no sirve si delante hay otra que corta antes.

Cloudflare responde de otra forma: cuando se agotan sus 125 segundos, devuelve un 524, un código propio que el RFC 9110 no define.

Una misma capa puede dar el 504 por motivos distintos. Para su balanceador, AWS enumera estos: no abre la conexión en 10 segundos, el destino no responde antes del tiempo de inactividad, una función Lambda no contesta o el destino anuncia más bytes de los que envía.

CloudFront también devuelve un 504 cuando un cortafuegos bloquea su tráfico hacia el origen o el origen no es accesible desde internet. Ahí no hay aplicación lenta: la petición no llega.

En Cloudflare, un 504 con su logotipo viene del servidor de origen; una página en blanco sin logotipo la generó Cloudflare.

Ejemplo de cálculo: una tienda online con Cloudflare delante y nginx con PHP-FPM detrás exporta los pedidos del año, y la consulta tarda 90 segundos sin enviar nada. A los 60, nginx devuelve un 504, que aparece con el logotipo de Cloudflare porque viene del origen.

El administrador sube fastcgi_read_timeout a 180 segundos y la exportación funciona. Cuando el archivo crece y la consulta pasa de 125 segundos, el error vuelve como 524, porque ahora salta el límite de Cloudflare. Cloudflare propone para esos procesos un subdominio sin proxy.

La duración delata la capa. curl con la opción -w y las variables %{http_code} y %{time_total} muestra código y segundos. Con los valores por defecto, un 504 a los 30 segundos en una petición POST, o hacia los 90 en GET y HEAD por los tres intentos, apunta a CloudFront, uno a los 60 a nginx o a un balanceador de AWS, y un 524 hacia los 125 a Cloudflare. AWS propone medir además el tiempo hasta el primer byte, el TTFB, en cada servidor.

El registro lo confirma: cuando se agota el plazo, nginx anota «upstream timed out», según su código fuente.

En Search Console, las estadísticas de rastreo separan «Error del servidor (5XX)», donde cae el 504, de los casos en que «se ha agotado el tiempo de espera de la solicitud de la página».

Un límite largo deja terminar procesos lentos; uno corto enseña antes el error. AWS recomienda que el tiempo de inactividad de la aplicación sea mayor que el del balanceador: si la aplicación cierra antes la conexión, el balanceador puede devolver un 502.

Para el SEO, el 504 sigue la regla general de los 5xx: la documentación de Google sobre códigos de estado (4 de febrero de 2026) describe aparte el 500, el 502 y el 503, pero no el 504. Los rastreadores bajan el ritmo, ignoran el contenido y conservan las URL indexadas, «but eventually dropped», sin plazo. El error que dura días se trata en la entrada sobre el error 503.

Distinto es que el servidor no conteste a Googlebot. Google trata los «network timeouts», las conexiones reiniciadas y los errores de DNS de forma parecida a los 5xx, pero sin respuesta no hay código de estado. Según su página sobre errores de red, el rastreo se frena de inmediato y las URL indexadas que no se alcanzan salen del índice «within days».

Fuente: RFC 9110 (junio de 2022); Cloudflare, «Error 524» (consultado el 13.11.2026).

El 500 es el fallo genérico del servidor, y el 503, sobrecarga o mantenimiento.

El RFC 9110 pide una respuesta «timely», pero no fija segundos. Con los valores por defecto, una respuesta que tarda 45 segundos da un 504 detrás de CloudFront y llega con normalidad detrás de Cloudflare.

Cloudflare define el 502 y el 504 de forma más amplia que el RFC: como «unable to establish contact» con el servidor de origen.

• Mide con curl cuántos segundos tarda el 504 y compáralos con los límites de cada capa.
• Busca la línea de esa hora en el registro del proxy y la petición lenta en el de la aplicación.
• Saca las tareas largas de la petición web, a una cola o a un cron, y consulta su estado por sondeo.
• Si una operación larga debe ir en la misma conexión, envía al menos un byte antes de que venza la inactividad, como recomienda AWS.
• Ajusta los límites solo después, de la aplicación hacia fuera, para que ninguna capa exterior corte antes.
• Tras el arreglo, revisa en Search Console el estado del host.
• Si solo visitas la página: recarga más tarde; si a otras personas les funciona, revisa tu VPN, proxy o DNS, como indica MDN.

• Registra en el origen el tiempo de respuesta de cada petición, como recomienda Cloudflare.
• Apunta en un documento el límite real de cada capa, de la CDN a PHP.

• Subir el límite de nginx con un CloudFront delante que corta a los 30 segundos.
• Buscar un 504 cuando Cloudflare muestra un 524.
• Dar por hecho que max_execution_time de PHP corta a los 30 segundos de reloj.
• Suponer que Google da un número fijo de días antes de retirar URL con 504.

Esta entrada se redactó en noviembre de 2026 con ayuda de IA, a partir de los RFC, la documentación de Google y Search Console y la de MDN, nginx, Apache, AWS, Cloudflare y PHP. Los límites se comprobaron el 13.11.2026. No contiene datos de clientes.