Cloudflare 521 / 522 en un sitio web en VPS: qué hacer (2026): diagnóstico de origen, firewall y tiempos de espera de Nginx

No trates todos los 5xx de Cloudflare como si fueran lo mismo.

Este artículo solo trata los 521 y 522 más comunes. Para fallos de renovación de certificados, consulta: Qué hacer cuando falla la renovación del certificado Let's Encrypt en un VPS.

Primero confirma si el propio origen de tu VPS es accesible.

Si conoces la IP del origen:

curl -I http://源站IP
curl -I https://源站IP

Si el sitio depende del encabezado Host, usa:

curl -I http://源站IP -H 'Host: example.com'
curl -I https://源站IP -H 'Host: example.com' -k

Si incluso la conexión directa falla, el problema está en el origen, no en Cloudflare.

Resultados habituales:

• Connection refused: el servicio no escucha o se rechazó la conexión, más propio de 521.
• Connection timed out: firewall, grupo de seguridad, enrutamiento o el origen está bloqueado, más propio de 522.
• SSL certificate problem: hay que revisar el certificado o el modo SSL de Cloudflare.
• Accesible directamente pero no a través de Cloudflare: céntrate en si se están bloqueando las IP de retorno al origen de Cloudflare.

En el VPS, ejecuta:

sudo ss -lntp | egrep ':80 |:443 '

Deberías ver a Nginx, Apache, Caddy o tu aplicación escuchando.

Si no hay nada escuchando:

sudo systemctl status nginx --no-pager
sudo systemctl status apache2 --no-pager
sudo systemctl status caddy --no-pager

Revisa los registros:

sudo journalctl -u nginx -n 100 --no-pager
sudo journalctl -u apache2 -n 100 --no-pager
sudo journalctl -u caddy -n 100 --no-pager

Si falla la recarga de Nginx, la configuración tiene un error de sintaxis o la ruta del certificado es incorrecta, Cloudflare puede ver un 521. Para diagnosticar la configuración de Nginx, consulta: Qué hacer cuando la configuración de Nginx es incorrecta en un VPS.

Firewall local:

sudo ufw status verbose
sudo iptables -S
sudo nft list ruleset

Si usas firewalld:

sudo firewall-cmd --list-all

Como mínimo, permite 80 y 443:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Pero permitir puertos en el firewall del sistema no es suficiente. También revisa el grupo de seguridad / firewall del proveedor de nube:

• ¿Está permitido el tráfico entrante 80/tcp?
• ¿Está permitido el tráfico entrante 443/tcp?
• ¿Permitiste solo tu propia IP pero no las IP de retorno al origen de Cloudflare?
• ¿Hay alguna política de región, ruta o DDoS que bloquee el tráfico?

El retorno al origen de Cloudflare no accede al origen desde tu ordenador local; accede a tu VPS desde los nodos perimetrales de Cloudflare. Que tú puedas acceder localmente no significa que Cloudflare pueda.

Muchas personas instalan Fail2Ban, un WAF, reglas deny de Nginx o un firewall en la nube y luego bloquean las IP de retorno al origen de Cloudflare como tráfico sospechoso.

Primero revisa el registro access/error de Nginx:

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

Si no ves ninguna solicitud de Cloudflare, puede que se estén bloqueando antes de llegar al firewall del sistema o al grupo de seguridad.

Si ves solicitudes pero devuelven 403/444/499/5xx, revisa Nginx, la aplicación o las reglas del WAF.

En escenarios con Fail2Ban, revisa:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Si restringes el acceso al origen mediante una lista de IP permitidas, recuerda usar los rangos de IP publicados oficialmente por Cloudflare y mantenerlos actualizados. No escribas a mano unos cuantos rangos antiguos y los dejes sin revisar durante mucho tiempo.

Un 522 no significa necesariamente que el puerto esté cerrado. Es más habitual que sea un tiempo de espera agotado mientras Cloudflare establece una conexión con el origen.

Revisa la carga en el VPS:

uptime
free -h
df -h
top

Revisa la E/S de disco:

iostat -x 1

Revisa los registros de Nginx / la aplicación:

sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log

Si la CPU, la memoria y la E/S de disco del origen están todas altas, las conexiones de Cloudflare pueden agotar el tiempo de espera. Para una E/S de disco alta, consulta: Qué hacer cuando la E/S de disco del VPS es muy alta.

Causas habituales:

• El upstream de PHP-FPM / Gunicorn / Node está bloqueado;
• Consultas lentas a la base de datos retienen las solicitudes;
• Memoria insuficiente provoca swap u OOM;
• La espera de E/S de disco es demasiado alta;
• El pool de conexiones del backend está agotado;
• El tráfico de rastreadores o de ataques satura el servidor.

