Erreur 522 : C’est quoi et comment la résoudre ?

C’est quoi l’erreur 522 exactement ?

L’erreur 522 survient quand Cloudflare n’arrive pas à établir une connexion TCP avec ton serveur d’origine. Le handshake réseau échoue ou expire avant d’aboutir.

Concrètement, le visiteur voit une page Cloudflare affichant « Connection timed out » avec le code 522. Le problème se situe entre Cloudflare et ton origin, pas entre le visiteur et Cloudflare. C’est différent d’une 524 (connexion établie mais réponse trop longue) ou d’une 502 (erreur de passerelle). L’enchaînement normal : visiteur → Cloudflare → serveur. Avec une 522, le « bouchon » est côté serveur : Cloudflare lance la requête mais n’obtient jamais la poignée de main initiale.

Deux scénarios typiques que je rencontre souvent :

Le serveur est carrément down ou injoignable (crash, maintenance, service arrêté).
Un firewall ou des règles iptables bloquent les IP Cloudflare sans que tu t’en rendes compte.

L’erreur 522 n’est presque jamais « chez Cloudflare ». Je commence toujours par vérifier l’origin : ports ouverts, firewall, charge serveur, DNS. Neuf fois sur dix, la cause est là.

Les causes techniques de l’erreur 522

Ton serveur d’origine ne répond pas ou met trop de temps à accepter la connexion. C’est généralement réseau, firewall ou ressources. Je liste les causes les plus fréquentes et comment les reconnaître rapidement grâce aux symptômes et aux logs.

Serveur d’origine injoignable ou éteint

Si ton serveur est down, en crash, en maintenance imprévue, ou que les ports 80/443 ne sont pas ouverts, Cloudflare ne peut simplement pas se connecter. Parfois, c’est juste le service web (Nginx, Apache, PHP-FPM) qui est arrêté.

Pour vérifier : lance un ping ou traceroute vers l’IP du serveur, puis teste avec curl directement sur l’IP en passant l’en-tête Host. Utilise telnet ou nc -vz IP 80 pour tester le port. Contrôle le statut des services avec systemctl status nginx, consulte l’uptime et vérifie le statut chez ton provider.

Dans les logs, tu ne verras aucune entrée ou des erreurs « connection refused » / « timeout ».

Surveille ton hôte avec UptimeRobot ou StatusCake. Active le redémarrage automatique des services via systemd (Restart=on-failure). Prévois un fallback ou une page statique si le service est critique.

Timeout de connexion trop court

Parfois, la pile réseau ou le serveur abandonne le handshake TCP trop vite : SYN backlog saturé, keepalive ou temps d’attente trop courts, surcharge momentanée. Le serveur ne traite pas la connexion à temps, et Cloudflare timeout.

Vérifie les paramètres côté Nginx (backlog, worker_connections), Apache (ListenBackLog) et kernel (net.core.somaxconn, net.ipv4.tcp_synack_retries, keepalive). Un cas typique : des pics de trafic saturent la file d’attente, les sockets disponibles sont épuisés.

Firewall ou règles iptables bloquantes

UFW, iptables, CSF, Fail2ban peuvent bloquer les IP Cloudflare par erreur : règles trop larges, blocage par pays/ASN, rate-limiting agressif. Cloudflare essaie de se connecter, mais le firewall drop la connexion.

Vérifie la liste des règles (iptables -S, ufw status), consulte les journaux (/var/log/ufw.log, logs Fail2ban). Regarde le Cloudflare Ray ID côté WAF. Teste depuis une IP Cloudflare pour reproduire.

Correctif : mets en allowlist l’ensemble des plages IP Cloudflare (IPv4 et IPv6). Désactive les blocages abusifs, ajuste les seuils Fail2ban.

Mon conseil : centralise tes règles firewall dans un fichier de conf versionné. Documente l’allowlist Cloudflare et automatise sa mise à jour avec un script cron qui récupère les plages officielles.

Configuration DNS incorrecte

