Ce que signifie chaque code, en une phrase

Ces trois erreurs sont générées par l'edge Cloudflare et non par votre application, ce qui explique qu'elles n'apparaissent jamais dans vos journaux applicatifs. Elles décrivent trois moments de rupture différents entre le proxy Cloudflare et votre serveur d'origine :

  • Erreur 521, « Web Server Is Down » : Cloudflare a joint l'adresse de votre origine et la connexion a été explicitement refusée. Quelque chose est vivant à l'origine, et ce quelque chose dit non. En général le processus du serveur web est arrêté ou redémarre en boucle, il n'écoute pas sur le port exigé par votre mode SSL/TLS, ou un outil de sécurité de l'origine rejette les adresses Cloudflare.
  • Erreur 522, « Connection Timed Out » : Cloudflare n'a obtenu aucune réponse exploitable. L'edge abandonne si aucun SYN+ACK ne revient dans les 19 secondes qui suivent son SYN, ou si l'origine n'accuse pas réception de la requête dans les 90 secondes une fois la connexion TCP établie. Rien n'a été refusé : les paquets sont partis dans le vide.
  • Erreur 524, « A Timeout Occurred » : la connexion a fonctionné, la requête a été acceptée, et l'origine a simplement mis trop de temps à répondre. Le Proxy Read Timeout par défaut est de 125 secondes. Un Proxy Write Timeout distinct de 30 secondes s'applique quand Cloudflare écrit des données vers l'origine, et celui-là n'est ajustable sur aucun plan.

La différence entre les trois constitue l'essentiel du diagnostic, et c'est justement l'étape que l'on saute. Un 521 est un refus, un 522 est un silence, un 524 est une lenteur. Un refus désigne un service arrêté ou un mauvais port d'écoute. Un silence désigne un pare-feu, une pile réseau saturée ou une adresse d'origine périmée. Une lenteur désigne le code applicatif et la base de données. Rien dans un 524 ne relève du réseau, et aucune optimisation SQL ne corrigera jamais un 521.

Un réflexe utile : conserver un historique du code qui apparaît, quand, et depuis quel pays. Des 521 concentrés en salves signifient généralement que le serveur web redémarre sans cesse, tandis que des 524 regroupés sur un seul endpoint pointent vers du code lent plutôt qu'une panne de connectivité. Cloudflare expose cela dans Zone Analytics, où les erreurs se filtrent par code de statut edge et se ventilent par URL, adresse source et centre de données.

Le protocole d'audit et de correction recommandé

Pour rétablir une disponibilité continue et éliminer ces pannes intermittentes :

  • Autorisation intégrale des plages IP Cloudflare : Configurer les règles de filtrage de l'origine (pare-feu d'hébergeur et système) pour autoriser l'intégralité des sous-réseaux IPv4 et IPv6 officiels de Cloudflare sans restriction de débit.
  • Restauration des IP réelles des visiteurs : Installer les modules appropriés (mod_remoteip pour Apache, ngx_http_realip_module pour Nginx) afin d'éviter que vos outils anti-brute force locaux ne pénalisent les adresses du proxy.
  • Maintien des keepalives : Cloudflare réutilise les connexions TCP ouvertes vers votre origine et documente les keepalives désactivés comme cause directe de 522. Laissez-les actifs avec un délai raisonnable.
  • Traitement asynchrone des tâches lourdes : Déporter les exports complexes et traitements différés vers des workers d'arrière-plan pour maintenir les réponses HTTP largement sous la limite de lecture de 125 secondes.

Origine sous nginx : d'où vient réellement le 522

