Le serveur refuse la porte à Cloudflare

L’erreur 521 Web Server Is Down veut dire une chose précise : Cloudflare a bien réussi à joindre l’adresse IP de ton serveur d’origine, mais celui-ci a refusé la connexion au niveau du port (généralement le 443, en HTTPS). Ce n’est pas un problème de réseau côté visiteur, ni un souci DNS classique : Cloudflare a frappé à la porte, et personne n’a répondu — ou pire, la porte était verrouillée exprès.

C’est différent d’une erreur 523, où Cloudflare n’arrive même pas à router vers l’IP, ou d’une erreur 520, où le serveur répond mais avec n’importe quoi. Ici, le refus est net et se situe presque toujours à un de ces trois niveaux : le service web est arrêté, le pare-feu bloque Cloudflare, ou le port est fermé. Bonne nouvelle : dans l’immense majorité des cas, aucune donnée n’est perdue, le site redevient accessible dès que la connexion réseau est rétablie côté origine.

Pourquoi ça arrive

1. Vérifier que le problème vient bien de l’origine

Avant de toucher à quoi que ce soit, confirme le diagnostic. Utilise un outil de vérification externe (type check-host.net) pour tester si le serveur répond en direct sur son IP, sans passer par le proxy Cloudflare. Si même en direct rien ne répond, le problème est 100 % côté serveur, pas côté Cloudflare. Si le site répond correctement en direct mais pas via Cloudflare, le souci vient très probablement d’un blocage de pare-feu ciblant spécifiquement les IP de Cloudflare.

2. Vérifier que le service web tourne

Connecte-toi en SSH à ton serveur — voici comment faire selon ton hébergeur : OVH, Gandi ou Plesk. Si tu ne sais pas ce qu’est SSH ni comment ça fonctionne, ce guide de base t’explique les fondamentaux avant d’aller plus loin.

Une fois connecté, vérifie l’état du serveur web :

systemctl status nginx
# ou
systemctl status apache2
# ou
systemctl status lsws

Si le service est arrêté (inactive ou failed), relance-le :

systemctl restart nginx

Regarde ensuite les logs d’erreur (/var/log/nginx/error.log ou équivalent Apache) pour comprendre pourquoi il s’est arrêté — ça t’évitera que ça recommence dans deux heures.

3. Vérifier que le port 443 est bien ouvert

Le port 443 (HTTPS) doit écouter et accepter les connexions entrantes. Vérifie ça avec :

ss -tlnp | grep 443

Si rien ne s’affiche, aucun processus n’écoute sur ce port — c’est la cause directe du refus. Vérifie ta configuration de virtual host (Nginx) ou de VirtualHost SSL (Apache) : le bloc listen 443 ssl; doit être présent et actif.

4. Autoriser les IP de Cloudflare dans le pare-feu

C’est la cause la plus fréquente sur les VPS un peu trop verrouillés. Si ton firewall (ufw, iptables, CSF, ou le pare-feu du panel de ton hébergeur) n’autorise qu’une liste restreinte d’IP, les plages Cloudflare doivent être explicitement whitelistées. Sinon, chaque requête de Cloudflare vers ton origine est purement et simplement rejetée.

Avec ufw, par exemple :

ufw allow from 173.245.48.0/20 to any port 443
ufw allow from 103.21.244.0/22 to any port 443

Cloudflare publie une liste officielle et à jour de ses plages IPv4 et IPv6 : ce sont ces plages précises qu’il faut autoriser sur le port 443 (et 80 si tu gères encore du HTTP). Sur un hébergement mutualisé, ce blocage est généralement géré par l’hébergeur lui-même — dans ce cas, contacte son support en précisant explicitement “erreur 521, IP Cloudflare bloquées par le pare-feu”.

5. Vérifier le certificat SSL et le mode Cloudflare

Si le mode SSL/TLS de Cloudflare est réglé sur Full (strict), ton serveur d’origine doit présenter un certificat SSL valide et non expiré. Un certificat cassé peut faire échouer la poignée de main TLS et déclencher un 521. Si tu soupçonnes un certificat expiré, ce guide dédié détaille comment le vérifier et le renouveler.