Si tes enregistrements A/AAAA pointent vers la mauvaise IP, si tu as un AAAA actif sans IPv6 stable côté serveur, un proxy orange mal positionné, ou un CNAME en chaîne vers un autre CDN, Cloudflare ne saura pas où aller.

Utilise dig ou nslookup pour vérifier : compare l’IP réelle de ton serveur avec celle renvoyée par DNS. Teste en orange cloud et grey cloud pour isoler. Vérifie le TTL et la propagation. Si tu héberges plusieurs domaines, contrôle le SNI.

Correctif : corrige l’IP dans Cloudflare, retire le AAAA si IPv6 n’est pas prêt, évite les boucles CDN.

Mon conseil : valide toujours en préprod avec un override hosts local avant de pousser en prod. Garde un fichier d’inventaire DNS à jour.

Surcharge serveur et manque de ressources

CPU/RAM saturés, connexions concurrentes élevées, base de données lente, disque en IO wait, table conntrack pleine : ton origin n’accepte plus de nouvelles connexions. Cloudflare tente, mais le serveur est trop occupé pour répondre.

Vérifie avec top/htop, iostat, vmstat, netstat -s ou ss -s (états SYN_RECV élevés). Consulte les logs d’erreurs, les métriques PHP-FPM (max_children atteint), MySQL (threads_connected).

Correctif : augmente les ressources (CPU, RAM, workers), optimise les requêtes lentes, active le cache edge et applicatif, limite les bursts, scale horizontalement.

Comment diagnostiquer l’erreur 522 sur votre site ?

Je suis une procédure terrain en plusieurs étapes pour isoler la cause :

Reproduire : vérifie si le 522 est global ou sporadique. Consulte Cloudflare Analytics, identifie les zones touchées, note le Ray ID.
Tester la connectivité à l’origin : lance curl -I -H "Host: domaine.com" http://IP_ORIGIN:80 et https://IP_ORIGIN:443 (avec SNI si nécessaire). Utilise nc -vz IP 80 et nc -vz IP 443 pour tester les ports.
Logs : inspecte access.log et error.log de Nginx/Apache, journalctl -u nginx, journalctl -u php-fpm, dmesg pour les erreurs kernel/network.
Firewall : liste les règles avec ufw status ou iptables -S. Consulte le journal Fail2ban/CSF. Compare avec les plages IP Cloudflare officielles.
Charge : lance top/htop, ss -s pour compter les connexions, ss -ltnp pour vérifier les ports en écoute et les backlogs.
DNS : exécute dig A domaine.com et dig AAAA domaine.com +trace. Vérifie que l’IP correspond et que le proxy orange est actif.

Mon conseil : documente chaque test (commande + résultat) dans un fichier texte ou un ticket. Isole un changement à la fois pour éviter de masquer la cause. Instrumente un healthcheck HTTP léger sur /health qui renvoie 200 si tout va bien, ça simplifie le debug.

Solutions concrètes pour résoudre l’erreur 522

Pars toujours du diagnostic pour corriger la cause racine. Je donne ici les corrections rapides et les durables. Teste après chaque changement et monitore en continu.

Vérifier l’état de votre serveur web

Étapes concrètes :

Redémarre proprement les services web : systemctl restart nginx, systemctl restart apache2, systemctl restart php-fpm. Vérifie le statut avec systemctl status.
Confirme que les ports 80 et 443 sont en écoute : ss -ltnp | grep -E ':80|:443'. Si fermés, ouvre-les avec ufw allow 80,443/tcp.
Vérifie les certificats SSL si tu es en HTTPS : chaîne complète, SNI configuré, expiration.
Si la VM ou le serveur est down : consulte la console de ton provider (OVH, AWS, DigitalOcean…), vérifie les incidents réseau, redémarre si nécessaire.

Mon conseil : active le redémarrage automatique avec systemd (ligne Restart=on-failure dans le service). Mets en place une page de statut publique (status.monsite.com). Rédige un runbook interne « incident 522 » pour gagner du temps.

Configurer correctement les IP Cloudflare

Actions à mener :