Nginx accepte les connexions bien plus vite qu'il ne peut les confier à une application. Sur une origine nginx, le 522 est donc presque toujours une affaire de budget de connexions, pas un nginx à l'arrêt.

  • Connexions de worker épuisées. Quand nginx n'a plus de worker_connections ou de descripteurs de fichiers disponibles, les nouvelles connexions s'accumulent dans la file d'acceptation du noyau et ne reçoivent jamais de réponse, c'est-à-dire exactement le silence que décrit un 522. Lisez les valeurs en vigueur et les sockets d'écoute d'un coup : 
    nginx -T | grep -E "worker_connections|keepalive_timeout|listen "
  • File d'acceptation pleine. Sur l'origine, un Recv-Q qui colle au Send-Q sur le port 443 signifie que la file est saturée et que les connexions sont abandonnées avant même que nginx ne les voie : 
    ss -ltn | grep -E ":80|:443"
  • Keepalives désactivés. Un keepalive_timeout 0; impose une nouvelle connexion TCP pour chaque requête depuis chaque centre de données Cloudflare. Les keepalives désactivés à l'origine figurent explicitement parmi les causes de 522 listées par Cloudflare.
  • Limites par adresse appliquées au proxy. Une zone limit_req ou limit_conn indexée sur $binary_remote_addr compte tout le réseau Cloudflare comme une poignée de clients tant que set_real_ip_from et real_ip_header CF-Connecting-IP ne sont pas configurés. Ces directives renvoient un 503 et non un 522, mais c'est la même erreur de lecture qui pousse fail2ban à bannir les proxys et à faire tomber le site.
  • Le 502 qui n'est pas un 522. Si nginx tourne mais que le socket PHP-FPM ou l'upstream Node est mort, nginx répond 502 et Cloudflare le transmet tel quel. Voir un vrai 502 dans le navigateur prouve donc que nginx a répondu : le problème est derrière nginx, pas entre Cloudflare et nginx.

Dans la plupart de ces cas, le journal d'erreurs nginx nomme directement la cause : 

grep -iE "worker_connections|too many open files|accept" /var/log/nginx/error.log | tail -20

Origine sous Apache : même symptôme, autres réglages

  • Saturation du pool de workers. Dès que tous les workers sont occupés, Apache cesse d'accepter de nouvelles connexions et l'edge ne voit qu'un silence. Vérifiez le MPM chargé et la façon dont les hôtes virtuels sont liés : 
    apachectl -M | grep mpm
apachectl -S
    Augmenter MaxRequestWorkers n'aide que si la machine a la mémoire correspondante ; le vrai correctif consiste presque toujours à supprimer les requêtes lentes qui monopolisent les workers.
  • Aucun écouteur sur le port qu'exige le mode SSL/TLS. apachectl -S liste chaque hôte virtuel et son port. Une zone en Full ou Full (strict) sans hôte virtuel sur le port 443 produit un 521 net, à chaque requête et partout.
  • Listes d'accès héritées. Cloudflare cite nommément .htaccess parmi les endroits où ses adresses finissent bloquées. Une directive Require ip ou Deny from écrite avant l'activation du proxy refuse l'edge et renvoie un 521.
  • Modules anti-abus qui lisent la mauvaise adresse. mod_evasive et ses équivalents voient des adresses Cloudflare au lieu des visiteurs tant que mod_remoteip n'est pas configuré avec RemoteIPHeader CF-Connecting-IP et les plages Cloudflare déclarées comme proxys de confiance.
  • Directives de timeout et 524. Les réglages Timeout et mod_reqtimeout d'Apache décident du moment où Apache abandonne, pas du moment où Cloudflare abandonne. Si Apache patiente au-delà de 125 secondes, le visiteur voit un 524 Cloudflare pendant que votre journal d'accès enregistre un 200 plusieurs minutes plus tard.

Une origine derrière un pare-feu qui bloque les plages IP de Cloudflare

La documentation de Cloudflare en fait la cause la plus fréquente de 522 : ses adresses limitées ou bloquées dans .htaccess, iptables ou un pare-feu. La correction n'est pas difficile, mais elle échoue de trois façons prévisibles, toutes évitables.

  1. Récupérez la liste à jour plutôt qu'une copie. Les plages changent. Ne recopiez jamais des adresses depuis un article, y compris celui-ci. Cloudflare publie la liste de référence sur www.cloudflare.com/ips, en texte brut exploitable par un script, et en JSON sur le point d'entrée public de l'API : 
    curl -s https://www.cloudflare.com/ips-v4
