Erreur 521 et 522 Cloudflare : votre serveur d'origine ne répond pas
· 6 min de lecture
Ce que signifient les erreurs
Quand un site passe par Cloudflare, les visiteurs parlent à Cloudflare, et Cloudflare parle à votre serveur, dit « serveur d'origine ». Les codes 521 et 522 sont propres à Cloudflare et disent la même chose : Cloudflare va bien, votre serveur ne répond pas.
- 521 Web server is down : Cloudflare a joint votre serveur, mais celui-ci a refusé la connexion sur le port 443 ou 80. Rien n'y écoute, ou un pare-feu rejette.
- 522 Connection timed out : Cloudflare n'a obtenu aucune réponse à sa tentative de connexion. Le serveur est éteint, surchargé, ou un pare-feu jette les paquets en silence.
Un 521 est donc un ERR_CONNECTION_REFUSED vu par Cloudflare au lieu du navigateur ; un 522, un délai de connexion dépassé. Ni l'un ni l'autre n'est une panne de Cloudflare, et désactiver le proxy ne réparera rien : sans Cloudflare, les visiteurs verraient directement la connexion refusée. À ne pas confondre avec un 502 Bad Gateway, où le serveur web répond mais l'application derrière est arrêtée.
Causes fréquentes
- Le serveur web est arrêté. nginx ou Apache a planté ou n'a pas redémarré après une modification. Résultat : 521.
- Le pare-feu bloque les adresses de Cloudflare. Cloudflare se connecte depuis ses propres plages d'IP. Un pare-feu restrictif, ou un outil anti-attaque qui a banni Cloudflare après une rafale de requêtes, provoque 521 (reject) ou 522 (drop).
- Le serveur est éteint ou injoignable. Panne, redémarrage, maintenance de l'hébergeur, interface réseau tombée : 522.
- Surcharge. Le serveur accepte les connexions trop lentement : 522 par intermittence, souvent aux heures de pointe.
- Mauvais port ou mauvais mode SSL. En mode « Full » ou « Full (strict) », Cloudflare se connecte en 443 ; si le serveur n'écoute qu'en 80, c'est 521. En « Flexible », Cloudflare se connecte en 80.
- L'enregistrement DNS chez Cloudflare pointe vers une ancienne IP. Après un déménagement de serveur, l'ancienne machine est éteinte : 522.
Si vous êtes visiteur
Vous ne pouvez rien faire : la page d'erreur est servie par Cloudflare au nom d'un site dont le serveur ne répond pas. Réessayez plus tard.
Si c'est votre site : vérifier d'abord
Lancez le Site down checker : il affiche le code 521 ou 522 depuis l'extérieur. Puis contournez Cloudflare et parlez au serveur avec son IP et l'en-tête Host :
# le serveur d'origine répond-il directement ?
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
# sur le serveur : son IP réelle (à comparer avec le DNS chez Cloudflare)
hostname -I
Si curl répond, le serveur va bien et c'est le chemin Cloudflare → serveur qui est bloqué (pare-feu, IP, port). Si curl échoue aussi, connectez-vous en SSH :
systemctl status nginx
systemctl status apache2
sudo ss -tlnp | grep -E ':80 |:443 '
sudo ufw status verbose
sudo fail2ban-client status
uptime
Solutions sur votre propre serveur
1. Redémarrer le serveur web
sudo nginx -t && sudo systemctl restart nginx
sudo apachectl configtest && sudo systemctl restart apache2
sudo journalctl -u nginx -n 50
S'il ne démarre pas, le journal donne la raison : erreur de syntaxe, certificat introuvable, port occupé, disque plein (df -h).
2. Autoriser les plages d'IP de Cloudflare
Cloudflare publie la liste de ses plages d'adresses. Votre pare-feu doit les accepter sur 80 et 443 :
# ufw : une règle par plage publiée par Cloudflare
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 a banni une adresse de Cloudflare, levez le bannissement et configurez-le pour lire l'IP réelle du visiteur (en-tête CF-Connecting-IP). Pensez aussi au groupe de sécurité du fournisseur cloud.
3. Faire correspondre port et mode SSL
Dans Cloudflare, section SSL/TLS : en « Full (strict) », votre serveur doit présenter sur 443 un certificat valide pour le domaine (Let's Encrypt via certbot, ou un certificat d'origine délivré par Cloudflare). En « Full », un certificat auto-signé suffit. En « Flexible », le serveur doit répondre en HTTP sur 80 sans rediriger. Le plus sûr : 80 et 443 avec un certificat valide, et « 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. Surcharge
Si uptime montre une charge élevée et que les 522 vont et viennent, cherchez ce qui occupe le serveur : top, les workers PHP-FPM saturés (server reached pm.max_children dans le log), une requête lente, une rafale de robots. Montez le nombre de workers si la mémoire le permet, et laissez Cloudflare servir le contenu statique.
5. Corriger l'enregistrement DNS chez Cloudflare
Dans le tableau de bord Cloudflare, onglet DNS : l'enregistrement A (et AAAA) de example.com et de www doit pointer vers l'IP actuelle du serveur. Supprimez un AAAA qui pointe vers une adresse IPv6 que le serveur n'a plus.
Si le problème vient de votre hébergeur
En hébergement mutualisé, vous ne pouvez ni redémarrer le serveur web ni ouvrir le pare-feu. Envoyez :
Bonjour, mon site example.com passe par Cloudflare et renvoie « Erreur 522 » (délai de connexion dépassé vers le serveur d'origine) depuis environ 15 h 00 (UTC). L'enregistrement DNS pointe vers 203.0.113.10, l'IP de mon hébergement. Rien n'a été modifié de mon côté. Le serveur web de cette machine est-il en panne, ou les plages d'adresses de Cloudflare sont-elles bloquées par votre pare-feu ?
Pour que cela ne se reproduise pas
Derrière Cloudflare, votre serveur peut être en panne sans que personne ne s'en aperçoive avant la page d'erreur. Une vérification depuis l'extérieur voit le 521 ou 522 dès qu'il apparaît, et sur votre propre serveur, l'agent serveur vous alerte quand nginx s'arrête, quand la charge monte ou quand le disque se remplit. L'intervention rapide redémarre le service arrêté si son test de configuration réussit, à prix fixe, 24 h/24 ; l'intervention approfondie reprend le pare-feu, le mode SSL ou la surcharge, facturée par tranches de 15 minutes, l'estimation étant un plafond.
Et maintenant
Vérifier depuis l'extérieur
Le site est-il down pour tout le monde ou seulement pour vous, et que répond le serveur ? Gratuit, sans inscription.
Site down checkerEn panne ? Nous intervenons.
Sur votre propre serveur ou sur un hébergement mutualisé avec accès SSH : intervention rapide à prix fixe pour les causes fréquentes, intervention approfondie facturée par tranches de 15 minutes pour tout le reste, 24 h/24. Prix affiché avant la commande.
Demander un dépannageAutres guides
- Site inaccessible : que faire dans les 15 premières minutes
- Serveur en panne : que vérifier en premier, et dans quel ordre
- Erreur 500 Internal Server Error : trouver la cause dans les logs et remettre le site en ligne
- Erreur 502 Bad Gateway : trouver la cause et la corriger
- Erreur 503 : surcharge, maintenance ou limite d'hébergement ?
- Erreur 504 Gateway Timeout : trouver ce qui ralentit
- DNS_PROBE_FINISHED_NXDOMAIN : le domaine ne répond plus
- ERR_CONNECTION_REFUSED : le serveur refuse la connexion
- Ce que signifie « Votre connexion n'est pas privée » et comment la corriger