504 Gateway Timeout detrás de Cloudflare

Qué significa este error y cómo reconocerlo

• La página de error muestra la marca de Cloudflare y normalmente incluye un Cloudflare Ray ID en lugar del diseño de error habitual de tu sitio.
• Un informe, una exportación, una carga, una llamada a la API o una acción masiva concreta falla mientras las páginas normales siguen cargando.
• La misma solicitud puede responder lentamente, agotar el tiempo de espera o fallar cuando se prueba directamente contra el origen.
• El problema puede ser intermitente cuando el origen está sobrecargado, o constante cuando Cloudflare no puede alcanzar el origen configurado.
• Los logs de la aplicación o del servidor web pueden mostrar que la solicitud comenzó, pero no se completó antes del timeout visible para el cliente.

Causas principales, ordenadas por probabilidad

1. El origen tarda demasiado. Una consulta de base de datos, un informe, una exportación, una carga u otra operación síncrona puede superar el tiempo que Cloudflare está dispuesto a esperar.
2. La solicitud alcanza un límite de timeout de Cloudflare. El límite aplicable depende de la solicitud, la configuración de la cuenta y el plan. Aumentar el timeout del servidor web de origen no amplía el límite del edge de Cloudflare.
3. Cloudflare no puede alcanzar el origen de forma fiable. Las reglas del firewall, los fallos de red, un destino DNS incorrecto, un servicio no disponible o la saturación de conexiones pueden impedir una respuesta a tiempo.
4. El endpoint no es adecuado para el proxy. Una API interna o especializada puede requerir un diseño DNS-only cuidadosamente controlado en lugar de pasar por el proxy de Cloudflare.
5. La configuración de SSL/TLS no coincide con el origen. Revisa el certificado del origen, el hostname y la validez del certificado cuando uses Full (strict). Los problemas de certificados pueden producir otros errores de origen de Cloudflare, así que confirma la respuesta exacta en lugar de asumir que cualquier problema de SSL es un 504.

Cómo solucionarlo

1. Confirma que Cloudflare generó la respuesta

Inspecciona la página de error para comprobar si muestra la marca de Cloudflare y un Ray ID, y compárala con la página de error normal de tu aplicación. Si Cloudflare generó la página, cambiar únicamente el manejo de errores de la aplicación no resolverá el problema entre el edge y el origen.

2. Define el alcance y el momento

Registra el hostname y la ruta exactos, el método HTTP, la acción del usuario, la hora aproximada de inicio y si el problema afecta a todos los visitantes o a una sola operación. Comprueba si las páginas normales funcionan mientras falla un informe, una exportación o una solicitud a la API.

Un fallo limitado a una operación costosa apunta más claramente a la duración del backend. Los fallos en solicitudes normales y rápidas apuntan más a la accesibilidad del origen, la capacidad o la configuración.

3. Prueba el origen de forma independiente

Usa una prueba directa autorizada contra el origen que conserve el hostname requerido, la cabecera Host, el comportamiento de TLS, la autenticación y el enrutamiento. Un hostname temporal de prueba con DNS-only puede ser útil si se configura de forma segura y el acceso al origen sigue estando restringido adecuadamente.

• El origen también es lento o falla: inspecciona los logs de la aplicación, las consultas a la base de datos, la capacidad de los workers, las dependencias externas, la carga del servidor y la saturación de conexiones.
• El origen es rápido, pero el hostname público devuelve 504: investiga el acceso del firewall entre Cloudflare y el origen, el DNS, la configuración de SSL/TLS, el estado del proxy y el endpoint afectado.
• La prueba directa no es representativa: repítela con la misma autenticación, el enrutamiento basado en hostname, las cabeceras y los demás requisitos utilizados por la solicitud que falla.

4. Corrige una operación realmente lenta

Para un informe, una exportación, una acción masiva u otra tarea de larga duración, evita mantener abierta una sola solicitud del navegador hasta que termine todo el trabajo. Pasa la operación a un proceso en segundo plano, muestra un estado de procesamiento y permite que el usuario obtenga el resultado mediante polling o una notificación de finalización.

Mide también las consultas a la base de datos, las trazas de la aplicación, las llamadas externas, la profundidad de la cola y el uso de recursos. No consideres aumentar el timeout del origen como solución principal sin medir la operación: si Cloudflare alcanza primero su límite, el visitante seguirá recibiendo un error mientras el origen puede continuar realizando trabajo innecesario.

5. Revisa el timeout aplicable de Cloudflare

Consulta la cuenta de Cloudflare y la documentación relevante para comprobar el timeout aplicable a la solicitud y al plan afectados. Si el trabajo es válido, pero no puede completarse dentro de un límite fijo, las opciones prácticas son rediseñarlo como trabajo asíncrono o utilizar una configuración de cuenta y un plan que admitan el timeout necesario, cuando estén disponibles.

6. Comprueba la accesibilidad cuando los fallos sean persistentes

Si también fallan las solicitudes normales y rápidas, verifica lo siguiente:

• El registro DNS apunta a la dirección actual del origen.
• El firewall del origen permite el tráfico de Cloudflare según sea necesario, sin exponer servicios innecesarios.
• El servidor web escucha en el puerto esperado y acepta el hostname solicitado.
• El origen tiene capacidad suficiente y no descarta ni pone en cola las conexiones.
• El modo SSL/TLS coincide con el certificado del origen, el hostname y la validez del certificado, especialmente con Full (strict).
• El registro afectado está pensado para pasar por el proxy, en lugar de servirse mediante una configuración DNS-only controlada.

Realiza cambios en el DNS, el firewall, SSL/TLS o el proxy solo con la autorización adecuada y un plan de reversión. Vuelve a probar el endpoint exacto que falla después de cada cambio relevante para que la relación entre causa y efecto siga siendo clara.

7. Escala el problema con pruebas útiles

Si el origen está sano y responde rápidamente mediante una prueba directa equivalente, recopila el Ray ID, la fecha y hora con la zona horaria, el hostname, la ruta, el método de solicitud, la zona de Cloudflare afectada y los resultados de la prueba directa. Entrega esta información al administrador de la cuenta de Cloudflare o al contacto de soporte para que pueda investigarse el comportamiento entre el edge y el origen.

Prevención y cómo verificar la solución

• Mide por separado el tiempo de respuesta del origen y la duración total de la solicitud, sin confundirlos con la disponibilidad visible a través de Cloudflare.
• Ejecuta los informes, las exportaciones, las cargas y las operaciones masivas de larga duración predecibles mediante procesos en segundo plano, con un progreso o estado de finalización visible.
• Configura alertas para detectar aumentos de latencia del origen, fallos de conexión, saturación de recursos y profundidad de las colas antes de que los usuarios sufran timeouts.
• Mantén los registros DNS, las reglas del firewall del origen y las listas de permitidos del tráfico de Cloudflare bajo control de cambios.
• Supervisa la validez del certificado del origen y la cobertura de hostname cuando uses Full (strict), y revisa los cambios de SSL/TLS antes del despliegue.
• Documenta qué endpoints deben usar el proxy de Cloudflare y cuáles requieren un diseño DNS-only controlado.
• Vuelve a probar la conectividad representativa con el origen después de realizar cambios en la infraestructura, el DNS, el firewall, los certificados o el proxy.

Preguntas frecuentes