Cómo solucionar el error 520 de Cloudflare: Guía completa de diagnóstico y resolución

El Error 520 de Cloudflare es un código de estado HTTP que se devuelve cuando la red perimetral de Cloudflare recibe una respuesta vacía, inesperada o de otro modo no interpretable de su servidor de origen. A diferencia de un 502 o 504, que indican un tiempo de espera de puerta de enlace o una puerta de enlace incorrecta, un 520 es el código comodín de Cloudflare para respuestas que quedan fuera de cualquier especificación HTTP reconocida, lo que significa que el servidor de origen respondió técnicamente, pero lo que envió de vuelta era inválido, truncado o estructuralmente malformado.

Desde un punto de vista práctico, el Error 520 significa que la conexión TCP entre Cloudflare y su servidor de origen se estableció, pero el protocolo de enlace a nivel HTTP falló. El usuario ve una página de error con la marca de Cloudflare con el mensaje "El servidor web está devolviendo un error desconocido" — y su sitio está efectivamente fuera de línea para ellos.

Qué desencadena el Error 520: Causas raíz explicadas

Comprender el modo de fallo exacto es esencial antes de tocar cualquier configuración. El Error 520 no es un problema único — es una clase de síntoma. Las siguientes causas son las más comunes, clasificadas por frecuencia en entornos de producción.

El servidor de origen devuelve un cuerpo de respuesta vacío sin línea de estado HTTP. Este es el desencadenante más frecuente. Apache o Nginx pueden fallar a mitad de la respuesta, dejando a Cloudflare con un socket TCP abierto sin datos entrantes.

El firewall o software de seguridad bloquea los rangos IP de Cloudflare. Herramientas como ModSecurity, Fail2Ban, CSF (ConfigServer Security & Firewall), o plugins a nivel de aplicación como Wordfence pueden descartar silenciosamente paquetes de las IPs de salida de Cloudflare, haciendo que la conexión se restablezca sin una respuesta HTTP adecuada.

Incompatibilidad en el protocolo de enlace SSL/TLS entre Cloudflare y el origen. Si Cloudflare está configurado en modo "Full (Strict)" pero su servidor de origen tiene un certificado caducado, autofirmado o mal configurado, la negociación TLS falla antes de que se intercambie cualquier dato HTTP.

Cabeceras de respuesta HTTP malformadas o demasiado grandes. Cloudflare aplica un límite estricto de 32 KB en las cabeceras de respuesta. Cualquier cabecera individual o conjunto de cabeceras combinadas que supere este límite provoca un 520. Este es un caso límite común con aplicaciones PHP mal escritas que vuelcan grandes datos de sesión o salida de depuración en las cabeceras.

Fallo del proceso del servidor de origen o eliminación por OOM (Out-of-Memory). Si el proceso del trabajador del servidor web (por ejemplo, un trabajador de Nginx o un pool de PHP-FPM) es eliminado por el OOM killer de Linux a mitad de una solicitud, la conexión se interrumpe abruptamente.

Excepciones a nivel de aplicación antes de que se envíen las cabeceras. Un error fatal de PHP, una excepción no controlada de Python, o un fallo de Node.js que ocurre antes de que se llame a res.writeHead() resulta en una respuesta vacía que Cloudflare no puede analizar.

Restablecimiento de conexión por el origen (TCP RST). El servidor de origen restablece activamente la conexión TCP, lo que Cloudflare interpreta como una respuesta desconocida.

Error 520 vs. Otros errores 5xx de Cloudflare

Distinguir el 520 de errores similares de Cloudflare evita esfuerzos de diagnóstico innecesarios.

Si está viendo el error 521, el proceso de su servidor web no está en ejecución. Si está viendo el error 524, su aplicación está en ejecución pero es demasiado lenta. Si está viendo el error 520, el servidor está en ejecución y respondiendo — pero lo que envía de vuelta está roto.

Solución paso a paso para el Error 520

Paso 1: Verificar el estado y la conectividad del servidor de origen

Antes de tocar Cloudflare, confirme que el servidor de origen está activo y que el demonio del servidor web está en ejecución.

Compruebe si el proceso del servidor web está activo:

# For Nginx
sudo systemctl status nginx

# For Apache
sudo systemctl status apache2

# For LiteSpeed
sudo systemctl status lsws

Pruebe la conectividad directa a la IP de origen, omitiendo el proxy de Cloudflare. Recupere su IP de origen desde el panel de control DNS de Cloudflare y luego pruébela directamente:

