Error 520 de Cloudflare: qué significa y cómo solucionarlo

Qué significa el error 520

Cloudflare se sitúa entre el visitante y tu servidor web como proxy inverso. En una petición normal, abre una conexión TCP con tu origen, envía la petición y retransmite la respuesta HTTP que vuelve. El error 520 salta cuando falla ese último paso: la conexión TCP se establece, pero los bytes que llegan a continuación no se interpretan como una respuesta HTTP válida, o no llega ningún byte antes de que la conexión se cierre.

Eso sitúa al 520 en una categoría distinta de los demás códigos 5xx de Cloudflare. El error 521 significa que el origen rechazó la conexión directamente. El error 522 significa que el intento de conexión agotó el tiempo de espera. El error 520 significa que el origen respondió algo, y Cloudflare no pudo interpretarlo ni retransmitirlo.

Cómo aparece el error 520

En el navegador, Cloudflare muestra su propia página de error, "Error 520: web server returned an unknown error", junto con un Ray ID que necesitarás si contactas con el soporte de Cloudflare. Una simple petición con curl contra el dominio muestra el mismo código de estado:

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

Por el lado de Cloudflare, las pestañas Security o Analytics del panel muestran un pico de respuestas 5xx, y las cuentas Enterprise con acceso a Logpull o Logpush pueden extraer el colo de borde concreto y el Ray ID de cada petición fallida. Nada de eso te dice qué envió realmente el origen, así que el siguiente sitio donde mirar es tu propio servidor.

En el origen, revisa los registros del servidor web y de la aplicación en la misma marca de tiempo que los fallos. Busca un reinicio de proceso, un fallo de segmentación, un cierre por falta de memoria en el registro del sistema (dmesg o journalctl -k), o un error de la aplicación que interrumpió la petición a mitad de la respuesta. Si los registros de la aplicación no muestran nada fuera de lo normal, es más probable que el problema sea una respuesta que técnicamente se completó pero incumplió alguna regla HTTP, como una cabecera demasiado grande.

Qué causa el error 520

• El proceso del origen se cayó o se reinició mientras gestionaba la petición. La conexión se cierra antes de que salga una respuesta completa. Esta es la causa más habitual.
• El origen reinició la conexión TCP (RST) en lugar de cerrarla de forma limpia. Los servidores de aplicaciones bajo presión de memoria o que alcanzan un tiempo de espera de worker suelen hacer esto.
• Cabeceras de respuesta que superan el límite de 16 KB de Cloudflare. Una cabecera set-cookie grande, una pila de cabeceras de depuración o cabeceras CORS extensas pueden llevar el total por encima de lo que Cloudflare acepta.
• Una cookie, o el conjunto combinado de cabeceras de cookie, demasiado grande. Los datos de sesión, las cookies de seguimiento o un gestor de cookies mal configurado pueden crecer con el tiempo por encima de los límites del navegador y del proxy.
• Una línea de estado ausente o mal formada. Algunos frameworks devuelven una cadena de error en bruto en lugar de una respuesta HTTP correcta cuando una excepción sin gestionar llega a la capa del servidor web.
• El origen devolvió datos que no son HTTP en el puerto HTTP(S). Esto ocurre después de un proxy inverso mal configurado, un mapeo de puerto equivocado, o un servicio que se enlaza al puerto antes de que arranque el servidor web real.
• Un dispositivo de seguridad o un WAF delante del origen cortó la conexión a mitad de la respuesta. Algunos WAF y balanceadores de carga locales cortan conexiones que disparan una regla, lo que parece idéntico a una caída vista desde el lado de Cloudflare.

Cómo saber de quién es la culpa

Como Cloudflare sí recibió una respuesta del origen, el error 520 es una señal fuerte de que el problema está del lado del origen y no en la red de Cloudflare, a diferencia del error 521 o 522, donde la propia conexión falla. La duda suele ser si afecta a todos los visitantes o solo a algunos.

La forma más rápida de averiguarlo es ejecutar una comprobación HTTP desde varias ubicaciones a la vez. Si una comprobación contra el dominio público falla desde todas las ubicaciones en el mismo momento en que los usuarios están reportando el error, el propio origen está caído o cayéndose para todo el mundo, no solo para un centro de datos de borde concreto. Si solo falla de forma intermitente o desde regiones concretas, puede que el origen esté sobrecargado con el tráfico de esa región, o que una capa de caché o balanceo de carga presente solo en parte de tu configuración esté implicada. La comprobación HTTP de HostTracker se ejecuta desde puntos de control en varios países y reporta el resultado de cada uno por separado, un detalle que un único curl desde tu propio escritorio no puede darte.

También puedes aislar el origen de Cloudflare por completo, llamándolo directamente con la cabecera Host del dominio, saltándote la red de borde para que cualquier error que veas sea, sin duda, del origen:

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

Sustituye ORIGIN_IP por la dirección IP real de tu servidor. Si esta petición directa también falla o devuelve la misma respuesta rota, el fallo queda confirmado en el origen.

Cómo solucionar el error 520

Si eres un visitante