curl -s https://www.cloudflare.com/ips-v6
curl -s https://api.cloudflare.com/client/v4/ips
    La réponse JSON porte un etag : c'est lui que l'on compare lors d'un rafraîchissement planifié pour savoir si quelque chose a bougé.
  2. Appliquez-les à chaque niveau, dans la même session. Groupe de sécurité cloud, pare-feu de l'hôte, liste d'autorisation applicative ou .htaccess, et liste d'exclusion de tout outil anti-abus type fail2ban ou CrowdSec. Autoriser les plages à un endroit et pas à l'autre est la première raison pour laquelle un 522 survit à sa correction : chaque niveau renvoie alors la faute à l'autre. Exemple avec UFW, les deux familles d'adresses d'un coup : 
    for ip in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow from "$ip" to any port 443 proto tcp
done
  3. N'oubliez jamais l'IPv6. Cloudflare utilise couramment ses plages IPv6. N'autoriser que l'IPv4 fait échouer une partie des connexions selon la famille d'adresses choisie par l'edge, ce qui est la signature typique d'un 522 intermittent que personne n'arrive à reproduire à la demande.
  4. Rafraîchissez sur une planification. Une autorisation posée une fois vieillit. Placez la récupération dans une tâche mensuelle qui réécrit les règles, plutôt que de découvrir l'écart en pleine panne.
  5. Envisagez de ne pas exposer l'origine du tout. Cloudflare Tunnel remplace entièrement les règles entrantes : le daemon cloudflared ouvre des connexions sortantes uniquement vers Cloudflare sur le port 7844, donc l'origine n'a besoin d'aucune adresse publique, d'aucun port entrant ouvert et d'aucune liste d'adresses à maintenir. Sur une origine auto-hébergée, cela supprime toute la catégorie de problème.
  6. Filtrez par pays à l'edge, pas à l'origine. Si l'objectif initial était d'écarter certaines régions, exprimez-le dans les règles de sécurité Cloudflare. Bloquer des plages d'adresses à l'origine pour y parvenir finit immanquablement par attraper le proxy lui-même.

Un 522 sur Cloudflare Pages ou un Worker, là où il n'y a pas d'origine classique

Un 522 sur un projet sans serveur à soi ressemble à une contradiction, et c'est pour cela que ces cas coûtent le plus de temps. Il en existe quatre réels, dont les trois premiers sont documentés par Cloudflare.

  • Cloudflare Pages avec un domaine personnalisé. Sur un projet Pages, un 522 signifie presque toujours que le domaine n'est pas raccordé des deux côtés. Le domaine personnalisé doit être ajouté au projet, et l'enregistrement CNAME doit pointer vers ce domaine personnalisé Pages. Un CNAME resté sur l'hébergeur précédent, ou un domaine jamais déclaré sur le projet, produit un 522 alors que l'URL en .pages.dev continue de fonctionner parfaitement.
  • Un Worker sur un Custom Domain qui interroge son propre hostname. C'est le cas contre-intuitif. Cloudflare indique clairement qu'un Worker déployé sur un Custom Domain effectuant un fetch vers son propre hostname provoque un 522, la requête rebouclant dans le Worker au lieu d'atteindre une origine. Les options documentées sont d'utiliser une Route plutôt qu'un Custom Domain, de viser un autre hostname, ou d'activer le compatibility flag global_fetch_strictly_public.
  • Une Origin Rule qui pointe vers du vide. Si une Origin Rule envoie le trafic vers un hostname impossible à résoudre, par exemple une route Worker dont l'enregistrement A est une adresse réservée comme 192.0.2.0, l'edge renvoie un 522.
  • Un service tiers appelé depuis un Worker ou une fonction Pages. Celui-là se comporte autrement que ce que l'on imagine. Cloudflare ne documente aucune limite de durée sur une sous-requête individuelle : une API externe lente ne déclenche donc pas un délai de lecture qui lui serait propre. Ce que l'on observe, c'est une requête qui reste suspendue jusqu'à ce que le visiteur parte, ou l'erreur que votre propre code décide de renvoyer. Quand un vrai 522 apparaît sur un tel appel, il provient en général de la zone Cloudflare du tiers et ne fait que remonter jusqu'à votre page. La protection utile consiste à borner vous-même chaque appel externe, avec un AbortSignal.timeout() autour du fetch, et à renvoyer un statut que vous avez choisi plutôt qu'un statut subi.

