Une page WordPress affiche « Connection timed out » alors que l’administration reste parfois accessible et que l’hébergeur annonce aucun incident. Ce scénario pointe souvent vers l’erreur 522, un échec de communication entre Cloudflare et le serveur qui héberge réellement le site.
En bref
- L’Erreur 522 apparaît quand Cloudflare attend une réponse du serveur d’origine et que celle-ci n’arrive pas dans le délai prévu.
- Un pare-feu qui bloque les plages IP de Cloudflare, une saturation PHP ou MySQL, une mauvaise cible DNS et une latence réseau sont les causes les plus fréquentes.
- Le premier test utile consiste à vérifier si le site répond directement depuis le serveur d’origine, sans le proxy Cloudflare.
- Les logs Apache, Nginx, PHP-FPM et le tableau de bord de l’hébergeur permettent de distinguer un blocage de sécurité d’un serveur saturé.
- Une erreur ponctuelle ne détruit pas le SEO, mais des indisponibilités répétées empêchent Google de crawler et de mettre à jour les pages.
Erreur 522 : ce que Cloudflare signale réellement
L’Erreur 522 n’est pas un message produit par WordPress, WooCommerce ou un navigateur. Elle vient de Cloudflare, le réseau CDN et proxy placé entre les visiteurs et le serveur d’origine. Cloudflare reçoit la demande, tente de joindre l’hébergement, puis affiche « Connection timed out » lorsque ce serveur tarde trop à répondre.
Le navigateur du visiteur a donc bien atteint Cloudflare. Sa connexion internet n’est généralement pas en cause. Le blocage se situe après Cloudflare, sur le trajet vers l’IP de l’hébergement, ou directement sur la machine qui exécute PHP, interroge MySQL et sert les fichiers du site.
Cloudflare masque l’IP du serveur sans la remplacer
Quand le nuage orange est actif dans la zone DNS Cloudflare, le domaine pointe publiquement vers les adresses IP Cloudflare. Le CDN transmet ensuite la requête à l’adresse IP définie dans l’enregistrement A ou AAAA d’origine. Le serveur doit accepter cette connexion et retourner une réponse dans un délai cohérent.
Ce fonctionnement apporte du cache, une protection DDoS, un certificat SSL géré côté visiteur et des règles de filtrage. Il ajoute aussi un intermédiaire. Si l’IP d’origine est erronée, si le pare-feu bloque Cloudflare ou si PHP-FPM est coincé, Cloudflare ne peut pas inventer la page à la place du serveur.
Le cas classique survient après une migration. Le domaine a été déplacé vers un nouveau VPS, mais l’enregistrement A dans Cloudflare conserve l’ancienne IP. Les visiteurs voient une erreur 522, tandis que le propriétaire teste son nouveau serveur via un fichier hosts local et pense que tout fonctionne. Les deux tests ne passent pas par la même route.
Ne pas confondre 522, 521, 524 et 502
Ces codes se ressemblent à l’écran, mais ils ne demandent pas le même dépannage serveur. Une erreur 521 indique souvent que l’origine refuse explicitement la connexion. Une erreur 522 correspond à une connexion qui n’aboutit pas ou qui reste silencieuse trop longtemps. Une erreur 524 survient après une connexion établie, lorsque le serveur met trop longtemps à produire une réponse HTTP complète.
| Code affiché | Ce que Cloudflare observe | Piste de contrôle prioritaire |
|---|---|---|
| 521 | Le serveur refuse la connexion | Service web arrêté, port 80 ou 443 fermé, règle de firewall trop stricte |
| 522 | Le serveur ne répond pas assez vite à la tentative de connexion | IP Cloudflare bloquées, saturation du serveur, problème de routage |
| 524 | La connexion existe, mais la réponse applicative dépasse le délai | Requête PHP longue, export WooCommerce, requête SQL lente |
| 502 ou 503 | Le proxy reçoit une réponse invalide ou un service indisponible | PHP-FPM, Nginx, Apache, ressources mémoire ou maintenance |
Cette distinction évite de modifier au hasard wp-config.php ou de désactiver cinq extensions WordPress. Un timeout serveur n’est pas automatiquement un bug de thème. Il peut venir d’une règle réseau placée loin de WordPress, chez l’hébergeur ou sur le pare-feu du VPS.
Une erreur isolée pendant une opération de maintenance ne se traite pas comme une panne qui revient chaque matin à 10 heures. La fréquence, l’URL touchée et les traces dans les journaux donnent une direction beaucoup plus fiable que l’écran blanc affiché au visiteur.
Identifier la cause d’un problème de connexion entre Cloudflare et l’hébergement
Une erreur 522 apparaît rarement sans indice autour d’elle. Un pic de trafic, un déploiement, une sauvegarde lancée en pleine journée, une mise à jour de règle ModSecurity ou un changement DNS laisse souvent une trace. Le but du diagnostic n’est pas de deviner. Il faut isoler le maillon qui ne répond plus.
Le serveur d’origine peut être vivant mais saturé
Sur un hébergement mutualisé, le site partage processeur, mémoire et processus avec d’autres comptes. Une boutique WooCommerce de 2 000 produits, un constructeur comme Elementor, un filtre de recherche lourd et un plugin de sauvegarde qui archive tout en même temps peuvent épuiser les workers PHP disponibles. Les nouvelles requêtes s’accumulent alors en attente.
Le tableau de bord de l’hébergeur montre parfois des limites atteintes sur les processus, les entrées simultanées ou l’usage CPU. Chez cPanel, les sections « Resource Usage » ou « Utilisation des ressources » donnent souvent cette information. Sur un VPS, les commandes top, htop, free -m et df -h révèlent respectivement une charge CPU, une mémoire insuffisante ou un disque saturé.
Un site qui dépasse quatre secondes de chargement sur des pages non cachées n’est pas automatiquement condamné à une 522. En revanche, si les workers PHP restent occupés pendant 30 ou 60 secondes par des appels externes, la marge disparaît vite dès que plusieurs visiteurs arrivent en même temps. WP-Cron lancé à chaque visite peut aussi aggraver la situation sur un petit serveur.
Un pare-feu mal réglé bloque souvent Cloudflare
Cloudflare n’envoie pas les requêtes depuis une seule adresse IP. Ses plages IPv4 et IPv6 évoluent et sont publiées sur sa documentation officielle. Une whitelist saisie manuellement il y a plusieurs années devient vite obsolète, surtout après une configuration de fail2ban, CSF, UFW, ModSecurity ou un firewall fourni par l’hébergeur.
Le symptôme est reconnaissable. Le serveur répond lorsque le proxy Cloudflare est désactivé, mais les pages deviennent inaccessibles dès que le nuage orange revient. Les logs d’accès Nginx ou Apache ne montrent alors aucune requête Cloudflare, ou les logs du pare-feu signalent des paquets rejetés depuis leurs IP.
Sur un serveur avec CSF, l’autorisation des réseaux Cloudflare doit être automatisée ou vérifiée régulièrement. Sur une offre mutualisée, cette opération n’est souvent pas accessible. Le ticket à envoyer au support doit être précis, avec l’heure, le domaine, l’adresse IP d’origine et le Ray ID affiché sur la page Cloudflare.
DNS et IPv6 créent des pannes difficiles à voir
Un enregistrement A doit viser la bonne IPv4. Un enregistrement AAAA doit viser une IPv6 réellement configurée et routée vers le serveur. Le piège courant consiste à déplacer le site vers un hébergeur qui ne fournit pas encore d’IPv6, tout en laissant un ancien AAAA dans Cloudflare. Certains visiteurs ou nœuds réseau suivent alors une route cassée.
Le test passe par les outils DNS de Cloudflare, puis par dig ou nslookup. Il faut contrôler le domaine principal, www, les sous-domaines utilisés par l’API, ainsi que l’adresse déclarée dans les règles de redirection. Un sous-domaine api mal pointé peut casser le paiement ou une application headless alors que la page d’accueil continue de répondre.
La latence réseau peut aussi venir d’un incident de peering entre réseaux, sans que le CPU du serveur ne monte. Ce cas est moins fréquent qu’un firewall ou qu’une saturation, mais les logs et les tests depuis plusieurs emplacements permettent de l’identifier.
Le bon ordre de recherche commence donc par l’état du serveur, puis les règles de filtrage et enfin les DNS. Réinstaller un plugin de cache avant ces contrôles fait perdre du temps, car WP Rocket ou LiteSpeed Cache ne peuvent pas ouvrir un port réseau bloqué.
Faire un diagnostic réseau sans modifier le site au hasard
Un diagnostic réseau utile s’appuie sur des tests qui répondent chacun à une question précise. Le serveur est-il joignable directement ? Cloudflare atteint-il l’IP attendue ? Le service web écoute-t-il bien sur HTTPS ? Les logs confirment-ils le rejet ou la saturation ? Cette méthode évite de transformer une panne courte en incident prolongé.
Tester l’origine en contournant temporairement le proxy
Dans Cloudflare, l’onglet DNS affiche un nuage orange pour les enregistrements proxifiés. Passer temporairement le nuage en gris permet d’envoyer les visiteurs directement vers le serveur d’origine. Cette manipulation expose l’IP réelle et retire les protections Cloudflare pendant le test. Elle doit donc rester brève et être faite hors pic de trafic si le site reçoit beaucoup de visites.
Si le site répond immédiatement en DNS only, l’origine est probablement active. Il faut alors examiner la liste des IP Cloudflare autorisées et la configuration du firewall. Si le site reste indisponible sans proxy, le souci se trouve plus bas, côté hébergeur, processus PHP, certificat d’origine ou service web.
Un autre test consiste à viser l’IP du serveur avec une requête HTTP qui conserve le nom de domaine. Sur un poste doté de curl, la commande suivante est utile : curl -I –resolve exemple.fr:443:IP_DU_SERVEUR https://exemple.fr. Elle ne modifie aucun DNS. Elle permet de vérifier la réponse HTTPS servie par l’origine pour ce domaine précis.
Lire les logs au bon endroit et sur la bonne heure
Les journaux ne servent à rien si l’heure n’est pas alignée. La page Cloudflare affiche un Ray ID et l’heure de l’incident. Il faut chercher ce créneau dans les access logs et error logs Apache ou Nginx, dans les erreurs PHP-FPM et dans les événements du pare-feu. Un décalage de fuseau horaire entre le serveur et Cloudflare peut faire rater la trace pertinente.
Une erreur « connect() failed », « upstream timed out » ou « server reached max children setting » oriente vers le serveur web et PHP-FPM. Une trace « denied », « blocked » ou « DROP » dans CSF, UFW ou fail2ban oriente vers la sécurité. Des lignes MySQL montrant des requêtes lentes peuvent expliquer pourquoi les processus PHP ne se libèrent jamais.
Sur WordPress, active temporairement les traces applicatives dans wp-config.php seulement si l’erreur touche une action précise, comme un panier WooCommerce ou un formulaire. La constante WP_DEBUG_LOG écrit dans wp-content/debug.log lorsqu’elle est configurée. Elle ne remplace pas les logs système, car une 522 peut arriver avant même que WordPress reçoive la requête.
Vérifier les indicateurs Cloudflare et la disponibilité externe
Le tableau Analytics > Events de Cloudflare permet de repérer des règles WAF qui bloquent des requêtes. Les graphiques de trafic montrent aussi un pic soudain qui coïncide avec la panne. Un pic peut venir d’une campagne publicitaire, d’un bot agressif, d’un crawl mal maîtrisé ou d’un endpoint XML-RPC ciblé.
Un contrôle depuis plusieurs localisations évite d’accuser trop vite le serveur. Si le domaine répond en France et échoue depuis plusieurs régions, le problème peut concerner une route ou une IPv6 mal gérée. Si toutes les zones échouent et que le monitoring de l’hébergeur montre une charge maximale, la piste de la saturation devient prioritaire.
- Note l’URL exacte, l’heure et le Ray ID affichés avec l’erreur.
- Contrôle l’IP A et AAAA dans Cloudflare, puis compare-les à celles fournies par l’hébergeur.
- Passe provisoirement l’enregistrement concerné en DNS only pour comparer la réponse directe.
- Consulte les usages CPU, RAM, processus PHP et espace disque au même créneau.
- Recherche les rejets Cloudflare dans les logs du firewall avant de modifier WordPress.
Cette séquence produit des éléments exploitables pour le support technique. Dire « mon site est cassé » déclenche une réponse standard. Envoyer l’URL, l’horaire UTC, le Ray ID, le résultat en DNS only et une capture des limites serveur réduit fortement les échanges inutiles.
Résolution d’erreur 522 selon la panne trouvée
La résolution d’erreur dépend de la preuve obtenue pendant le diagnostic. Un firewall qui filtre Cloudflare ne se règle pas comme un PHP-FPM à bout de souffle. Modifier simultanément DNS, plugins, cache et règles de sécurité rend le résultat impossible à interpréter.
Autoriser les réseaux Cloudflare dans le pare-feu
Si le test direct fonctionne et que la version proxifiée échoue, il faut autoriser toutes les plages IP Cloudflare publiées dans la documentation officielle. La liste doit être ajoutée dans le pare-feu du système, celui du panneau d’hébergement et, si besoin, dans les règles de sécurité externes. Une règle ajoutée seulement dans Wordfence ne débloque pas un rejet effectué avant l’arrivée de la requête dans WordPress.
Les serveurs Nginx ou Apache derrière Cloudflare doivent aussi être configurés pour restaurer la vraie IP du visiteur via les en-têtes Cloudflare. Sans cette configuration, les logs voient surtout des IP Cloudflare. Cela n’explique pas directement une 522, mais une mauvaise lecture des logs peut pousser fail2ban à bloquer le proxy au lieu du bot réel.
Après ajout des autorisations, le test doit se faire avec le nuage orange réactivé. Une réponse correcte pendant quelques secondes ne valide pas tout. Surveille les erreurs pendant plusieurs heures si le blocage était déclenché par un seuil de sécurité ou par une montée de trafic.
Réduire la charge quand PHP et MySQL attendent
Un mutualisé bas de gamme tient correctement une vitrine WordPress de quelques pages, mais il sature vite avec WooCommerce, des filtres Ajax, des imports et un trafic régulier. Ajouter un cache de page aide les visiteurs non connectés. Cela ne soulage pas assez un panier, une page compte ou un tableau d’administration qui nécessite des réponses dynamiques.
Commence par repérer les extensions qui déclenchent des appels longs. Les sauvegardes à chaque requête, les statistiques internes, les connecteurs vers des API lentes et les constructeurs surchargés créent des files d’attente. Query Monitor peut révéler les requêtes SQL longues en environnement de test. Il ne doit pas rester actif durablement en production sur un site déjà fragile.
Configure WP-Cron comme une vraie tâche cron côté hébergeur au lieu de le lancer sur chaque visite. Limite les sauvegardes aux périodes calmes et envoie les archives vers un stockage externe. Sur un VPS, augmente le nombre de workers PHP-FPM seulement si la mémoire le permet. Multiplier les processus sur 1 Go de RAM finit souvent en swap, puis en temps de réponse encore plus mauvais.
Un changement d’offre devient justifié lorsque les limites sont atteintes de façon répétée avec un trafic normal. Passer d’un mutualisé bridé à une offre WordPress mieux dimensionnée ou à un VPS administré coûte plus cher, mais conserver une boutique inaccessible pendant les pics coûte directement des commandes. Le bon hébergeur dépend du trafic, du nombre de pages dynamiques et du niveau d’administration que tu acceptes.
Corriger les DNS sans casser la messagerie
Dans Cloudflare, corrige l’enregistrement A qui cible l’ancienne IP et supprime l’AAAA devenu inutile. Vérifie aussi que les enregistrements MX, SPF, DKIM et DMARC restent présents. Une migration DNS menée trop vite peut régler une 522 tout en bloquant les e-mails transactionnels de WooCommerce.
La propagation observée dépend du TTL et des caches résiduels. Cloudflare applique rapidement ses modifications internes, mais des tests locaux peuvent garder une ancienne résolution pendant un moment. Utilise un résolveur DNS public différent ou vide le cache DNS du poste avant de conclure que la correction n’a rien changé.
Quand les mesures montrent que l’origine reste serveur injoignable malgré une IP correcte et un firewall ouvert, l’hébergeur doit intervenir. Le ticket doit demander la vérification des ports 80 et 443, de la route vers Cloudflare, des événements de limitation et de l’état du nœud d’hébergement au créneau exact.
Limiter les retours de timeout serveur et protéger le référencement
Une erreur 522 de quelques minutes ne fait pas tomber un domaine dans Google du jour au lendemain. Le risque apparaît lorsque les indisponibilités deviennent répétées, longues ou touchent des pages que Google visite souvent. Le robot reçoit alors une réponse d’échec au lieu du contenu, ce qui ralentit le crawl et retarde la prise en compte des mises à jour.
Surveiller la disponibilité avant que les visiteurs signalent la panne
Un monitoring HTTP externe interroge une URL à intervalle régulier depuis plusieurs emplacements. Il doit surveiller la page d’accueil, mais aussi une page produit, un endpoint API et, pour WooCommerce, une page non cachée si le parcours d’achat dépend de réponses dynamiques. Une page d’accueil servie depuis le cache Cloudflare peut être verte alors que le serveur d’origine souffre déjà.
Les alertes doivent arriver sur une adresse consultée ou un canal utilisé par l’équipe. Une alerte par e-mail dans une boîte rarement ouverte ne résout rien. L’historique aide aussi à relier les incidents à une sauvegarde, à une mise à jour de plugin, à un cron ou à un pic de trafic provenant d’une campagne.
Cloudflare Analytics permet de comparer les erreurs côté edge et les requêtes reçues par l’origine. Les logs du serveur complètent cette lecture. Si Cloudflare reçoit 10 000 requêtes et que Nginx n’en voit qu’une fraction pendant l’incident, le filtrage ou le réseau mérite une vérification. Si Nginx les voit toutes mais que PHP répond trop tard, la charge applicative est en cause.
Éviter les réglages WordPress qui aggravent les pointes
Un thème qui charge quinze extensions et interroge l’API REST à chaque affichage n’est pas adapté à une petite offre mutualisée. Les Core Web Vitals et la disponibilité ne sont pas le même sujet, mais des scripts lourds, une base de données gonflée et des requêtes lentes font monter le temps passé sur le serveur. Quand plusieurs visiteurs arrivent, la marge disparaît.
Garde un cache cohérent, pas trois couches qui se contredisent. Sur un serveur LiteSpeed, LiteSpeed Cache est généralement le choix logique. Sur Nginx ou Apache, WP Rocket peut couvrir le cache de page et plusieurs optimisations front-end, à condition de tester le panier, les formulaires et les espaces membres après chaque réglage.
Évite de purger tout le cache Cloudflare après chaque modification mineure. Une purge complète force l’origine à reconstruire de nombreuses pages au même moment. Purger une URL précise ou les fichiers touchés limite ce pic. Les règles de cache doivent exclure les zones sensibles, comme /cart/, /checkout/ et /my-account/ sur WooCommerce.
Traiter l’impact SEO avec des données plutôt qu’avec le taux de rebond
Le « taux de rebond » n’est pas un levier de classement direct à piloter comme un compteur de panne. Le problème SEO concret est l’accessibilité. Dans Google Search Console, le rapport d’exploration et l’inspection d’URL permettent de voir si Googlebot rencontre des échecs de récupération ou si les pages restent accessibles.
Une indisponibilité courte appelle une surveillance. Une série d’erreurs sur plusieurs jours demande une correction d’infrastructure avant de publier davantage de contenu. Une nouvelle page ne peut pas être correctement crawlée si le serveur répond une fois sur deux. Le SEO technique commence par un site que les visiteurs et les robots peuvent joindre.
Garde une fiche d’incident avec l’heure, la durée, l’URL, le Ray ID, la charge serveur et la correction appliquée. Après deux ou trois occurrences, ce document montre si le problème vient d’une même extension, d’une règle de sécurité ou d’un hébergement sous-dimensionné. C’est plus utile que de redémarrer le serveur à chaque panne sans comprendre ce qui l’a provoquée.
L’erreur 522 vient-elle de la connexion internet du visiteur ?
Dans la plupart des cas, non. Le navigateur a atteint Cloudflare, puis Cloudflare n’a pas obtenu de réponse assez rapide du serveur d’origine. Le problème se situe habituellement côté hébergement, pare-feu, DNS ou réseau entre Cloudflare et l’origine.
Désactiver Cloudflare règle-t-il durablement une erreur 522 ?
Passer temporairement un enregistrement DNS en nuage gris aide à isoler la panne. Si le site répond alors correctement, il faut vérifier les plages IP Cloudflare autorisées et les règles de sécurité. Laisser Cloudflare désactivé durablement retire le cache, le proxy et les protections associées sans corriger la cause.
Une erreur 522 peut-elle venir de WordPress ?
WordPress peut contribuer au problème si PHP, MySQL, WP-Cron ou une extension consomment les ressources disponibles jusqu’à bloquer les réponses. Pourtant, une 522 peut aussi survenir avant que WordPress ne soit exécuté, par exemple avec une IP DNS erronée ou un pare-feu qui rejette Cloudflare.
Quelle information envoyer au support de l’hébergeur ?
Transmets le domaine concerné, l’heure exacte de l’incident avec le fuseau horaire, le Ray ID Cloudflare, l’adresse IP d’origine, le résultat du test sans proxy et les éventuelles lignes de logs. Le support peut alors contrôler le routage, les ports 80 et 443, les limitations et la charge du serveur.