Un client m'appelle un mardi matin, paniqué. Son site e-commerce affiche une page blanche barrée du message « Error 521 Web server is down ». Le problème ? Son serveur tourne. Il l'a vérifié deux fois. Pourtant, depuis vingt minutes, plus personne ne peut acheter. Et chaque minute compte quand votre chiffre d'affaires repose sur un tunnel de commande.
Ce jour-là, j'ai perdu quarante minutes à chercher au mauvais endroit. J'ai fouillé le code, redémarré PHP, vidé des caches qui n'avaient rien à voir. La vraie cause était ailleurs. L'erreur Cloudflare 521 ne dit pas que votre site est cassé : elle dit que Cloudflare n'arrive plus à parler à votre serveur d'origine. Nuance énorme.
Points clés à retenir
- Le code 521 signifie « Web server is down » : l'origine refuse ou n'accepte pas la connexion de Cloudflare.
- Dans la grande majorité des cas, le vrai coupable est un pare-feu qui bloque les IP Cloudflare, pas un serveur éteint.
- Le test décisif : appelez l'origine directement, sans passer par Cloudflare.
- Whitelister les plages d'IP Cloudflare règle la moitié des incidents que je vois.
- Ne confondez pas 521 avec 522 (timeout) ou 523 (DNS) : le diagnostic change du tout au tout.
L'erreur Cloudflare 521, c'est quoi au juste ?
Quand vous activez Cloudflare, votre trafic passe par un intermédiaire : le visiteur parle à Cloudflare, qui parle à votre serveur d'origine. L'erreur 521 survient quand ce dernier maillon casse. Cloudflare essaie de joindre votre serveur et se heurte à un refus de connexion pur et simple.
Ce n'est pas un timeout. C'est un rejet immédiat : la machine répond « connexion refusée » au lieu de rester muette. Cette distinction est capitale, et c'est là que la plupart des gens se trompent.
Une erreur propre à Cloudflare
Le code 521 n'existe pas dans le protocole HTTP standard. C'est une invention de Cloudflare pour vous dire : « le problème est de votre côté, mais je ne peux pas vous dire précisément où ». Autrement dit, vous voyez la page d'erreur, vos visiteurs aussi, mais vos logs serveur peuvent être totalement vides. Rien n'est même arrivé jusqu'à votre application.
Et là, ça devient déroutant. Vous ouvrez votre terminal, vous tapez une requête vers votre site, et tout répond normalement. Pourquoi ? Parce que vous ne passez probablement pas par Cloudflare pour ce test, ou vous venez d'une IP déjà autorisée.
Le serveur existe... mais refuse de parler
La formulation « Web server is down » est trompeuse. Le serveur n'est pas forcément down. Il peut très bien tourner, servir vos autres sites, répondre en SSH. Simplement, il rejette les connexions provenant du réseau Cloudflare.
J'ai vu ce cas précis chez un client qui avait installé un module de sécurité un vendredi soir. Samedi matin, boom. Le module avait mis à jour sa liste de blocage et considérait les IP Cloudflare comme suspectes. Le serveur allait parfaitement bien. Il avait juste décidé de ne plus causer à l'intermédiaire.
Comment résoudre le problème Cloudflare, étape par étape
Oubliez les listes de causes en vrac. Voici l'ordre exact dans lequel je procède, et pourquoi cet ordre compte.
Étape 1 : vérifier que l'origine répond en direct
Avant tout, contournez Cloudflare. Récupérez l'IP publique de votre serveur et testez l'accès direct. Deux commandes suffisent :
- curl -I http://VOTRE_IP — pour voir si le port 80 répond et quel code HTTP revient
- telnet VOTRE_IP 443 (ou nc -zv VOTRE_IP 443) — pour confirmer que le port HTTPS accepte bien les connexions
Sur le serveur lui-même, vérifiez que votre service écoute réellement : ss -tlnp | grep -E ':80|:443'. Si rien n'apparaît, votre serveur web est arrêté ou mal configuré — et le problème n'a rien à voir avec Cloudflare. S'il écoute, passez à l'étape suivante.
Détail que j'ai mis des mois à intégrer : un test depuis votre navigateur passe souvent par le cache ou une connexion différente. Faites le test depuis une IP tierce (un VPS loué à l'heure, par exemple). Résultat : soit ça répond, soit ça bloque. Vous saurez enfin de quel côté chercher.
Étape 2 : le pare-feu bloque très probablement Cloudflare
C'est la cause numéro un, et pourtant presque aucun guide ne vous donne la vraie solution. Votre pare-feu (iptables, UFW, CSF, fail2ban) voit arriver un flux massif depuis les IP Cloudflare et décide de le bloquer. Fail2ban est un serial-killer dans ce scénario : il bannit les IP Cloudflare à la chaîne après quelques requêtes d'erreur.
La correction : autoriser explicitement les plages d'IP officielles de Cloudflare. Elles sont publiées par Cloudflare elle-même et changent rarement. Voici comment je procède selon la stack :
| Outil | Action | Commande type |
|---|---|---|
| UFW | Autoriser les plages Cloudflare | ufw allow from 173.245.48.0/20 to any port 443 |
| iptables | Insérer une règle d'accept | iptables -I INPUT -s 173.245.48.0/20 -j ACCEPT |
| CSF | Ajouter en liste blanche | csf -a 173.245.48.0/20 |
| fail2ban | Ignore IP dans le jail | ajouter ignoreip = dans jail.local |
Bien sûr, remplacez la plage par la liste complète fournie par Cloudflare (IPv4 et IPv6). Listez-les toutes, pas une seule. J'ai perdu une heure un jour parce que j'avais whitelisté l'IPv4 et oublié l'IPv6 — devinez quel protocole Cloudflare utilisait pour me joindre.
Étape 3 : vérifier le SSL et le mode de connexion
Un certificat expiré ou mal configuré sur l'origine peut aussi provoquer un refus de connexion. Si vous êtes en mode « Full (Strict) » sur Cloudflare, votre serveur doit présenter un certificat valide, signé, non expiré. En mode « Flexible », Cloudflare parle en HTTP à votre serveur — pratique, mais moins sûr.
Le piège classique : un certificat auto-signé sur l'origine combiné au mode Full (Strict). Le handshake TLS échoue, la connexion est refusée, 521. Vérifiez la date d'expiration. Ça m'est arrivé une fois, une nuit, à cause d'un renouvellement Let's Encrypt qui avait raté silencieusement.
521, 522, 523, 524 : ne confondez plus ces erreurs
La question revient sans arrêt : « mais quelle différence avec 522 ? ». La distinction vous fait gagner un temps fou au diagnostic.
Le tableau de décision que j'utilise
| Code | Signification | Qui est en cause |
|---|---|---|
| 521 | Connexion refusée par l'origine | Pare-feu, SSL, service arrêté |
| 522 | Timeout de connexion | Origine lente ou injoignable (réseau) |
| 523 | Origine introuvable | DNS mal configuré côté serveur |
| 524 | Timeout après connexion | Application trop lente à répondre |
Retenez le fil conducteur : 521 = rejet immédiat. 522 = silence prolongé. 523 = adresse introuvable. 524 = l'application met trop de temps. Le 521 est le seul où le serveur vous dit activement « non » — les autres sont des « je n'ai rien reçu ».
Les questions qu'on me pose le plus souvent
Comment débloquer Cloudflare ?
Avant de chercher à « débloquer » quoi que ce soit, il faut identifier ce qui bloque. Si vous voyez la page 521, ce n'est pas Cloudflare qui vous bloque : c'est votre propre origine qui refuse Cloudflare. « Débloquer », dans ce cas, revient à autoriser les IP Cloudflare dans votre pare-feu ou à corriger la config SSL côté serveur. Si vous voyez plutôt une page de challenge Cloudflare (CAPTCHA, « Vérifiez que vous êtes humain »), c'est un autre mécanisme : les règles de sécurité de votre compte Cloudflare filtrent le trafic entrant.
Pourquoi est-ce que je suis bloqué par Cloudflare ?
Deux scénarios distincts, souvent mélangés. Le premier : votre visiteur est bloqué (challenge, page 1020, page d'erreur). Dans ce cas, ce sont les règles WAF, le mode « Under Attack » ou un rate-limiting trop agressif côté Cloudflare qui entrent en jeu. Le second : votre serveur refuse Cloudflare. Et là on revient au 521.
Quand j'entends « je suis bloqué », je pose systématiquement la question inverse : qui bloque qui ? Un site inaccessible en 521 n'est pas un visiteur bloqué par Cloudflare — c'est Cloudflare bloqué par votre serveur. Une fois cette bascule faite, le diagnostic devient limpide.
Faut-il contacter son hébergeur ?
Seulement après les trois étapes ci-dessus. Si l'origine ne répond pas en direct et que vous n'avez pas la main sur la machine (hébergement mutualisé), c'est à eux de jouer. Décrivez précisément : « le port 443 refuse les connexions depuis les IP Cloudflare, voici les tests que j'ai faits ». Un ticket avec des preuves est traité en heures. Un ticket « ça marche pas » traîne des jours.
Sur un serveur que vous administrez, vous n'aurez probablement jamais besoin de les appeler. Le 521 se règle dans 90 % des cas avec les étapes 1 et 2.
Ce que le 521 m'a appris sur le diagnostic
La leçon que je garde de tous ces incidents, c'est que l'erreur n'est pas la cause. Le message « Web server is down » vous oriente vers le serveur alors que le coupable est presque toujours une règle de pare-feu ou une config SSL vieillissante. Le message ment par omission.
La prochaine fois que vous tomberez sur un 521, ne redémarrez rien. Posez-vous une seule question : est-ce que mon serveur accepte la connexion de Cloudflare ? Testez, whitelistez, vérifiez le certificat. Et si tout ça échoue, vous aurez au moins un ticket béton à envoyer à votre hébergeur.
Le vrai réflexe à cultiver, ce n'est pas de mémoriser des codes, c'est de toujours identifier l'intermédiaire qui parle. Cloudflare n'est qu'un messager. Apprenez à l'interroger, pas à lui obéir.