« Ça ne plante que quand mon VPN est activé »

Cette recherche revient souvent et mérite une réponse honnête, parce que la plupart du temps le propriétaire du site poursuit quelque chose qui ne lui appartient pas. Un 522 se joue entre Cloudflare et votre origine, et la connexion du visiteur n'a aucune influence sur le fait que l'origine réponde. Une page qui fonctionne sans VPN et échoue avec relève donc de trois situations, dont une seule vous incombe.

  • Ce n'est pas réellement un 522. Les adresses de sortie mutualisées des VPN traînent une mauvaise réputation, et ce qu'elles déclenchent en pratique est un Managed Challenge, un CAPTCHA, ou une page 1020 émise par une règle de sécurité. Pour le visiteur cela ressemble à un site en panne, mais cela n'a rien à voir avec la connectivité vers l'origine. Lisez le code imprimé sur la page avant toute chose. Si quelqu'un signale « le site est down sur mon VPN », demandez une capture d'écran plutôt qu'une description.
  • Un autre centre de données Cloudflare, et une autorisation incomplète. C'est le cas qui vous appartient vraiment. Le VPN déplace votre point de sortie, un autre site Cloudflare vous sert, et ce site contacte votre origine depuis une autre adresse. Si votre liste d'autorisation est périmée ou recopiée d'une ancienne source, certains sites passent et d'autres sont rejetés. Le symptôme est un site qui fonctionne pour la majorité et échoue pour une minorité, apparemment au hasard. Filtrer les erreurs par centre de données dans Zone Analytics le confirme en une minute, et réappliquer les plages complètes le corrige.
  • Le VPN lui-même. Les clients d'entreprise qui inspectent le TLS, un split tunneling mal configuré, un nœud de sortie saturé ou une résolution DNS forcée dans le tunnel cassent la connexion avant même que Cloudflare n'intervienne. Si la même URL s'ouvre depuis un téléphone en 4G et n'échoue qu'à travers un VPN précis, le site n'est pas en cause et aucune modification de votre côté n'y changera rien.

L'erreur 524, les traitements longs, et que faire quand on ne peut pas les raccourcir

Un 524 signifie que la connexion était bonne et l'application trop lente. Le chronomètre est le Proxy Read Timeout, 125 secondes par défaut, auquel s'ajoute un Proxy Write Timeout fixe de 30 secondes quand Cloudflare écrit des données vers l'origine. Aucun des deux n'est ajustable hors Enterprise : la vraie question est donc quoi faire d'un export, d'un rapport ou d'un import qui prend légitimement trois minutes.

  • Répondre immédiatement, puis interroger l'état. La recommandation de Cloudflare pour les traitements HTTP volumineux est justement le status polling. L'endpoint accepte la tâche, répond en quelques millisecondes avec un identifiant, et le navigateur demande l'état toutes les quelques secondes. C'est la seule option qui passe à l'échelle, et elle survit à une coupure côté visiteur.
  • Déplacer l'endpoint vers un sous-domaine non proxifié. Cloudflare suggère de placer les requêtes qui dépassent régulièrement 125 secondes derrière un sous-domaine en nuage gris. Le compromis est réel : ce hostname perd le proxy et son adresse devient publique. À réserver à un export d'administration, jamais à une route publique.
  • Commencer à répondre tôt. Le délai compte le temps sans réponse de l'origine : un endpoint qui envoie ses en-têtes et un premier fragment rapidement se comporte très différemment d'un endpoint qui bufferise tout pendant deux minutes avant de vider. Diffuser un long rapport en flux plutôt que de l'assembler en mémoire supprime souvent l'erreur sans rien accélérer.
  • Mettre en cache le résultat coûteux. Si la réponse lente est identique pour tout le monde, seule la première requête devrait la payer. Notre guide sur les raisons pour lesquelles le cache Cloudflare ne fonctionne pas et comment le corriger détaille la structure de règles qui rend cela sûr.
  • Enterprise uniquement : relever le délai. Le Proxy Read Timeout peut être porté jusqu'à 6 000 secondes sur les zones Enterprise, via une Cache Rule ou l'API de réglages de zone. Cloudflare signale un écart possible d'une seconde entre la valeur posée et le déclenchement réel de l'erreur : réglez donc une seconde au-dessus de votre cible.

