Erreur 522 Cloudflare : un délai de connexion expiré entre deux serveurs
L’erreur 522 (« Connection timed out ») n’est pas une panne du site vue depuis le navigateur — c’est un échec de dialogue entre deux machines qui ne se trouvent pas là où on l’imagine. Cloudflare, positionné en proxy devant le site pour accélérer le contenu et filtrer le trafic indésirable, tente d’établir une connexion TCP avec le serveur d’origine (l’hébergement réel du site) pour lui transmettre la requête du visiteur. Passé un délai fixe, si le serveur d’origine n’a pas répondu, Cloudflare abandonne et affiche cette page d’erreur à sa place.
Le visiteur ne voit donc jamais le vrai problème : son navigateur a bien joint Cloudflare, qui a bien tenté de relayer la requête, mais c’est le tronçon suivant — entre Cloudflare et l’hébergement — qui a échoué. Cette distinction change tout le diagnostic : contrairement à une erreur affichée directement par WordPress ou par le serveur web, la 522 indique que le serveur d’origine est soit injoignable, soit trop lent à répondre, sans préciser lequel des deux avant d’aller vérifier.
La différence avec les erreurs Cloudflare voisines
Cloudflare distingue plusieurs codes selon la nature exacte de l’échec, et confondre l’erreur 522 avec ses voisines fait perdre du temps de diagnostic. L’erreur 521 (« Web server is down ») signifie que le serveur d’origine a activement refusé la connexion — port fermé, service web arrêté, pare-feu qui bloque explicitement Cloudflare — alors que la 522 signifie qu’aucune réponse n’est arrivée dans le délai imparti, ce qui pointe plutôt vers une lenteur ou une perte de paquets que vers un refus net. L’erreur 523 (« Origin is unreachable ») indique que Cloudflare n’a même pas pu router la requête vers l’adresse IP du serveur, un problème de configuration réseau en amont plutôt qu’un souci côté hébergement. Cette nuance oriente directement les vérifications à faire en premier : un refus net (521) pousse à contrôler le pare-feu et le service web, un délai dépassé (522) pousse à contrôler la charge du serveur et la latence réseau.
Vérifier d’abord si le serveur d’origine répond réellement
Avant d’aller chercher une cause complexe, il faut confirmer que le serveur héberge toujours le site et répond aux requêtes directes. Depuis un panneau d’hébergement (cPanel, Plesk ou l’interface propriétaire de l’hébergeur), un simple accès au site en contournant temporairement Cloudflare — via l’adresse IP directe du serveur ou un fichier hosts modifié localement pour pointer dessus — révèle si le serveur répond normalement ou s’il est lui-même en difficulté. Une réponse rapide et correcte en accès direct signifie que le problème se situe dans le tunnel Cloudflare-serveur, pas dans le serveur lui-même ; une absence de réponse ou une lenteur confirmée oriente vers une surcharge réelle de l’hébergement.
Un test complémentaire utile : la commande traceroute (ou tracert sous Windows) vers l’adresse IP du serveur d’origine depuis une machine externe au réseau de l’hébergeur permet de repérer un saut réseau qui bloque ou ralentit anormalement le trafic entre Cloudflare et le serveur, en particulier si l’hébergeur applique un filtrage géographique ou un anti-DDoS agressif qui traite à tort les IP Cloudflare comme suspectes.
Les causes les plus fréquentes
Un serveur d’origine surchargé, incapable de traiter la requête dans le délai que Cloudflare accorde (par défaut 100 secondes, mais ramené à 15-30 secondes sur la plupart des configurations), est la cause la plus courante. Un pic de trafic, un script PHP long à exécuter ou une base de données lente à répondre suffisent à dépasser ce délai — un mécanisme proche de ce qui déclenche une erreur 508 Resource Limit Is Reached sur un hébergement mutualisé, sauf qu’ici le message vient de Cloudflare plutôt que du serveur lui-même.
Un pare-feu ou un système anti-DDoS côté hébergeur qui bloque ou limite spécifiquement les adresses IP de Cloudflare vient ensuite : certains hébergeurs, en particulier sur des offres d’entrée de gamme, appliquent des règles de limitation de débit qui traitent le volume de connexions Cloudflare comme un signal d’attaque, alors qu’il s’agit du trafic normal relayé pour l’ensemble des visiteurs du site. La solution consiste à autoriser explicitement la plage d’adresses IP publiée par Cloudflare (https://www.cloudflare.com/ips/) dans la configuration du pare-feu ou du service anti-DDoS de l’hébergement.
Un service web arrêté ou redémarré au mauvais moment (Apache, Nginx, ou le gestionnaire de processus PHP-FPM) produit le même symptôme de façon intermittente, en particulier après une intervention de maintenance côté hébergeur ou un crash silencieux consécutif à un pic de mémoire. Enfin, un certificat SSL invalide ou expiré côté serveur d’origine, quand le mode de chiffrement Cloudflare est réglé sur « Full » ou « Full (strict) », empêche l’établissement de la connexion sécurisée entre les deux serveurs — un point de vigilance distinct de l’expiration d’un certificat SSL côté visiteur, puisque celui-ci concerne le tronçon Cloudflare-origine et non Cloudflare-navigateur.
Corriger selon la cause identifiée
Si le serveur est surchargé, identifier le processus responsable via les outils de monitoring de l’hébergeur (utilisation CPU, mémoire, nombre de connexions à la base de données) et agir en conséquence : optimiser une requête lente, activer un cache objet pour réduire la charge sur la base de données, ou augmenter les ressources allouées si l’offre d’hébergement actuelle plafonne durablement en dessous du trafic réel du site.
Si le pare-feu bloque Cloudflare, ajouter la liste d’IP officielle à la liste blanche du pare-feu ou du système anti-DDoS, en configurant idéalement une règle qui se met à jour automatiquement si l’hébergeur le permet — Cloudflare fait évoluer occasionnellement ses plages d’adresses.
Si le service web est instable, consulter les journaux serveur (error.log d’Apache ou de Nginx) pour repérer un redémarrage inattendu ou une erreur de configuration récente, et contacter le support de l’hébergeur avec l’horodatage exact des erreurs 522 constatées pour croiser avec ses propres journaux d’infrastructure.
Si le mode SSL Cloudflare est en cause, vérifier que le certificat installé sur le serveur d’origine est valide et à jour, ou basculer temporairement le mode de chiffrement sur « Flexible » depuis le tableau de bord Cloudflare (onglet SSL/TLS) le temps de résoudre le certificat côté serveur — une mesure provisoire, pas une solution durable, puisqu’elle réduit le chiffrement du tronçon Cloudflare-origine.
Réduire le risque de récidive
Un monitoring actif de la disponibilité du serveur d’origine, indépendant de Cloudflare, permet de détecter une dégradation avant qu’elle ne déclenche l’erreur pour les visiteurs — la plupart des outils de supervision proposent une vérification directe par IP en plus du nom de domaine passant par le proxy. Ajuster le délai d’attente Cloudflare à la marge (paramètre disponible sur les offres Business et Enterprise) donne un peu plus de latitude à un serveur ponctuellement lent sans pour autant masquer un vrai problème de capacité.
Sur le fond, une erreur 522 récurrente sous charge normale est, dans la majorité des cas, le signal qu’un hébergement mutualisé a atteint ses limites de ressources partagées pour le trafic réel du site : les ressources garanties et le temps de réponse d’un serveur dédié infogéré éliminent ce type de goulot d’étranglement en supprimant la contention avec d’autres sites hébergés sur la même machine. Comparer les garanties de disponibilité et de temps de réponse annoncées par l’hébergeur reste le critère le plus concret à vérifier avant de migrer, plutôt que de se fier uniquement à l’espace disque ou à la bande passante affichés en avant sur les offres commerciales.