Error 522 de Cloudflare: connection timed out - causas y soluciones

Qué significa el error 522

Toda petición mediante proxy empieza con Cloudflare abriendo una conexión TCP con tu origen antes de poder enviar la propia petición HTTP. El error 522 salta cuando ese handshake, el SYN TCP y el SYN-ACK esperado de vuelta, no se completa dentro de la ventana de tiempo de espera de Cloudflare. El origen puede estar demasiado sobrecargado para aceptar conexiones nuevas, un firewall puede estar descartando los paquetes en silencio en lugar de rechazarlos, o la ruta de red entre Cloudflare y el origen puede estar congestionada.

Esto es distinto del error 521, donde el origen rechaza activamente la conexión, y del error 524, donde la conexión TCP se establece pero la propia respuesta HTTP nunca llega a tiempo. El error 522 es específicamente un fallo en la etapa del handshake, antes de que se llegue a enviar ninguna petición HTTP.

Cómo aparece el error 522

Los visitantes ven la página de Cloudflare, "Error 522: connection timed out", con un Ray ID. Una petición con curl contra el dominio muestra el mismo estado tras, aproximadamente, la ventana de tiempo de espera de Cloudflare:

curl -I https://example.com
HTTP/2 522

Como el handshake TCP nunca terminó, ninguna petición llegó a tu aplicación, así que los registros de la aplicación suelen estar vacíos para el periodo de fallo. Mira en su lugar las métricas a nivel de conexión: la carga y la CPU del servidor en el momento de los errores, el número de conexiones establecidas y en espera (ss -s o netstat -an | grep SYN_RECV), y los registros del firewall o del balanceador de carga por paquetes descartados o filtrados en el puerto correspondiente.

Qué causa el error 522

• El servidor de origen está sobrecargado y no puede aceptar conexiones nuevas con suficiente rapidez. Una CPU alta, una cola de conexiones pendientes llena, o un grupo de workers agotado, producen todos esto.
• Un firewall o un grupo de seguridad está descartando en silencio los paquetes SYN de Cloudflare en lugar de enviar un reset TCP. Un descarte silencioso parece idéntico a un servidor lento o caído desde el lado de Cloudflare, mientras que un reset produciría en su lugar el error 521.
• El keepalive TCP está desactivado en el origen, lo que aumenta la rotación de conexiones y la probabilidad de que un handshake nuevo llegue justo en un momento en que el servidor está demasiado ocupado para aceptarlo.
• La dirección IP del origen no está correctamente incluida en la lista blanca donde la red exige una lista blanca explícita en lugar de una simple regla de firewall, así que las peticiones de Cloudflare se filtran antes de llegar al socket que escucha.
• Congestión de red o pérdida de paquetes entre Cloudflare y el origen, más habitual en orígenes detrás de un hosting de gama de consumo o muy sobrecontratado.

522 frente a 524

Ambos códigos son tiempos de espera agotados, pero ocurren en puntos distintos de la petición. El error 522 ocurre antes de enviar ninguna petición HTTP: el propio handshake TCP nunca se completa. El error 524 ocurre después: la conexión TCP se establece y Cloudflare envía la petición HTTP, pero el origen no devuelve una respuesta completa dentro de 100 segundos. Un 524 suele apuntar a una aplicación lenta, por ejemplo un endpoint de generación de informes, una consulta a base de datos larga, o una petición disparada por un cron que legítimamente tarda minutos. La solución para un 524 casi siempre es acelerar el endpoint o sacar el trabajo lento del ciclo petición-respuesta hacia un trabajo en segundo plano que el cliente consulta para obtener un resultado; los planes Cloudflare Enterprise también pueden aumentar el límite de 100 segundos para rutas concretas, pero eso trata el síntoma y no el propio endpoint lento.

Cómo saber de quién es la culpa

Un 522 casi siempre se origina en el origen o cerca de él, ya que la propia red de Cloudflare tiene una disponibilidad muy alta y raramente es la fuente de un tiempo de espera del handshake. La pregunta útil es si el origen está completamente caído o solo está teniendo dificultades bajo carga desde ciertas regiones. La forma más rápida de comprobarlo es ejecutar una comprobación HTTP desde varias ubicaciones a la vez: la comprobación HTTP de HostTracker consulta el dominio desde puntos de control en varios países y reporta cada uno por separado, así que un patrón en el que algunas ubicaciones agotan el tiempo de espera y otras tienen éxito apunta a un servidor sobrecargado que atiende algunas peticiones pero no todas, mientras que un tiempo de espera agotado uniforme en todas partes apunta a que el origen está completamente caído o a un firewall que descarta todas las conexiones.

Cómo solucionar el error 522

Si eres un visitante