Ce qui ne marche pas et que l'on tente quand même : redémarrer le serveur, ce qui n'accélère pas une requête de 90 secondes ; augmenter max_execution_time en PHP, ce qui change le moment où votre code renonce et non celui où Cloudflare cesse d'attendre ; et ajouter de la mémoire à une machine dont le goulot d'étranglement est un index manquant en base.

Diagnostiquer pas à pas : de curl à une origine stable

Suivez ces étapes dans l'ordre. Chacune réduit le champ de recherche avant toute modification, et d'autres checklists de ce type sont disponibles dans notre hub de guides Cloudflare.

  1. Caractérisez le schéma de défaillance. Échantillonnez le site pendant une minute et notez quel code apparaît et à quelle fréquence : 
    for i in $(seq 1 30); do curl -s -o /dev/null -w "%{http_code}\n" https://www.exemple.com/; sleep 2; done
    Des réponses 200 et 521 alternées pointent vers un serveur web qui redémarre en boucle. Des 522 en salves signifient généralement un bridage par pare-feu ou une saturation. Des 524 sur un seul endpoint pointent vers du code applicatif lent plutôt qu'un problème réseau.
  2. Notez ce dont vous aurez besoin pour escalader. Cloudflare demande le code exact, l'heure avec son fuseau et l'URL en échec avant que quiconque puisse aider. Le Ray ID identifie la requête : 
    curl -sI https://www.exemple.com/ | grep -iE "^HTTP|cf-ray|server"
  3. Séparez un problème réseau d'un délai applicatif grâce aux temps. Une seule commande indique vers lequel des trois codes vous vous dirigez : 
    curl -s -o /dev/null https://www.exemple.com/ \
  -w "connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n"
    Une phase de connexion qui n'aboutit jamais relève du 522. Une connexion normale avec un temps jusqu'au premier octet qui grimpe au-delà de quelques secondes annonce un 524. Une connexion qui échoue instantanément est un refus, donc un 521.
  4. Testez l'origine directement, en contournant le proxy. Récupérez l'adresse d'origine depuis votre panneau d'hébergement ou un enregistrement de test en nuage gris, puis : 
    curl -sI --resolve www.exemple.com:443:203.0.113.10 https://www.exemple.com/
    Si cette requête échoue ou expire aussi, le problème se situe côté origine et Cloudflare n'est que le messager.
  5. Demandez-vous si le port est seulement joignable. Depuis une machine extérieure à votre hébergement : 
    nc -vz 203.0.113.10 443
    Un « Connection refused » relève du 521, une attente indéfinie relève du 522. La distinction vaut trente secondes, car elle vous envoie vers deux interlocuteurs différents.
  6. Vérifiez sur quels ports le serveur web écoute. Sur l'origine, confirmez que le daemon lie réellement les ports attendus : 
    ss -tlnp | grep -E ":80|:443"
    Un daemon à l'écoute uniquement en IPv6, ou sur un port personnalisé, explique un 521 qui survit aux redémarrages du service.
  7. Cherchez une saturation plutôt qu'un blocage. Un pare-feu et une machine surchargée produisent le même silence, mais les compteurs, eux, ne mentent pas : 
    ss -s