1. Recarga la página después de uno o dos minutos. Muchos errores 520 vienen de una caída o reinicio breve del que el propio supervisor de procesos del sitio se recupera automáticamente.
2. Prueba una ventana privada o de incógnito, o una red distinta. Esto descarta una caché local obsoleta o una extensión del navegador con mal comportamiento, aunque un 520 rara vez lo causa algo de tu lado.
3. Comprueba si el sitio publica su propia página de estado, si tiene una, para ver si hay una incidencia conocida.
4. No hay nada que configurar de tu lado para arreglar un 520. Lo genera el propio servidor del sitio, no tu navegador, tu proveedor de internet ni tu resolvedor DNS.

Si administras el sitio

1. Revisa los registros del servidor web y de la aplicación en la marca de tiempo exacta de los fallos, buscando una caída, una excepción sin gestionar o un reinicio de worker.
2. Salta Cloudflare y consulta el origen directamente con la cabecera Host (mostrado arriba), o usa la opción "Pause Cloudflare on Site" de Cloudflare, para confirmar que la respuesta está rota con independencia del proxy.
3. Mide el tamaño de tus cabeceras de respuesta y cookies. Una sola cabecera set-cookie grande o una pila de cabeceras de depuración que quedaron activas en producción pueden llevar el total por encima de 16 KB; recorta lo que no necesites y mueve los datos de sesión grandes al lado del servidor.
4. Busca respuestas mal formadas: un proxy inverso o balanceador de carga apuntando al upstream equivocado, una aplicación que devuelve texto plano en un puerto HTTP, o una línea de estado ausente del gestor de errores por defecto de un framework.
5. Comprueba si hay agotamiento de recursos en el origen: límites de memoria, límites del grupo de conexiones, o un gestor de procesos (systemd, pm2, un grupo de workers de Gunicorn o uWSGI) atascado en un bucle de reinicio.
6. Si hay un WAF, un proxy antivirus o un balanceador de carga entre internet y tu servidor de aplicación, revisa sus propios registros por conexiones que haya descartado o cortado alrededor del mismo momento.

Cómo prevenirlo

El error 520 suele aparecer primero como un ticket de soporte, no como una alerta, porque nada en el origen registra necesariamente un handshake fallido con el borde de Cloudflare de la misma forma en que registra una excepción de la aplicación. Una comprobación de disponibilidad que se ejecuta fuera de tu propia red detecta el mismo fallo que vería un visitante, desde el mismo punto de vista, antes de que alguien tenga que reportarlo. Ejecutar la comprobación desde varios países también muestra al instante si un 520 es global o está limitado a una región, que es el detalle que decide por dónde empezar a depurar.

Errores relacionados

• Error 521 de Cloudflare: el servidor web está caído - el origen rechazó la conexión en lugar de responder.
• Error 522 de Cloudflare: tiempo de conexión agotado - el handshake TCP con el origen nunca se completó.
• Errores de servidor 5xx - la familia general de códigos de estado.
• 502 Bad Gateway - la versión no específica de Cloudflare para una respuesta inválida del upstream.

Preguntas frecuentes

¿El error 520 es culpa de Cloudflare o mía?

Casi siempre del origen. Cloudflare recibió una respuesta y no pudo interpretarla ni retransmitirla, lo que significa que el servidor de origen, y no la red de Cloudflare, produjo la respuesta rota.

¿El error 520 significa que todo mi sitio está caído?

No necesariamente. Significa que falló la petición concreta que lo disparó. Si el origen se está cayendo bajo carga, puede servir un 520 a algunas peticiones y respuestas normales a otras hasta que se corrija el problema de fondo.

¿Puedo arreglar el error 520 solo desde el panel de Cloudflare?

Raramente. Como la causa casi siempre está en el origen, los ajustes del panel no van a arreglar una aplicación que se cae o una cabecera de respuesta demasiado grande. La excepción es verificar que tu modo SSL/TLS y los ajustes de origen coinciden con lo que tu servidor realmente hace, lo que al menos descarta una mala configuración del lado de Cloudflare.

¿Cuál es la diferencia entre el error 520 y un 502 Bad Gateway normal?

El 502 es el estado HTTP general para una respuesta inválida de un servidor upstream, usado por cualquier proxy inverso. Cloudflare usa el 520 específicamente como su propia categoría general para una respuesta tan rota que no encaja en ninguno de los demás códigos 5xx nombrados de Cloudflare, por eso aparece la página de error de Cloudflare con el Ray ID en lugar de una página 502 genérica.

¿De verdad puede una cookie grande causar un 520?

Sí. Cloudflare impone un límite al tamaño total de las cabeceras de respuesta, actualmente en torno a 16 KB, y las cookies cuentan para ese total. Una aplicación que sigue añadiendo datos a una cookie de sesión, o que fija varias cookies grandes a la vez, puede superar ese límite y disparar un 520 aunque la propia aplicación no tenga ningún fallo.

¿Reintentar la petición lo arregla?

A veces, si la causa fue una caída o reinicio pasajero en el origen que ya se ha recuperado. Si el origen está enviando respuestas rotas de forma constante, por ejemplo por una cabecera demasiado grande en cada petición, reintentar no ayudará hasta que se corrija el origen.