Erreur 522 Cloudflare : connexion expirée, que faire

Erreur 522 Cloudflare : ce qu’elle signifie

L’erreur 522 Cloudflare signifie que Cloudflare a bien reçu la requête du visiteur, mais n’a pas réussi à établir la connexion avec votre serveur d’origine dans le temps imparti. Le serveur reste silencieux : pare-feu qui bloque les IP Cloudflare, serveur surchargé, mauvais port ou keep-alive coupé.

Votre site n’est pas forcément perdu. Le visiteur atteint Cloudflare sans problème, le blocage se situe entre Cloudflare et votre hébergeur. Dans la majorité des cas, la cause se trouve en quelques vérifications, à faire dans un ordre précis.

Cas typique : un site WordPress fonctionne depuis des mois, puis affiche soudain la 522 sur une partie des visiteurs seulement. Rien n’a changé côté contenu, mais l’hébergeur a durci son pare-feu la veille. Ce scénario revient très souvent.

Ne confondez pas la 522 avec ses voisines. En 521, l’origine refuse activement la connexion (Cloudflare Docs, erreur 521) : voir l’erreur 521 Web Server Is Down. La 523 pointe une origine injoignable, souvent une mauvaise IP dans le DNS : voir l’erreur 523. La 524 survient quand la connexion est établie mais que la réponse arrive trop tard : voir l’erreur 524. La 520, elle, correspond à une réponse vide ou inattendue : voir l’erreur 520.

Pourquoi la 522 arrive

Un handshake TCP est l’échange en trois temps (SYN, SYN+ACK, ACK) qui ouvre une connexion entre deux machines avant tout échange de données. En 522, ce handshake n’aboutit jamais, donc aucune requête n’atteint votre application. D’après ScalaHosting, 2026, Cloudflare abandonne s’il ne reçoit pas de SYN+ACK sous 19 secondes, ou si l’origine n’accuse pas réception sous 90 secondes après l’ouverture de la connexion. Ces délais viennent d’une source de second rang, à recouper avec la documentation Cloudflare.

Les causes les plus fréquentes :

• Un pare-feu ou un plugin de sécurité bloque ou limite les IP Cloudflare.
• Le serveur d’origine est arrêté, planté ou saturé.
• L’enregistrement DNS A ou AAAA pointe vers une mauvaise IP.
• Le serveur écoute sur un autre port que celui attendu par Cloudflare.
• Le keep-alive est désactivé ou réglé trop court.
• Des paquets se perdent sur le chemin réseau entre Cloudflare et l’origine.

Le pare-feu est la cause commune aux erreurs 520, 521 et 522 (Cloudflare Docs, erreur 520). Commencez donc par là, mais seulement après l’étape 1.

1. Vérifiez que le serveur d’origine répond vraiment

Avant de toucher au moindre réglage, confirmez que le serveur est en vie. Sinon vous cherchez une règle de pare-feu alors que la machine est arrêtée.

1. Connectez-vous au panel de votre hébergeur et regardez l’état du serveur (en ligne, redémarrage, maintenance en cours).
2. Consultez la page de statut de l’hébergeur : un incident réseau explique beaucoup de 522 intermittentes.
3. Testez l’IP d’origine directement, sans passer par Cloudflare : curl -I http://IP_ORIGINE -H "Host: votresite.fr" depuis votre poste ou un autre serveur.
4. Si vous avez un accès SSH, vérifiez que le service web tourne (systemctl status nginx ou apache2).

Si le serveur ne répond pas du tout, le problème n’est pas Cloudflare. Redémarrez le service ou contactez l’hébergeur.

Évitez les gestes inutiles : vider les cookies, changer de navigateur ou réinstaller des plugins n’a aucun effet tant que la connectivité de l’origine n’est pas confirmée (ScalaHosting, 2026).

2. Autorisez toutes les IP Cloudflare dans le pare-feu

Un pare-feu est un filtre qui accepte ou rejette les connexions entrantes selon leur adresse, leur port et leur fréquence. Tout votre trafic arrive désormais depuis un petit nombre d’IP Cloudflare : le pare-feu les voit comme une attaque et les bloque ou les limite. Un trafic concentré sur peu d’IP peut déclencher les règles anti-DDoS de l’origine (Elementor, 2026).

La procédure officielle demande de confirmer que les IP Cloudflare ne sont ni bloquées ni limitées en débit, puis d’autoriser toutes les plages dans le pare-feu (Cloudflare Docs, erreur 521). Ces vérifications valent aussi pour la 522.

À contrôler, dans cet ordre :

1. Le pare-feu système : iptables -L -n ou ufw status. Cherchez des règles qui rejettent ou limitent les plages Cloudflare.
2. Le fichier .htaccess : des lignes Deny from ou Require not ip peuvent viser ces plages.
3. Les plugins de sécurité (Wordfence, iThemes et équivalents) : désactivez temporairement le blocage d’IP pour tester.
4. Le pare-feu de l’hébergeur (groupes de sécurité, liste blanche du panel) : certains hébergeurs exigent une liste blanche séparée du pare-feu système (Host-Tracker, 2026).