nstat -az | grep -iE "ListenDrops|ListenOverflows|TCPBacklogDrop"
dmesg -T | grep -iE "conntrack|table full|drop" | tail -20
    Des compteurs non nuls et qui progressent pendant l'incident signifient que l'origine abandonne des connexions sous charge, et non qu'une règle les rejette.
  8. Autorisez toutes les plages IP Cloudflare, à chaque niveau. Appliquez les listes à jour comme décrit plus haut, au groupe de sécurité cloud et au pare-feu de l'hôte, en IPv4 et en IPv6, et ajoutez-les à la liste d'exclusion de tout outil anti-abus.
  9. Restaurez les IP réelles des visiteurs à l'origine. Configurez mod_remoteip (Apache) ou ngx_http_realip_module (Nginx) pour que les limiteurs de débit et détecteurs de brute force lisent l'adresse du visiteur depuis CF-Connecting-IP au lieu de l'adresse du proxy. Sinon, une journée chargée suffit pour que fail2ban bannisse les proxys eux-mêmes et fasse tomber tout le site.
  10. Vérifiez le chemin réseau, dans les deux sens. Un traceroute depuis l'extérieur apprend peu de chose ; ce que le support Cloudflare demande, c'est un relevé depuis votre origine vers une adresse Cloudflare vue dans vos propres journaux : 
    mtr -rwc 50 198.41.128.1
    Lancez-le pendant l'incident, pas après, et conservez la sortie.
  11. Vérifiez le mode SSL/TLS. Dans SSL/TLS > Overview, privilégiez Full (strict) avec un certificat d'origine valide. Un décalage entre le mode de l'edge et l'écoute de l'origine produit des échecs de connexion ou de handshake qui se manifestent en codes 52x, parfois seulement sur certaines URLs. Ne le « réglez » pas en basculant sur Flexible : cela échange une erreur contre une boucle de redirection, comme l'explique notre guide sur la boucle de redirection HTTPS infinie derrière Cloudflare.
  12. Profilez tout ce qui répond en plus de quelques secondes. Pour les erreurs 524, activez le log des requêtes lentes de votre base de données, vérifiez la saturation des pools PHP-FPM ou un event loop Node.js bloqué, et déportez exports, génération de rapports et webhooks vers des files d'arrière-plan. Chaque endpoint public doit répondre largement sous la limite des 125 secondes.

Les erreurs fréquentes qui entretiennent les coupures

  • Autoriser les adresses Cloudflare à un seul niveau : Autoriser les plages sur le groupe de sécurité cloud mais pas sur le pare-feu de l'hôte (ou l'inverse) laisse le trafic bloqué, et chaque niveau renvoie la faute à l'autre.
  • Autoriser l'IPv4 en oubliant l'IPv6 : La moitié des connexions échoue alors selon la famille d'adresses choisie par l'edge, ce qui est la signature typique d'un 522 intermittent.
  • Recopier une liste d'adresses au lieu de la récupérer : Les plages changent. Une liste copiée dans un script de pare-feu il y a trois ans est une panne programmée, et elle échoue en silence jusqu'au jour où une nouvelle plage est utilisée.
  • Laisser les outils anti-abus locaux bannir les proxys : fail2ban ou un limiteur applicatif qui voit des milliers de requêtes depuis une poignée d'adresses finira par toutes les bannir, faisant tomber tous les visiteurs d'un coup.
  • Lire un 502 comme un 522 : Un 502 signifie que votre serveur web a répondu et que son upstream non, donc Cloudflare transmet votre propre erreur. Y chercher un problème de pare-feu coûte un après-midi.
  • Traiter le 524 comme un incident réseau : Redémarrer le serveur ne rend pas une requête SQL de 90 secondes plus rapide. Un 524 signifie que la connexion était bonne et l'application trop lente ; la correction se trouve dans le code et la base de données, pas dans le pare-feu.
  • Laisser une adresse d'origine périmée dans le DNS : Après une migration de serveur, un enregistrement A pointant encore vers l'ancienne machine produit des erreurs 521 ou 522 qui vont et viennent avec la propagation. Vérifiez DNS > Records avant de toucher à quoi que ce soit ; notre guide sur les emails cassés après migration vers Cloudflare détaille l'hygiène des enregistrements DNS.

Questions fréquentes

Que signifie l'erreur Cloudflare 522 ?

