Un proxy no recibió respuesta a tiempo.
Cuándo usarlo
La aplicación de origen es demasiado lenta o está colgada.
Causas habituales y soluciones
El proxy se cansó de esperar al upstream. Causas típicas: una consulta lenta a la base de datos o una llamada lenta a una API externa, un worker bloqueado por un deadlock, muy pocos workers para el tráfico, o un firewall que descarta paquetes sin avisar. Los tiempos de espera van por capas, y gana el más corto: proxy_read_timeout de nginx es de 60 segundos por defecto, AWS ALB corta por inactividad a los 60, API Gateway a los 29, y Cloudflare muestra su propio 524 a los 100 segundos.
Averigua en qué se va el tiempo: revisa en los logs de la aplicación la duración de las solicitudes, busca consultas lentas y mide la misma solicitud directamente contra el origen, sin pasar por el proxy. Aumentar los tiempos de espera solo oculta el problema; pasa las tareas largas a un worker en segundo plano y devuelve 202 con una URL de estado. El trabajo puede terminar igualmente después del 504, así que reintentar solicitudes no idempotentes puede duplicarlo.
Error del servidor (5xx)
Los códigos 5xx son errores del servidor: puede que la solicitud sea correcta, pero el servidor o algo detrás de él ha fallado. Conviene configurar alertas para ellos.
Cómo se ve
HTTP/1.1 504 Gateway TimeoutCómo enviarlo
| Node.js / Express | res.status(504).end() |
|---|---|
| Python / Flask | return '', 504 |
| nginx | return 504; |
Cómo comprobarlo
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/