L’erreur 521 est un code de Cloudflare, pas un statut HTTP du registre habituel. Le message affiché est que le serveur web d’origine est injoignable. Concrètement, Cloudflare a tenté d’ouvrir une connexion TCP vers l’adresse d’origine configurée pour le nom, et cette connexion a été refusée. Rien n’écoute sur le port, ou un pare-feu répond par un rejet explicite. La requête HTTP n’a pas commencé. Il n’y a donc rien à optimiser dans le thème ou dans une requête SQL.
Le nuage orange doit être actif. Un enregistrement DNS « DNS only » ne passe pas par Cloudflare et ne peut pas produire un 521.
Causes propres au 521
- Le service web d’origine est arrêté. Nginx, Apache ou le panneau n’écoute plus sur le port 443 ou 80.
- Le service n’écoute que sur
127.0.0.1. Depuis la machine, un test local passe. Depuis Cloudflare, la connexion est refusée. - L’adresse IP renseignée chez Cloudflare (enregistrement A proxifié, ou IP d’origine) pointe vers un ancien serveur.
- Le pare-feu de l’hébergeur rejette les adresses de Cloudflare. Un REJECT, qui renvoie un paquet de refus, se manifeste en 521. Un DROP silencieux se manifeste plutôt en 522, parce que la poignée de main n’obtient aucune réponse.
- L’hébergeur a retiré l’adresse du routage après un incident réseau. Le port ne répond plus du tout.
Aucune de ces causes n’est une page lente. Le 524, lui, suppose que la connexion TCP a déjà réussi.
Contourner le proxy pour tester l’origine
- Lisez le code sur la page Cloudflare. Confirmez 521, pas 522 ni 523.
- Notez l’IP d’origine affichée dans le DNS Cloudflare pour cet enregistrement.
- Depuis une machine extérieure, ouvrez une connexion TCP vers cette IP sur le port 443. Un refus immédiat confirme le 521. Une attente sans réponse orienterait vers un 522.
- Sur le serveur, vérifiez que le processus écoute sur l’interface publique, pas seulement en local.
- Comparez avec un accès qui ne passe pas par le proxy, en appelant l’IP avec l’en-tête
Hostdu domaine. S’il répond, l’application va bien et le blocage est le chemin Cloudflare. - Un test d’URL sur le nom public reproduit ce que voient les visiteurs. Il doit repasser en 200 après le correctif. Tant qu’il montre une erreur Cloudflare, le proxy n’atteint toujours pas l’origine.
Le journal d’accès de l’origine reste vide pendant un 521 : la requête n’arrive pas. Chercher une erreur PHP à cet instant ne mène à rien.
Rétablir l’écoute et le pare-feu
| Constat | Action |
|---|---|
| Processus web arrêté | Le redémarrer et vérifier qu’il écoute sur 443 |
| Écoute locale seulement | Le lier à l’adresse publique utilisée par Cloudflare |
| Mauvaise IP dans le DNS | Corriger l’enregistrement A proxifié, attendre la prise en compte |
| Pare-feu en REJECT | Autoriser les plages IP de Cloudflare publiées pour le HTTP et le HTTPS |
| Origine saine en direct, 521 en public | Revoir le pare-feu et l’IP, pas le code du site |
Après modification du pare-feu, retestez depuis l’extérieur. Un test lancé sur le serveur lui-même ne traverse pas la règle qui bloque Cloudflare.
Ce qu’il ne faut pas faire
Ne purgez pas le cache Cloudflare en premier : il n’y a pas de page d’origine à remettre en cache. Ne changez pas le mode SSL en premier réflexe. Les échecs de certificat correspondent à d’autres codes Cloudflare, pas à un refus de connexion TCP. Ne confondez pas avec une maintenance voulue : si vous arrêtez le site, les visiteurs qui passent par Cloudflare verront 521 tant que rien n’écoute. Une coupure annoncée se prépare autrement, par un 503 avec Retry-After servi par une origine qui répond encore.
Le contrôle utile ensuite est celui d’un client extérieur, comme lorsque vous testez si un site répond vraiment. Le 521 n’existe que sur le chemin proxifié.