curl -I --resolve yourdomain.com:80:YOUR_ORIGIN_IP http://yourdomain.com/
curl -I --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/

Si curl devuelve un estado HTTP válido (200, 301, etc.), el servidor de origen es funcional y el problema está en la capa de comunicación entre Cloudflare y el origen. Si curl devuelve una respuesta vacía o un restablecimiento de conexión, el problema está en el lado del origen.

Compruebe la presión de recursos del sistema:

# Memory usage
free -h

# CPU load
uptime

# Check for OOM kills in the last boot
dmesg | grep -i "oom|killed process"

# Check for PHP-FPM pool exhaustion
sudo systemctl status php8.1-fpm

Paso 2: Inspeccionar los registros de errores del servidor de origen

Los registros del servidor de origen son la fuente de diagnóstico más valiosa. No omita este paso.

Para Nginx:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

Para Apache:

sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/apache2/access.log

Busque específicamente:

• Entradas de nivel [crit] o [emerg]

upstream prematurely closed connection (Nginx + PHP-FPM)
Premature end of script headers (Apache + CGI/PHP)
worker_connections are not enough (límite de trabajadores de Nginx alcanzado)
Errores fatales de PHP registrados en el registro de errores del servidor web

Correlacione las marcas de tiempo del registro con el momento en que ocurrieron los errores 520. El panel de control de Cloudflare en Analytics > Traffic muestra las marcas de tiempo de los picos de 520 que puede usar para la correlación.
Paso 3: Incluir en la lista blanca los rangos IP de Cloudflare en su firewall
Si un firewall está bloqueando las IPs de salida de Cloudflare, la conexión se restablecerá silenciosamente. Cloudflare publica sus rangos IP actuales en https://www.cloudflare.com/ips/.
Para UFW (Ubuntu/Debian):
# Download Cloudflare IPv4 ranges and whitelist them
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

# Repeat for IPv6
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

sudo ufw reload
Para CSF (ConfigServer Firewall):
Agregue los rangos IP de Cloudflare a /etc/csf/csf.allow, luego reinicie CSF:
sudo csf -r
Para ModSecurity: Si sospecha que ModSecurity es el culpable, revise su registro de auditoría:
sudo tail -n 200 /var/log/modsec_audit.log
Busque coincidencias de reglas contra las direcciones IP de Cloudflare. Puede incluir en la lista blanca las IPs de Cloudflare en su configuración de ModSecurity o establecer la directiva SecRemoteRules para excluirlas.
Nota crítica: Nunca deshabilite permanentemente su firewall o ModSecurity. Incluya en la lista blanca únicamente los rangos IP publicados de Cloudflare, y vuelva a habilitar todos los controles de seguridad inmediatamente después de las pruebas.
Paso 4: Auditar y corregir las cabeceras de respuesta HTTP
Las cabeceras malformadas o demasiado grandes son una causa frecuentemente ignorada de los errores 520. Use curl con salida detallada para inspeccionar exactamente lo que está enviando su origen:
curl -v --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/ 2>&1 | head -80
Esté atento a:

Cabeceras con caracteres no ASCII o caracteres de control
Cabeceras Set-Cookie con valores extremadamente largos (común en configuraciones incorrectas de sesiones PHP)
Cabeceras Content-Type faltantes o malformadas
Cabeceras Content-Length duplicadas con valores en conflicto

Si está ejecutando una aplicación PHP, revise php.ini para la configuración de output_buffering. Un búfer de salida deshabilitado combinado con un error fatal a mitad de la respuesta puede causar una transmisión parcial de cabeceras.
Específicamente para sitios WordPress: Los plugins que inyectan grandes cantidades de datos en las cabeceras HTTP (algunos plugins de seguridad o caché hacen esto) pueden superar el límite de 32 KB de Cloudflare. Audite los plugins activos y pruebe en modo seguro.
Paso 5: Validar la configuración SSL/TLS de Cloudflare
Una incompatibilidad SSL entre Cloudflare y el origen es una fuente común de fallos de clase 520 que se disfraza como un error desconocido genérico.
Navegue a Cloudflare Dashboard > SSL/TLS > Overview y verifique el modo de cifrado:



Modo SSL de Cloudflare
Requisito del origen
Recomendado para








—
—
—








Off
Sin SSL en el origen
Nunca recomendado