Elle signifie que Cloudflare a tenté de joindre votre serveur d'origine et n'a obtenu aucune réponse exploitable dans les délais. L'edge abandonne si aucun SYN+ACK ne revient dans les 19 secondes qui suivent son SYN, ou si l'origine n'accuse pas réception de la requête dans les 90 secondes une fois la connexion TCP établie. Rien n'a refusé la connexion et rien n'a été trop long à calculer : les paquets sont partis dans le vide. D'après la documentation de Cloudflare, la cause la plus fréquente est un pare-feu d'origine qui bloque ou limite les plages d'adresses IP de Cloudflare.

Comment corriger l'erreur Cloudflare 522 connection timed out ?

Dans cet ordre. Vérifiez d'abord que l'origine répond, en interrogeant son adresse directement avec curl --resolve. Autorisez ensuite toutes les plages IPv4 et IPv6 actuelles de Cloudflare à chaque niveau de filtrage : groupe de sécurité cloud, pare-feu de l'hôte, listes d'autorisation applicatives ou .htaccess, et outils anti-abus comme fail2ban. Vérifiez que l'origine n'est pas saturée en regardant la file d'attente d'acceptation TCP et les compteurs ListenOverflows. Confirmez que l'enregistrement A ou AAAA dans le DNS Cloudflare correspond toujours à l'adresse réellement attribuée par votre hébergeur. Les keepalives doivent rester activés côté origine.

Comment corriger l'erreur Cloudflare 521 ?

Un 521 est un refus actif : quelque chose est bien vivant à l'origine et dit non. Vérifiez que le processus du serveur web tourne et ne redémarre pas en boucle, puis qu'il écoute sur le port exigé par votre mode SSL/TLS : le port 80 pour Flexible, le port 443 pour Full et Full (strict). Confirmez que l'origine sert réellement du HTTPS avec un certificat valide si vous êtes en Full ou Full (strict). Cherchez enfin un outil de sécurité qui refuse les adresses Cloudflare : une liste dans .htaccess, une directive Require ip, un pare-feu système ou fail2ban.

Erreur 522 Cloudflare avec nginx : par où commencer ?

Par la saturation, puis par les keepalives. Quand nginx épuise worker_connections, les nouvelles connexions s'empilent dans la file d'acceptation du noyau et ne reçoivent jamais de réponse, ce qui correspond exactement à un 522. Regardez la colonne Recv-Q de ss -ltn sur le port 443, et le journal d'erreurs nginx à la recherche de worker_connections ou de « too many open files ». Vérifiez ensuite que keepalive_timeout n'est pas à 0, Cloudflare documentant les keepalives désactivés à l'origine comme cause de 522. Si nginx tourne mais que l'upstream PHP-FPM ou Node est mort, vous obtenez un 502 transmis au visiteur, pas un 522.

Pourquoi Cloudflare Pages renvoie-t-il une erreur 522 ?

Sur un projet Pages, un 522 traduit presque toujours un domaine personnalisé mal raccordé. La documentation de Cloudflare demande de vérifier que le domaine personnalisé a bien été ajouté au projet et que l'enregistrement CNAME pointe vers ce domaine personnalisé Pages. Un CNAME resté sur un ancien hébergeur, ou un domaine jamais déclaré côté projet, produit un 522 alors qu'il n'existe aucun serveur d'origine vous appartenant dans la chaîne.

Un Worker Cloudflare peut-il renvoyer le code d'erreur 522 ?

Oui, et le cas documenté est contre-intuitif : un Worker déployé sur un Custom Domain qui effectue un fetch vers son propre hostname provoque un 522, la requête rebouclant dans le Worker au lieu d'atteindre une origine. Cloudflare propose d'utiliser une Route plutôt qu'un Custom Domain, de viser un autre hostname, ou d'activer le compatibility flag global_fetch_strictly_public. Une Origin Rule pointant vers un hostname non résolvable produit le même code. Une API tierce lente est un cas différent : Cloudflare ne documente aucune limite de durée sur une sous-requête individuelle, on observe donc plutôt une requête qui reste suspendue ou une erreur renvoyée par votre propre code.

Pourquoi ai-je une erreur Cloudflare 522 avec un VPN ?