Pour isoler le problème, teste temporairement en passant en mode Full (non strict) dans Cloudflare (SSL/TLS > Overview). Si le site redevient accessible, le certificat d’origine est en cause — corrige-le puis repasse en strict, qui reste le réglage recommandé pour la sécurité.

6. Vérifier que le serveur n’est pas à court de ressources

Un serveur qui manque de RAM ou de CPU peut voir son service web tué par le système (OOM killer) sans redémarrer automatiquement. Vérifie la mémoire disponible :

free -h

Si le service PHP-FPM ou Nginx a été tué récemment, ça apparaît dans les logs système (dmesg ou /var/log/syslog). Sur un site WordPress, ça peut être lié à un memory_limit PHP trop élevé combiné à un nombre de workers trop important pour la RAM disponible du serveur — un sujet qu’on détaille dans ce guide sur les directives PHP. Réduire le nombre de workers PHP-FPM ou augmenter la RAM du serveur stabilise la situation durablement.

7. Vérifier que le DNS pointe vers le bon serveur

Après une migration d’hébergeur, si le DNS pointe encore vers l’ancien serveur (qui a été arrêté ou dont l’IP a changé), tu obtiens ce type d’erreur. Vérifie l’enregistrement A/AAAA de ton domaine et compare-le à l’IP réelle de ton serveur actif. Ces guides t’aident à configurer correctement : DNS chez o2switch, DNS chez IONOS, DNS chez Hostinger. Si le DNS ne propage pas comme attendu, ce diagnostic complet reprend toutes les vérifications.

Tableau récapitulatif

CauseSolution
Service web arrêtésystemctl restart nginx (ou apache2/lsws) + vérifier les logs
Pare-feu bloque les IP CloudflareWhitelister les plages IP officielles Cloudflare sur le port 443
Port 443 ferméVérifier ss -tlnp, corriger le virtual host SSL
Certificat SSL invalide + mode strictRenouveler le certificat ou tester en mode Full temporaire
Serveur à court de RAM/CPURéduire les workers PHP-FPM, augmenter les ressources serveur
DNS pointant vers un ancien serveurCorriger l’enregistrement A/AAAA vers l’IP active

FAQ

La 521 vient-elle toujours de mon serveur ou parfois de Cloudflare ?

Dans l’écrasante majorité des cas, la 521 vient de l’origine (ton serveur). Cloudflare joue ici un simple rôle de messager qui rapporte fidèlement que ton serveur a refusé la connexion. Il est très rare que Cloudflare soit lui-même en cause.

Puis-je désactiver Cloudflare pour contourner temporairement l'erreur ?

Techniquement oui, en passant le DNS en “DNS only” (nuage gris) plutôt que proxifié (nuage orange), mais cela expose directement l’IP de ton serveur et supprime la protection anti-DDoS de Cloudflare. À réserver à un test de diagnostic court, pas à une solution durable.

Le firewall de mon hébergeur mutualisé peut-il bloquer Cloudflare sans que je le sache ?

Oui, certains hébergeurs appliquent des règles de sécurité par défaut qui n’incluent pas les plages IP Cloudflare, surtout après un changement de configuration serveur. Dans ce cas, seul le support technique de l’hébergeur peut ajuster la règle côté infrastructure.

Comment savoir si mon serveur a été tué par manque de mémoire ?

Vérifie les logs système avec dmesg | grep -i kill ou consulte /var/log/syslog : un processus tué par l’OOM killer y laisse une trace explicite avec le nom du service concerné.

Quand passer la main à un pro

Si tu n’as jamais touché à un pare-feu serveur, à une configuration Nginx/Apache ou à un panel SSH, chaque manipulation ici comporte un risque réel de couper complètement l’accès à ton serveur — y compris pour toi. Un mauvais réglage de firewall peut te bloquer l’accès SSH lui-même. Si le diagnostic dépasse une simple relance de service, ou si le serveur tombe régulièrement sans cause évidente (ressources sous-dimensionnées, configuration instable), c’est le signe qu’une maintenance suivie par une agence évite ce genre d’urgence récurrente plutôt que de la subir à chaque incident.

Ce problème, Peechy s'en occupe

Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.

Confier mon site à Peechy