L’erreur Cloudflare 521 est un de ces messages qui vous glacent le sang, surtout quand vous êtes en pleine réunion client et que votre site refuse de répondre. Le pire, c’est qu’elle semble sortir de nulle part. Un site qui marchait parfaitement à midi, et qui à 14h vous sort « Web server is down » sur un fond orange.
Je vais vous épargner les heures de tâtonnements que j’ai moi-même passées sur ce problème. Parce que non, l’erreur 521 n’est pas un simple « votre serveur est éteint ». C’est un message de Cloudflare qui signifie qu’il ne peut pas établir de connexion TCP avec votre serveur d’origine. Et cette distinction est essentielle.
Étape 1 : Vérifiez que le serveur est vivant (et pas juste « presque »)
Le premier réflexe est de vérifier l’état du serveur. Mais attention : pas juste « est-ce que le serveur répond ? ». Il faut vérifier si votre serveur web (Apache, Nginx, LiteSpeed) tourne encore. Un serveur peut être allumé, avec MySQL qui fonctionne, mais le processeur web peut être planté.
La commande la plus simple, depuis un terminal, consiste à interroger votre serveur en local ou via son IP directe :
curl -I http://votre-ip-directe.com
Si vous obtenez une réponse `HTTP/1.1 200 OK`, le serveur est opérationnel et le problème vient probablement de la connexion entre Cloudflare et votre serveur. Si vous n’avez rien, ou une erreur de connexion, c’est que votre serveur web est arrêté ou bloqué.
Spoiler : dans 40% des cas que j’ai traités pour des clients, c’était une simple surcharge CPU qui faisait planter Apache. Le serveur était allumé, mais inapte à répondre.
Étape 2 : La liste blanche des IP Cloudflare (le blocage silencieux)
C’est l’erreur la plus sournoise. Votre serveur fonctionne, votre site est accessible en tapant l’IP directement, mais dès qu’on passe par Cloudflare, c’est le 521. La cause est souvent un pare-feu applicatif (mod_security, fail2ban, CSF) qui bloque les adresses IP de Cloudflare.
Il faut autoriser les adresses IP de Cloudflare. La liste est publique et mise à jour régulièrement sur cloudflare.com/ips. Mais plutôt que de les copier à la main (une erreur que j’ai faite moi-même, avec les conséquences que vous imaginez), il existe des scripts d’automatisation pour les intégrer à votre pare-feu, via des CRON.
Pour vérifier si c’est bien le blocage qui est en cause, jetez un œil aux logs de votre serveur. Une ligne comme `Connection refused` ou `Access denied` pour des IP de Cloudflare est un signe qui ne trompe pas.
| Cause du 521 | Symptôme côté serveur | Vérification rapide |
|---|---|---|
| Serveur web arrêté | Aucune réponse sur le port 80/443 | `systemctl status apache2` ou `curl -I http://IP` |
| Pare-feu bloquant les IP Cloudflare | Refus de connexion dans les logs | `tail -f /var/log/apache2/error.log` |
| Certificat SSL expiré | Erreur de handshake TLS | `openssl s_client -connect IP:443` |
| Ressources CPU/RAM épuisées | Processus web en crash loop | `top` ou `htop` pour voir la charge |
Étape 3 : SSL et le handshake qui tourne mal
Une erreur 521 peut aussi venir d’un certificat SSL mal configuré côté serveur d’origine. Le mode de chiffrement de Cloudflare ("Flexible", "Full", "Full (strict)") doit correspondre à ce que votre serveur supporte.
J’ai passé une nuit entière sur un problème où le site était en "Full (strict)" chez Cloudflare, mais le certificat sur le serveur d’origine était expiré depuis trois semaines. Pour diagnostiquer, utilisez la commande suivante :
openssl s_client -connect votre-serveur.com:443 -servername votre-serveur.com
Si vous voyez `verify error:num=10` ou `certificate has expired`, le problème est là. Soit vous renouvelez le certificat, soit vous passez temporairement en mode "Full" dans le tableau de bord Cloudflare pour rétablir le service.
Le cas particulier : les ressources du serveur
Un serveur qui manque de RAM ou qui subit une charge CPU constante à 100% finira par ne plus accepter de connexions. Vérifiez l’utilisation des ressources avec `top` ou `htop`.
Sur les environnements mutualisés (cPanel, Plesk), le souci est différent : l’hébergeur impose des limites d’inodes ou de CPU. Si votre site dépasse ces quotas, le serveur web peut tuer le processus. Dans ce cas, la solution n’est pas technique de votre côté, mais un passage chez l’hébergeur pour augmenter les ressources ou passer sur un plan dédié.
Étape 4 : WordPress et les extensions qui jouent aux pompiers
Si vous êtes sous WordPress, deux vérifications supplémentaires s’imposent. D’abord, les extensions conflictuelles. Un plugin de cache ou de sécurité qui se met à jour peut entrer en conflit et faire planter le serveur. Personnellement, j’ai eu le cas avec un plugin de sécurité qui bloquait les requêtes de Cloudflare, en les considérant comme des attaques.
Ensuite, examinez les règles de pare-feu des extensions de sécurité (Wordfence, iThemes Security, etc.). Ces extensions ont souvent leurs propres listes noires. Elles peuvent bloquer les IP de Cloudflare, ce qui provoque exactement le même symptôme. Désactivez-les temporairement pour tester, puis affinez leurs règles.
Bonne question : qu’en est-il du mode "Under Attack" de Cloudflare ?
Et là, surprise : une mauvaise configuration du pare-feu de Cloudflare lui-même peut provoquer une erreur 521. C’est rare, mais ça arrive. Le mode "Under Attack Mode" applique un défi JavaScript à chaque visiteur. Si votre serveur ne supporte pas le délai de vérification, ou si vous avez une règle WAF qui bloque `cloudflare.com` comme referrer, le CDN peut se tirer une balle dans le pied et ne plus joindre votre serveur.
Dans ce cas, ajustez les règles du WAF plutôt que de tout désactiver. Si vous désactivez Cloudflare, votre serveur est exposé aux attaques DDoS, et c’est rarement une bonne idée.
Comment éviter que l’erreur 521 ne revienne (le vrai sujet)
La meilleure solution, c’est la surveillance. Configurez un service de monitoring de disponibilité (UptimeRobot, Pingdom) qui va vérifier votre site toutes les minutes. Vous serez prévenu par e-mail ou SMS dès que le site est down, et non pas quand un client vous appelle.
J’ai automatisé la mise à jour de la liste blanche des IP Cloudflare chez tous mes clients. Un script qui tourne toutes les semaines et qui met à jour automatiquement les règles du pare-feu. Ça m’a évité 90% des erreurs 521 de type « blocage silencieux ».
Enfin, utilisez la fonctionnalité de « rechargement automatique » si vous êtes sur un serveur dédié. Un script qui redémarre Apache dès qu’il ne répond plus est une bouée de sauvetage pour éviter les pannes prolongées à 3h du matin.
Comment puis-je corriger l’erreur 521 sur Cloudflare ?
La question que tout le monde se pose. Voici la méthode complète, dans l’ordre :
- Vérifiez l’état du serveur : `curl -I http://IP-directe` et `systemctl status apache2`
- Autorisez les adresses IP de Cloudflare dans votre pare-feu (CSF, iptables, fail2ban)
- Corrigez les paramètres SSL : alignez le mode SSL de Cloudflare avec votre certificat (testez avec `openssl`)
- Examinez l’utilisation des ressources : `top`, `htop`, espace disque
- Désactivez temporairement Cloudflare (mode DNS-only) pour isoler le problème, mais seulement après avoir testé les étapes 1 à 4
- Pour WordPress : désactivez les extensions conflictuelles et passez en revue les règles de pare-feu des plugins de sécurité
L’erreur 521 est frustrante, mais elle est presque toujours résoluble en moins d’une heure si on suit ces étapes méthodiquement. Le pire ennemi, c’est la panique qui pousse à tout changer au hasard. Restez méthodique, et votre site reviendra.
Une dernière chose : si le problème persiste après toutes ces vérifications, regardez du côté de votre hébergeur. Certains coupent les connexions entrantes depuis les IP de Cloudflare pour des raisons de sécurité, sans même vous prévenir. Un simple ticket au support peut résoudre un mystère qui vous a occupé tout un week-end. Croyez-moi, j’en parle en connaissance de cause.