Mets en allowlist toutes les plages IP Cloudflare (IPv4 et IPv6) dans UFW, iptables, CSF ou le WAF de l’origin. Liste officielle disponible sur cloudflare.com/ips.
Désactive les règles qui bloquent l’ASN de Cloudflare ou qui appliquent un geo-block touchant les PoP.
Restaure l’IP visiteur réelle dans les logs : real_ip_header CF-Connecting-IP; sous Nginx, mod_remoteip sous Apache. Ça te permet de garder des filtres pertinents sans bloquer Cloudflare.

Mon conseil : automatise la mise à jour des plages avec un script cron qui télécharge et applique les nouvelles IP. Garde une doc interne à jour avec les commandes exactes.

Ajuster les paramètres de timeout

Actions :

Augmente prudemment keepalive_timeout, worker_connections, backlog (Nginx), Timeout, KeepAlive, MaxRequestWorkers (Apache).
Ajuste le kernel : net.core.somaxconn, net.ipv4.tcp_synack_retries, net.ipv4.tcp_max_syn_backlog.
Évite les scripts lents à l’initialisation : charge paresseuse, cache warmup, traitement asynchrone pour libérer la réponse initiale.

Mon conseil : mesure avant/après (latence TCP, connexions en SYN_RECV). Ajuste par palier et teste en charge avec ab ou wrk.

Examiner votre fichier .htaccess et vos règles firewall

Actions :

Inspecte .htaccess (rewrites, conditions IP) et la conf Nginx (location, deny). Vérifie qu’aucune règle ne rejette les ranges Cloudflare.
Audite Fail2ban (jails trop agressives), ModSecurity ou le WAF origin (règles qui drop), rate-limiting par IP.
Nettoie les doublons et les priorités de règles. Consigne les exceptions dans un fichier de conf dédié.

Mon conseil : commence en mode « log only » pour valider, puis resserre progressivement. Teste avec une IP Cloudflare simulée pour reproduire le comportement avant de déployer en prod.

Vérifier vos enregistrements DNS

Actions :

Confirme que les enregistrements A/AAAA pointent vers la bonne IP publique. Retire le AAAA si IPv6 n’est pas stable côté serveur.
Évite les chaînes CNAME vers d’autres proxys. Teste en désactivant temporairement le proxy orange (grey cloud) pour isoler l’origin.
Réduis le TTL pendant les interventions. Valide la propagation avec dig +trace. Vérifie le SNI si tu héberges plusieurs domaines.

Mon conseil : garde un fichier d’inventaire DNS avec IP principale, IP de secours, TTL. Documente la procédure de bascule. Valide toujours avec un override hosts local avant de pousser.

Impact de l’erreur 522 sur votre SEO et vos conversions

L’indisponibilité liée à une 522, c’est une perte directe de sessions et de revenus. Les visiteurs tombent sur une page d’erreur et repartent. Ton taux de rebond explose, les conversions chutent, et les moteurs de recherche enregistrent des signaux négatifs.

Côté SEO, Google Search Console remonte des « Server error (5xx) » sur les URL touchées. Le crawl ralentit sur ces pages. Si l’erreur est récurrente, les URL peuvent être désindexées progressivement. Tes positions baissent, ton autorité aussi.

Mon conseil : priorise la stabilité avant l’optimisation. Active le cache côté edge (Cloudflare Page Rules, Cache Everything). Envisage Always Online si pertinent, pour servir des versions statiques en cas de panne. Surveille les rapports de couverture et les taux d’erreurs dans Search Console.

Mesure l’impact : compare sessions, taux de conversion et CA pendant l’incident avec la période normale. Configure des alertes dès 1 % d’erreurs 522 sur 15 minutes. Réagis vite : chaque minute d’indisponibilité te coûte en trafic, en conversions et en SEO.

Métrique	Pendant incident 522	Normal
Sessions	↓ 50–100 %	Stable
Taux de rebond	↑ 80–100 %	~40 %
Conversions	↓ 100 %	Stable
Erreurs 5xx (Search Console)	↑ pics	~0 %