1. Recarga después de una breve espera. Un pico momentáneo de carga o un pequeño contratiempo de red a menudo se resuelve solo.
2. Revisa la página de estado del sitio, si tiene una, en busca de una incidencia conocida.
3. No hay nada que arreglar de tu lado. El tiempo de espera agotado ocurre entre Cloudflare y el propio servidor del sitio, no en tu navegador ni en tu conexión con Cloudflare.

Si administras el sitio

1. Revisa la carga del servidor y la capacidad de conexión disponible en el momento de los fallos: CPU, memoria, y los límites de conexión o de workers configurados en el servidor web (por ejemplo, worker_connections de nginx).
2. Confirma que tu firewall o grupo de seguridad permite los rangos de IP publicados de Cloudflare en el puerto correspondiente, y que rechaza con un reset en lugar de descartar los paquetes en silencio, lo que al menos convierte un 522 en un 521 más fácil de diagnosticar.
3. Activa el keepalive TCP en el servidor web del origen y en cualquier balanceador de carga que tengas delante, y comprueba que los ajustes de keepalive a nivel de sistema operativo no se han dejado en valores por defecto muchísimo más largos de lo que la conexión realmente necesita.
4. Si tu hosting o tu red en la nube exige una lista blanca de IP explícita separada del firewall, confirma que la IP del origen está en ella.
5. Cronometra el handshake en bruto directamente contra el origen, saltándote Cloudflare, para ver si el retraso está en llegar a tu servidor:

   curl -v -H "Host: example.com" --connect-timeout 5 https://ORIGIN_IP/

   Una conexión que se queda colgada aquí confirma que el propio origen es lento aceptando conexiones, y no algo específico de Cloudflare.
6. Para endpoints concretos lentos en lugar de un servidor sobrecargado en general, saca el trabajo de larga duración (informes, exportaciones, trabajos por lotes) de la ruta de la petición hacia un trabajo en segundo plano que el cliente consulta o del que recibe una notificación, y plantéate un aumento del tiempo de espera de Cloudflare Enterprise solo como parche temporal para rutas que no puedas acelerar rápido.

Cómo prevenirlo

Un servidor que solo falla su handshake bajo carga máxima pasará cualquier comprobación manual que hagas tú mismo, ya que es poco probable que lo pruebes justo en el momento exacto en que tiene dificultades. Una comprobación HTTP que se ejecuta según un horario desde fuera de tu red detecta esa ventana de fallo aunque nadie esté mirando, y ejecutarla desde varios países muestra si la ralentización es de capacidad global o de una ruta de red regional.

Errores relacionados

• Error 520 de Cloudflare: error desconocido - el origen respondió, pero la respuesta era inutilizable.
• Error 521 de Cloudflare: web server is down - el origen rechazó la conexión en lugar de no responder.
• Errores de servidor 5xx - la familia general de códigos de estado.
• 502 Bad Gateway - la versión no específica de Cloudflare de un fallo del upstream.

Preguntas frecuentes

¿Cuánto espera Cloudflare antes de mostrar el error 522?

Unos 15 segundos para el handshake TCP. Si el origen no ha aceptado la conexión para entonces, Cloudflare se rinde y devuelve 522 al visitante.

¿El 522 es lo mismo que mi servidor estando caído?

No siempre. También puede significar que el servidor está activo pero demasiado ocupado para aceptar una conexión nueva a tiempo, o que un firewall está descartando el intento de conexión sin enviar un reset.

¿Por qué un firewall descarta en lugar de rechazar una conexión?

Algunas configuraciones por defecto de firewall o de grupo de seguridad descartan en silencio los paquetes que no coinciden con una regla de permiso en lugar de enviar un reset TCP. Ese descarte silencioso es lo que convierte lo que podría ser un 521 rápido y claro en un 522 más lento y ambiguo.

¿El 522 significa que necesito ampliar mi servidor?

No necesariamente. Antes de escalar, comprueba si el keepalive está desactivado, si el firewall descarta en silencio los rangos de Cloudflare, y si los límites de conexión en la configuración del servidor web están fijados más bajos de lo que el tráfico realmente necesita.

¿Cuál es la diferencia entre el 522 y el 524?

El 522 es un fallo al llegar a completar siquiera el handshake TCP. El 524 es una conexión completada donde la propia respuesta HTTP tarda demasiado, normalmente por una lógica de aplicación lenta y no por un problema de red o de capacidad.

¿Una única consulta lenta a base de datos puede causar un 522?

No directamente, ya que el 522 ocurre antes de enviar ninguna petición. Es más probable que una consulta lenta produzca un 524, donde la conexión tuvo éxito pero la respuesta tardó demasiado en llegar.