Flexible
No se necesita SSL en el origen
Solo para configuraciones heredadas; riesgo de seguridad








Full
Cualquier certificado SSL en el origen (incluido autofirmado)
Entornos de desarrollo








Full (Strict)
Certificado SSL válido y de confianza en el origen
Todos los sitios en producción





Si su origen usa un certificado autofirmado y Cloudflare está configurado en Full (Strict), el protocolo de enlace TLS fallará. Instale un certificado válido en el origen (un certificado gratuito de Let’s Encrypt funciona) o cambie temporalmente al modo Full mientras soluciona el certificado.
Si necesita un certificado de confianza adecuado para su servidor de origen, los Certificados SSL de una CA de confianza eliminan completamente el problema del certificado autofirmado y son compatibles con el modo Full (Strict) de Cloudflare.
Paso 6: Pausar el proxy de Cloudflare para un diagnóstico específico
Eliminar temporalmente Cloudflare de la ruta de solicitud permite aislar si el problema está en la configuración de Cloudflare o en el servidor de origen.
Método 1: Deshabilitar el proxy en un registro DNS específico
En el panel de control DNS de Cloudflare, haga clic en el icono de nube naranja junto a su registro A o CNAME para ponerlo en gris. Esto omite el proxy de Cloudflare mientras mantiene la resolución DNS a través de Cloudflare. La propagación DNS tarda hasta 5 minutos.
Método 2: Pausar Cloudflare globalmente para el dominio
Navegue a Cloudflare Dashboard > Overview > Advanced Actions > Pause Cloudflare on Site. Esto enruta todo el tráfico directamente a su origen.
Después de pausar, pruebe su sitio. Si carga correctamente, el problema está en la configuración de Cloudflare. Si sigue fallando, el problema está en el servidor de origen independientemente de Cloudflare.
Vuelva a habilitar Cloudflare inmediatamente después de las pruebas — un Cloudflare pausado significa que su sitio pierde la protección DDoS, el caché CDN y la cobertura WAF.
Paso 7: Verificar la precisión de los registros DNS
Un registro DNS A mal configurado que apunta a una IP incorrecta o desactualizada hace que Cloudflare enrute el tráfico al servidor equivocado, que devolverá una respuesta inesperada.
En el panel de control DNS de Cloudflare:

Verifique que el registro A para su dominio raíz (@) apunte a la IP actual de su servidor de origen
Verifique que el CNAME para www se resuelva correctamente
Si migró servidores recientemente, confirme que la IP antigua ya no esté referenciada en ningún lugar

Confirme a qué IP está enviando realmente el tráfico Cloudflare:
dig +short yourdomain.com @1.1.1.1
Compare esto con la IP real de su servidor de origen. Si difieren, actualice el registro DNS en Cloudflare.
Paso 8: Escalar los recursos del servidor de origen
Si su servidor de origen está constantemente bajo alta carga, los errores 520 ocurrirán de forma intermitente durante los picos de tráfico a medida que los procesos de trabajo se agoten y las conexiones se interrumpan.
Diagnostique el agotamiento de recursos:
# Check Nginx worker connections
sudo nginx -T | grep worker_connections

# Check PHP-FPM pool limits
cat /etc/php/8.1/fpm/pool.d/www.conf | grep -E "pm.|max_children"

# Monitor real-time connections
ss -s
Opciones de ajuste sin actualización de hardware:

Aumente worker_connections en /etc/nginx/nginx.conf

• Aumente pm.max_children en la configuración del pool de PHP-FPM
• Habilite la directiva keepalive de Nginx para conexiones upstream
• Implemente caché de objetos (Redis o Memcached) para reducir la presión sobre la base de datos
• Habilite la regla de página Cache Everything de Cloudflare para descargar la entrega de activos estáticos

Para aplicaciones que han superado la infraestructura compartida, migrar a un entorno de Hosting VPS le brinda control total sobre los límites de procesos de trabajo, la asignación de memoria y el ajuste TCP a nivel de kernel — ninguno de los cuales está disponible en los planes compartidos.

Si su aplicación maneja cargas de trabajo de cómputo intensivo (inferencia ML, procesamiento de video, operaciones con grandes conjuntos de datos) que causan fallos intermitentes de los trabajadores, el Hosting GPU descarga esas tareas de los procesos de su servidor web, eliminando una fuente común de fallos a mitad de respuesta.