Récupérez la liste à jour sur la page Cloudflare IP Ranges (fichiers texte ips-v4 et ips-v6). Elle comprend par exemple 103.21.244.0/22, 104.16.0.0/13 et, en IPv6, 2606:4700::/32. Une liste copiée une fois puis jamais mise à jour devient incomplète : la plage 2405:b500::/32 a été ajoutée le 28 septembre 2023 (Cloudflare, IP Ranges).

Indice géographique : si la 522 n’apparaît que dans certaines zones, une plage correspondant à ces zones a probablement été oubliée. Si les IP en échec sont toujours les mêmes, un équipement réseau de l’hébergeur en bloque une partie (Cloudflare Community, 2018).

Autoriser les IP Cloudflare corrige la 522, mais ne suffit pas à sécuriser l’origine : l’idéal est d’ajouter les Authenticated Origin Pulls et de valider l’en-tête Host (Javan Rasokat, 2025).

3. Cherchez une surcharge du serveur

Un serveur saturé n’accepte plus de nouvelles connexions : le handshake traîne, puis expire. Les logs de l’application sont souvent vides, puisque la requête n’arrive jamais jusqu’à elle. Regardez plutôt la charge CPU, la mémoire et le nombre de connexions (ss -s, netstat) ainsi que les logs du pare-feu (Host-Tracker, 2026).

Points à vérifier :

• La charge CPU et la RAM au moment des pannes.
• Les limites de connexions ou de workers, par exemple worker_connections dans nginx, ou le nombre de processus PHP-FPM.
• Un pic de visites, un robot qui moissonne le site ou un plugin lourd.

Sur un mutualisé, la saturation vient souvent des quotas : voir l’erreur 508 Resource Limit Reached et la mémoire PHP épuisée sur WordPress. Si le trafic a dépassé les capacités de l’offre, passer d’un mutualisé à un VPS est la solution durable.

4. Contrôlez le DNS, le port et le mode SSL côté Cloudflare

Passez maintenant côté Cloudflare, dans le tableau de bord de la zone.

1. DNS : l’enregistrement A (IPv4) ou AAAA (IPv6) du domaine doit pointer vers l’IP actuelle de l’hébergeur. Après une migration, c’est la première chose à revérifier.
2. Port : Cloudflare se connecte en HTTP sur le port 80 et en HTTPS sur le 443 par défaut. Confirmez que le serveur écoute bien sur le port attendu.
3. Mode SSL/TLS : un mode « Full » ou « Full (strict) » exige un HTTPS fonctionnel à l’origine. Un mode mal choisi provoque des erreurs, parfois d’autres codes : voir l’erreur 525.
4. Règles et load balancers : une règle de redirection ou un pool d’origines mal réglé peut envoyer le trafic vers une machine éteinte.

Notez le Ray ID affiché sur la page d’erreur : l’hébergeur ou le support Cloudflare s’en servent pour retrouver la requête.

5. Activez le keep-alive et réglez le délai

Le keep-alive désigne le maintien d’une connexion TCP ouverte entre deux requêtes, pour éviter de refaire un handshake à chaque fois. Désactivé, il multiplie les nouvelles connexions et fait monter la charge. Activez le TCP keepalive sur le serveur d’origine et sur tout load balancer, et vérifiez que les réglages du système ne restent pas à des valeurs par défaut trop longues (Host-Tracker, 2026).

Sous Apache, la directive KeepAlive On se règle dans la configuration du serveur. Sous nginx, c’est keepalive_timeout. Sur un mutualisé, la configuration est gérée par l’hébergeur : demandez-lui de la contrôler.

Autre astuce de diagnostic : configurer le pare-feu pour rejeter les paquets avec un reset plutôt que de les abandonner en silence. Une 522 devient alors une 521, plus facile à diagnostiquer (Host-Tracker, 2026).

6. Exclure le réseau et l’intermittence

Si tout est correct mais que l’erreur revient, le problème vient peut-être du chemin réseau entre Cloudflare et l’hébergeur : perte de paquets, incident temporaire ou équipement qui limite le trafic. Une 522 peut aussi disparaître seule quand la charge baisse ou qu’une nouvelle tentative réussit (Cloudways, 2025).

Notez les heures, les Ray ID et les zones géographiques touchées, puis transmettez-les à l’hébergeur. Il pourra consulter ses logs réseau, que vous n’avez pas.

Tableau récapitulatif : cause, symptôme, solution

FAQ

Quand passer la main à un pro

Faites appel à un professionnel dans ces cas : vous n’avez pas accès au pare-feu, l’hébergeur répond que tout est normal alors que la 522 persiste, ou l’erreur est intermittente sans motif clair. Un technicien sait lire les logs réseau et la charge, et corriger la configuration sans couper le site.

Ces pannes sont rarement un hasard : une liste d’IP non mise à jour ou un serveur sous-dimensionné se repèrent avant que les visiteurs ne voient l’erreur. C’est ce que couvre une maintenance par abonnement.