Un 522 se joue entre Cloudflare et votre origine : la connexion du visiteur ne change normalement rien au fait que l'origine réponde ou non. Commencez par lire le code affiché sur la page, car les adresses de sortie mutualisées des VPN déclenchent en général un Managed Challenge, un CAPTCHA ou une page 1020, pas un 522. Le seul cas qui vous incombe vraiment est une liste d'autorisation partielle : le VPN déplace votre point de sortie, un autre centre de données Cloudflare vous sert, il contacte votre origine depuis une autre adresse, et une liste périmée la rejette. Si la page s'affiche depuis un téléphone en 4G et échoue uniquement via un VPN précis, le site n'est pas en cause.

Qu'est-ce qu'une « 522 host error » Cloudflare ?

Ce n'est pas un code distinct. La page d'erreur 522 de Cloudflare affiche trois segments, votre navigateur, le centre de données Cloudflare et votre hébergeur, et signale le segment hébergeur comme défaillant. L'expression « 522 host error » vient simplement de ce libellé à l'écran. Le diagnostic est celui de n'importe quel 522 : l'edge n'a pas obtenu de réponse exploitable de votre origine.

Pourquoi les erreurs 522 n'apparaissent-elles qu'à certains moments de la journée ?

Parce que la cause est un seuil franchi, pas un blocage permanent. Les pics de trafic épuisent un budget de connexions, un seuil fail2ban se déclenche après des connexions répétées, ou le pare-feu de l'hôte applique une limitation de débit qui ne s'active que sous charge. Échantillonner le taux d'erreur sur une journée complète révèle généralement le schéma.

Les conseils que l'on trouve sur Reddit à propos de l'erreur 522 sont-ils justes ?

Les deux réponses qui dominent ces fils, autoriser les plages IP de Cloudflare et ouvrir un ticket chez l'hébergeur, sont justes la plupart du temps et sautent toutes deux une étape. L'autorisation ne sert que si vous appliquez la liste à jour à chaque niveau, IPv6 compris, et un ticket hébergeur n'avance que si vous fournissez le code exact, l'horodatage avec son fuseau et l'URL, c'est-à-dire précisément ce que Cloudflare demande de transmettre. Deux conseils fréquents sont à écarter : mettre Cloudflare en pause masque le symptôme sans rien apprendre, et basculer le mode SSL/TLS en Flexible échange un 522 contre une boucle de redirection.

Faut-il un plan Cloudflare payant pour corriger les erreurs 521, 522 ou 524 ?

Non. Ces trois erreurs sont générées par l'edge selon le comportement de l'origine, et la correction se situe toujours dans votre infrastructure : règles de pare-feu, ports d'écoute ou performance applicative. Les listes d'IP Cloudflare sont publiques et utilisables sur tous les plans, y compris Free. Les plans supérieurs changent le support dont vous bénéficiez, pas la nature du correctif. La seule exception est l'augmentation du délai du 524, qui est un réglage Enterprise.

Peut-on augmenter la limite de 125 secondes derrière l'erreur 524 ?

Uniquement sur les zones Enterprise, où le Proxy Read Timeout peut être porté jusqu'à 6 000 secondes via une Cache Rule ou l'API de réglages de zone. Sur tous les autres plans la limite est fixe : les options pratiques consistent à rendre l'endpoint plus rapide, à renvoyer un identifiant de tâche et interroger son état, à mettre en cache la réponse coûteuse, ou à déplacer l'endpoint long vers un sous-domaine non proxifié.

Ces erreurs affectent-elles mon référencement ?

Des erreurs répétées lors des crawls sont interprétées comme de l'instabilité, et des pages qui renvoient systématiquement des 5xx peuvent être retirées de l'index. Disponibilité et cache doivent généralement être corrigés ensemble ; notre guide sur l'optimisation du cache montre comment absorber les pics de trafic à l'edge pour que moins de requêtes atteignent une origine fragile.

Votre site subit des coupures intermittentes inexpliquées ?

CF Garage diagnostique la chaîne de liaison entre Cloudflare et votre origine, identifie les goulots d'étranglement et fiabilise vos connexions. Tarif fixe, intervention sans risque d'interruption.

Voir nos offres

Ressources et guides complémentaires