Paso 9: Revisar las reglas de firewall y seguridad de Cloudflare

Las propias funciones de seguridad de Cloudflare pueden ocasionalmente interferir con la comunicación legítima con el origen, especialmente si las reglas de Firewall personalizadas o las reglas WAF están mal configuradas.

Revise Cloudflare Dashboard > Security > WAF > Custom Rules para detectar cualquier regla que pueda estar interceptando solicitudes antes de que lleguen al origen. También revise Security > Settings > Browser Integrity Check — en casos raros, esto puede causar comportamientos inesperados con ciertos agentes de usuario o solicitudes automatizadas.

Revise el registro de Security > Events para ver si Cloudflare está bloqueando o desafiando solicitudes que deberían llegar a su origen.

Paso 10: Escalar al proveedor de hosting o al soporte de Cloudflare

Si todos los pasos anteriores se han agotado sin resolución, escale con información precisa.

Al contactar a su proveedor de hosting, proporcione:

• Las marcas de tiempo exactas de las ocurrencias del error 520 (desde Cloudflare Analytics)
• Extractos relevantes de su registro de errores del servidor web
• La salida de curl -v contra su IP de origen
• Métricas actuales de uso de recursos (CPU, RAM, recuento de conexiones)

Los proveedores que ejecutan infraestructura gestionada en Servidores Dedicados pueden realizar diagnósticos a nivel de kernel, capturas de paquetes (tcpdump) e inspección a nivel de socket que no están disponibles en entornos compartidos.

Al contactar al soporte de Cloudflare, incluya:

• Su Ray ID de la página de error 520 (visible en el HTML de error de Cloudflare)
• Un archivo HAR capturado desde Chrome DevTools durante el error
• Su modo SSL/TLS actual y cualquier regla de Firewall personalizada

El Ray ID es fundamental — permite a los ingenieros de Cloudflare recuperar la entrada exacta del registro del nodo perimetral para su solicitud fallida.

Diagnóstico avanzado: Capturar el fallo exacto con tcpdump

Para errores 520 persistentes o intermitentes que resisten la solución de problemas estándar, una captura de paquetes en el servidor de origen revela exactamente lo que está ocurriendo en la capa TCP/HTTP cuando Cloudflare se conecta.

# Capture traffic from Cloudflare IPs on port 443
sudo tcpdump -i eth0 -w /tmp/cloudflare_capture.pcap 'src net 103.21.244.0/22 or src net 103.22.200.0/22 or src net 103.31.4.0/22 or src net 104.16.0.0/13 or src net 104.24.0.0/14' and port 443

Abra el archivo .pcap resultante en Wireshark y filtre por tcp.flags.reset == 1 para identificar paquetes TCP RST, que indican que el origen está restableciendo activamente las conexiones. Filtre por http para inspeccionar cualquier respuesta HTTP parcial que se esté enviando.

Este nivel de análisis identifica definitivamente si el error 520 es causado por un RST del firewall, un fallo de la aplicación a mitad de la respuesta, o un fallo TLS.

Prevención del Error 520: Medidas proactivas

La resolución de problemas reactiva es costosa. Estas medidas reducen significativamente la probabilidad de ocurrencia del error 520.

Implemente Health Checks de Cloudflare. En Traffic > Health Checks, configure una verificación de estado contra su origen. Cloudflare le alertará antes de que los usuarios comiencen a ver errores 520.

Habilite la función Always Online de Cloudflare (en Caching > Configuration). Aunque no soluciona el problema subyacente, sirve versiones en caché de sus páginas a los usuarios durante las interrupciones del origen, evitando un apagón completo del servicio.

Configure la monitorización del servidor de origen con herramientas como UptimeRobot, Pingdom, o una solución autohospedada como Uptime Kuma. Monitorice la IP de origen directamente (no el dominio con proxy de Cloudflare) para detectar fallos del origen independientemente de Cloudflare.

Automatice la inclusión en lista blanca de IPs de Cloudflare. Los rangos IP de Cloudflare cambian ocasionalmente. Use un cron job para actualizar su lista blanca del firewall:

# /etc/cron.weekly/update-cloudflare-ips
#!/bin/bash
CF_IPS=$(curl -s https://www.cloudflare.com/ips-v4)
# Add logic to update UFW/CSF/iptables rules

Use Authenticated Origin Pulls de Cloudflare. Esta función configura su origen para aceptar únicamente conexiones HTTPS que presenten el certificado de cliente de Cloudflare, bloqueando cualquier solicitud directa al origen que omita el proxy. Esto también elimina una clase de errores 520 causados por tráfico no proveniente de Cloudflare que llega a su origen y activa respuestas del software de seguridad.

Para equipos que gestionan múltiples dominios y aplicaciones web, un VPS con cPanel proporciona acceso centralizado a registros, gestión de firewall y gestión de certificados SSL en todos los dominios alojados — reduciendo significativamente el tiempo de diagnóstico para eventos de error 520.

Matriz de decisión: Diagnóstico de su escenario específico de error 520

Lista de verificación técnica de puntos clave

Antes de escalar al soporte, confirme que ha completado cada uno de los siguientes puntos:

• Verificó que el proceso del servidor web de origen está en ejecución (systemctl status)
• Probó la conectividad directa al origen con curl -v --resolve omitiendo Cloudflare
• Revisó los registros de errores del origen para las marcas de tiempo exactas de los eventos de error 520
• Confirmó que los rangos IP de Cloudflare están en lista blanca en todos los firewalls activos (UFW, CSF, iptables, ModSecurity)
• Validó que las cabeceras de respuesta están por debajo de 32 KB y no contienen valores malformados
• Confirmó que el modo SSL/TLS de Cloudflare coincide con el tipo de certificado del origen
• Verificó que los registros DNS A apuntan a la IP de origen correcta y actual
• Comprobó la memoria del sistema y la CPU para detectar eliminaciones por OOM o agotamiento de recursos
• Capturó el Ray ID de la página de error 520 para la escalada al soporte de Cloudflare
• Revisó el registro de eventos de seguridad de Cloudflare para detectar interferencias de reglas WAF

Preguntas frecuentes

¿Cuál es la diferencia entre el Error 520 y el Error 521 de Cloudflare?

El Error 521 significa que Cloudflare llegó correctamente a la IP de su servidor de origen pero el proceso del servidor web rechazó la conexión TCP — típicamente porque Nginx o Apache no está en ejecución. El Error 520 significa que la conexión TCP se estableció pero la respuesta HTTP estaba vacía, truncada o malformada. Si ve el error 521, inicie su servidor web. Si ve el error 520, el servidor está en ejecución pero enviando respuestas rotas.

¿Puede el Error 520 ser causado por Cloudflare en sí mismo, y no por el servidor de origen?

Raramente, pero sí. Los problemas en los nodos perimetrales de Cloudflare pueden causar errores 520 que no son reproducibles al acceder al origen directamente. Revise cloudflarestatus.com para incidentes activos. Si el origen responde correctamente a través de curl directo y la página de estado de Cloudflare muestra un incidente activo, espere a que Cloudflare lo resuelva en lugar de realizar cambios en su servidor.

¿Por qué el Error 520 ocurre solo de forma intermitente y no de manera consistente?

Los errores 520 intermitentes casi siempre indican agotamiento de recursos — pools de trabajadores de PHP-FPM sin hijos disponibles, Nginx alcanzando los límites de worker_connections, o el OOM killer de Linux terminando procesos bajo presión de memoria. Estas condiciones ocurren durante picos de carga y se resuelven cuando el tráfico disminuye, creando el patrón intermitente. Los errores 520 consistentes apuntan a un problema de configuración.

¿Pausar Cloudflare soluciona el Error 520?

Pausar Cloudflare lo elimina de la ruta de solicitud, por lo que si su sitio funciona después de pausarlo, el problema está en la configuración de Cloudflare (modo SSL, reglas WAF, registros DNS). Si su sitio sigue fallando después de pausarlo, el problema está en el servidor de origen. Pausar Cloudflare es un paso de diagnóstico, no una solución — elimina la protección DDoS y el caché CDN mientras está activo.

¿Cómo encuentro el Ray ID para reportar un error 520 a Cloudflare?

El Ray ID se muestra en la parte inferior de la página de error 520 de Cloudflare que se muestra a los usuarios. Parece una cadena hexadecimal de 16 caracteres (por ejemplo, 7a3f2b9c1d4e8f0a). También puede encontrarlo en la cabecera de respuesta CF-Ray, visible en Chrome DevTools en la pestaña Network. Incluya siempre este ID al abrir un ticket de soporte de Cloudflare — permite a los ingenieros de Cloudflare recuperar la entrada exacta del registro perimetral para su solicitud fallida.