Error 521 y 522 de Cloudflare: el servidor de origen no responde

Qué significan estos errores

Cuando un sitio pasa por Cloudflare, los visitantes hablan con Cloudflare y Cloudflare habla con tu servidor, el llamado « servidor de origen ». Los códigos 521 y 522 son propios de Cloudflare y dicen lo mismo: Cloudflare funciona, tu servidor no contesta.

• 521 Web server is down: Cloudflare llegó a tu servidor, pero este rechazó la conexión en el puerto 443 o 80. Nada escucha ahí, o un firewall la rechaza.
• 522 Connection timed out: Cloudflare no obtuvo respuesta al intentar conectarse: servidor apagado o saturado, o un firewall que descarta los paquetes sin avisar.

Un 521 es, por tanto, un ERR_CONNECTION_REFUSED visto por Cloudflare y no por el navegador; un 522, un tiempo de conexión agotado. Ninguno es una caída de Cloudflare, y desactivar el proxy no arregla nada: sin Cloudflare, los visitantes verían la conexión rechazada directamente. No lo confundas con un 502 Bad Gateway, donde el servidor web responde pero la aplicación de detrás está detenida. ¿No sabes aún qué falla? Empieza por la guía sitio web caído.

Causas frecuentes

1. El servidor web está detenido. nginx o Apache se cayó o no volvió a arrancar tras un cambio. Resultado: 521.
2. El firewall bloquea las direcciones de Cloudflare. Cloudflare se conecta desde sus propios rangos de IP. Un firewall restrictivo, o una herramienta contra ataques que vetó a Cloudflare tras una ráfaga de peticiones, da 521 (reject) o 522 (drop).
3. El servidor está apagado o inalcanzable. Caída, reinicio, trabajos programados del proveedor de hosting, interfaz de red caída: 522.
4. Sobrecarga. El servidor acepta las conexiones demasiado despacio: 522 intermitente, sobre todo con mucho tráfico.
5. Puerto o modo SSL equivocado. En modo « Full » o « Full (strict) », Cloudflare se conecta al 443; si el servidor solo escucha en el 80, da 521. En « Flexible », Cloudflare se conecta al 80.
6. El registro DNS en Cloudflare apunta a una IP antigua. Tras una mudanza de servidor, la máquina vieja está apagada: 522.

Si eres visitante

No puedes hacer nada: Cloudflare sirve la página de error por un sitio cuyo servidor no responde. Vuelve a intentarlo más tarde.

Si es tu sitio: comprobar primero

Abre el Website down checker: muestra el código 521 o 522 desde fuera. Después salta Cloudflare y habla con el servidor por su IP con la cabecera Host:

# ¿responde directamente el servidor de origen?
curl -sI https://203.0.113.10/ -H 'Host: example.com' -k --max-time 10
curl -sI http://203.0.113.10/ -H 'Host: example.com' --max-time 10

# en el servidor: la IP real, para comparar con el DNS
hostname -I

Si curl responde, el servidor está bien y el bloqueo está en el camino Cloudflare → servidor (firewall, IP, puerto). Si también falla, entra por SSH:

systemctl status nginx
systemctl status apache2
sudo ss -tlnp | grep -E ':80 |:443 '
sudo ufw status verbose
sudo fail2ban-client status
uptime

Soluciones en tu propio servidor

1. Reiniciar el servidor web

sudo nginx -t && sudo systemctl restart nginx
sudo apachectl configtest && sudo systemctl restart apache2
sudo journalctl -u nginx -n 50

Si no arranca, el log dice por qué: error de sintaxis, certificado que no existe, puerto ocupado, disco lleno (df -h).

2. Permitir los rangos de IP de Cloudflare

Cloudflare publica sus rangos de direcciones. Tu firewall debe aceptarlos en el 80 y el 443:

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

Si fail2ban vetó una dirección de Cloudflare, levanta el veto y haz que lea la IP real del visitante (cabecera CF-Connecting-IP). Revisa también el grupo de seguridad del proveedor cloud.

3. Hacer coincidir puerto y modo SSL

En Cloudflare, sección SSL/TLS: con « Full (strict) », tu servidor debe presentar en el 443 un certificado válido para el dominio (Let's Encrypt con certbot, o un certificado de origen de Cloudflare). Con « Full » basta uno autofirmado. Con « Flexible », el servidor debe responder por HTTP en el 80 sin redirigir. Lo más seguro: 80 y 443 con certificado válido y « Full (strict) ».

sudo ss -tlnp | grep ':443 '
echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject

4. Sobrecarga

Si uptime muestra carga alta y los 522 van y vienen, busca qué ocupa el servidor: top, workers de PHP-FPM saturados (server reached pm.max_children en el log), una consulta lenta, robots. Sube los workers si la memoria lo permite y deja que Cloudflare sirva lo estático.

5. Corregir el registro DNS en Cloudflare

En el panel de Cloudflare, pestaña DNS: el registro A (y AAAA) de example.com y de www debe apuntar a la IP actual del servidor. Elimina un AAAA con una dirección IPv6 que el servidor ya no tiene.

Si el problema está en tu proveedor de hosting

En un hosting compartido no puedes reiniciar el servidor web ni abrir el firewall. Envía esto:

Hola, mi sitio example.com pasa por Cloudflare y devuelve « Error 522 » (tiempo de conexión agotado hacia el servidor de origen) desde las 15:00 (UTC) aproximadamente. El registro DNS apunta a 203.0.113.10, la IP de mi hosting. No cambié nada por mi parte. ¿Está caído el servidor web de esa máquina, o el firewall bloquea los rangos de Cloudflare?

Para que no vuelva a pasar

Detrás de Cloudflare, un servidor caído pasa inadvertido hasta la página de error. Una comprobación desde fuera ve el 521 o el 522 en cuanto aparece; en tu propio servidor, el agente de servidor te avisa cuando nginx se detiene, sube la carga o se llena el disco.

¿Caído? Intervenimos. En tu propio servidor o en un hosting compartido con acceso SSH, la intervención rápida reinicia el servicio detenido si su prueba de configuración es correcta, a precio fijo, las 24 horas, todos los días; la intervención a fondo se encarga del firewall, del modo SSL o de la sobrecarga, en bloques de 15 minutos; la estimación es el precio máximo.