L’erreur 522 est un code Cloudflare, distinct du 521 et du 524. Cloudflare a envoyé la demande de connexion TCP vers l’IP d’origine, et la poignée de main n’a pas abouti avant son délai de connexion. Aucune requête HTTP n’est partie. Le journal d’accès du site ne contient en général pas la visite : du point de vue de l’application, il ne s’est rien passé.
Le visiteur voit une page Cloudflare « Connection timed out ». Ce n’est pas le délai de 100 secondes d’une réponse HTTP, qui correspond au 524.
Causes propres au 522
- Le pare-feu jette les paquets des adresses Cloudflare sans répondre (DROP). La connexion reste en suspens, puis expire. Ce n’est pas un refus immédiat.
- L’origine est tellement saturée qu’elle ne complète plus les nouvelles poignées de main. La file d’acceptation est pleine. Les clients déjà connectés peuvent encore finir une requête, les nouveaux n’entrent pas.
- Un mauvais routage ou un filtrage chez l’hébergeur bloque le chemin depuis le réseau de Cloudflare, alors qu’un autre réseau, le vôtre, atteint encore le serveur.
- L’IP d’origine est annoncée mais ne répond sur aucun port utile. Moins net qu’un refus : la machine est injoignable plutôt que fermée.
- Un équipement devant le serveur (anti-DDoS de l’hébergeur) absorbe les SYN sans les transmettre.
Le code PHP, les thèmes et les index SQL n’interviennent pas : la session TCP n’existe pas.
Distinguer un silence d’un refus
- Confirmez le numéro 522 sur la page d’erreur. Un 521 est un refus. Un 524 est une requête déjà envoyée.
- Depuis un réseau qui n’est pas le serveur, tentez d’ouvrir le port 443 de l’IP d’origine. Si l’appel reste sans réponse jusqu’au délai, vous reproduisez le 522. S’il est refusé tout de suite, vous êtes plutôt sur un 521.
- Regardez les règles du pare-feu à la même minute. Un DROP des plages Cloudflare explique le silence. Un REJECT expliquerait un 521.
- Comparez la charge. Une file d’attente pleine au niveau TCP se voit par des connexions qui n’arrivent pas, pas par des pages PHP lentes dans le journal.
- Testez le nom public avec un test d’URL. Tant que Cloudflare affiche 522, les visiteurs ne joignent pas l’origine, même si votre SSH fonctionne.
Les fonctionnalités de surveillance qui interrogent l’URL publique voient le 522. Un contrôle lancé sur le serveur, en local, ne le voit pas.
Débloquer le chemin
| Constat | Action |
|---|---|
| DROP des IP Cloudflare | Autoriser ces plages en entrée sur 80 et 443. Préférer une règle explicite à un oubli après un durcissement |
| Charge qui empêche d’accepter les connexions | Libérer des workers ou de la CPU. Le correctif est la capacité d’accepter, pas un index SQL |
| Chemin réseau coupé depuis Cloudflare seulement | Ouvrir un ticket hébergeur avec l’IP d’origine, l’heure et le fait qu’un autre réseau passe |
| IP d’origine injoignable | Vérifier que la machine est routée et que l’enregistrement Cloudflare pointe vers elle |
| Anti-DDoS trop agressif | Demander le déblocage des plages Cloudflare, pas une purge de cache |
Retestez le port depuis l’extérieur après chaque changement de pare-feu. Un test local dira toujours que « le site est up ».
Ce qu’un 522 n’est pas
Ce n’est pas une page à optimiser, ni un cache à purger. Ce n’est pas un 524 : allonger le temps laissé à PHP ne complète pas une poignée de main absente. Ce n’est pas un 521 : relancer le service web ne sert à rien s’il écoute déjà et que les paquets sont jetés avant. Ce n’est pas non plus le moment de changer le mode SSL.
Quand la connexion TCP revient, contrôlez que l’URL publique répond un code de l’origine, avec la méthode pour tester si un site répond vraiment. Jusque-là, le visiteur ne parle qu’à Cloudflare.