Aunque 521/522 no son exactamente errores SSL, un modo SSL incorrecto complica el diagnóstico.

Modos habituales:

• Flexible: del navegador a Cloudflare es HTTPS, de Cloudflare al origen es HTTP;
• Full: de Cloudflare al origen también es HTTPS, pero el certificado no se verifica estrictamente;
• Full strict: de Cloudflare al origen es HTTPS y el certificado del origen debe ser válido.

Para sitios en producción se recomienda Full strict, con Let's Encrypt o un Cloudflare Origin Certificate instalado en el origen.

Si tu origen solo escucha en 80 pero Cloudflare hace el retorno por HTTPS, habrá problemas. Revisa:

sudo ss -lntp | egrep ':80 |:443 '
curl -I https://源站IP -H 'Host: example.com' -k

Si el certificado está caducado o el dominio no coincide, normalmente se parece más a 525/526, pero muchos usuarios se lo encuentran mientras diagnostican 521/522.

Los registros A/AAAA en el DNS de Cloudflare deben apuntar al origen real.

Revisa:

dig +short example.com

Si el proxy de nube naranja está activado, un dig externo ve IP de Cloudflare, no la IP del origen. Debes comprobar en el panel de Cloudflare si la IP del origen en el registro DNS es correcta.

Problemas habituales:

• El DNS de Cloudflare no se actualizó después de cambiar la IP del VPS;
• Se actualizó el registro A, pero el registro AAAA sigue apuntando al IPv6 antiguo;
• El origen desactivó IPv6, pero Cloudflare sigue haciendo el retorno por AAAA;
• Varios registros DNS apuntan a máquinas distintas.

Para problemas de configuración de IPv6, consulta: Guía de configuración de IPv6 en VPS.

Si necesitas urgentemente determinar si es un problema de la ruta de Cloudflare, puedes cambiar temporalmente el registro DNS de nube naranja a nube gris para que el tráfico vaya directamente al origen.

Pero ten en cuenta:

• La nube gris expone la IP del origen;
• Si HTTPS no está bien configurado en el origen, los usuarios pueden ver errores de certificado;
• Esto es solo un método de diagnóstico, no una solución a largo plazo;
• Los cambios de DNS pueden tener retrasos por caché.

Un enfoque más seguro es usar curl -H 'Host: 域名' 源站IP para probar el origen directamente, sin cambiar de inmediato el DNS de producción.

Si vas a abrir un ticket, no digas solo "Cloudflare 522". Se recomienda proporcionar:

date
curl -I http://源站IP -H 'Host: example.com'
curl -I https://源站IP -H 'Host: example.com' -k
sudo ss -lntp | egrep ':80 |:443 '
sudo ufw status verbose
sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log
uptime
free -h
df -h

Si sospechas que se están bloqueando las IP de retorno al origen de Cloudflare, adjunta capturas del firewall y del grupo de seguridad. Así es más fácil localizar el problema que enviando solo una captura de la página de error.

Cuando encuentres Cloudflare 521 / 522, revisa en este orden:

1. Confirma el código de error: 521 es conexión rechazada, 522 es tiempo de conexión agotado.
2. Usa curl -H 'Host: 域名' 源站IP para conectarte directamente al origen.
3. En el VPS, usa ss -lntp para confirmar si 80/443 está escuchando.
4. Revisa el estado y los registros del servicio Nginx/Apache/Caddy.
5. Revisa UFW, iptables/nftables, firewalld.
6. Revisa si el grupo de seguridad del proveedor de nube permite el retorno al origen de Cloudflare.
7. Revisa si se están bloqueando IP de Cloudflare por error.
8. En escenarios 522, revisa CPU, memoria, E/S de disco y servicios upstream.
9. Revisa los registros DNS de Cloudflare y si A/AAAA apuntan al origen correcto.
10. Revisa si el modo SSL coincide con la escucha del origen y el certificado.

El núcleo de Cloudflare 521 / 522 no es "Cloudflare está roto", sino que la ruta de Cloudflare a tu origen en VPS tiene un problema.

Para 521, revisa primero si el servicio web está iniciado, si 80/443 está escuchando y si el firewall rechaza conexiones; para 522, revisa primero el firewall/grupo de seguridad, la carga del origen, la red y los tiempos de espera. Primero usa curl para evitar Cloudflare y conectarte directamente al origen, luego revisa ss, journalctl, los registros de Nginx y las reglas del grupo de seguridad; básicamente así reducirás el problema al origen, a la red o a la configuración de Cloudflare.