Quand ChatGPT, X, Canva ou un site client affichent soudain une page Cloudflare, le mauvais réflexe consiste souvent à redémarrer le serveur, modifier le DNS ou vider tous les caches. J’ai vu ces manipulations aggraver les dégâts au lieu de résoudre le problème. Une erreur HTTP 5xx peut venir du réseau Cloudflare, du serveur d’origine ou d’un incident local. La première étape consiste donc à vérifier la panne avant de changer quoi que ce soit.
Vérifier rapidement si Cloudflare est réellement en panne
Cloudflare sert d’intermédiaire entre le navigateur et le serveur du site. Son infrastructure fournit notamment un CDN, un proxy, la terminaison TLS, la protection contre les attaques DDoS et un pare-feu applicatif Web. Si l’un de ces composants rencontre un incident, plusieurs services indépendants peuvent devenir inaccessibles alors que leurs serveurs d’origine continuent de fonctionner.
Les signaux qui pointent vers un incident global
Une panne Internet Cloudflare se reconnaît rarement à partir d’un seul site. Cherchez plutôt plusieurs indices concordants : des domaines sans lien entre eux échouent, une page d’erreur Cloudflare s’affiche, les codes HTTP 500 ou 5xx se multiplient et des produits comme Access ou Turnstile cessent aussi de fonctionner. ChatGPT, Claude, X/Twitter, Canva, Doctissimo, Marmiton et League of Legends ont déjà été touchés lors d’incidents distincts.
Pour connaître l’état du réseau, consultez la page de statut Cloudflare, puis faites un test depuis un autre accès, par exemple une connexion mobile. Si le site fonctionne en 4G mais pas sur le réseau de votre entreprise, le problème n’est probablement pas mondial. À l’inverse, lorsque plusieurs utilisateurs, régions et services signalent la même erreur, évitez les manipulations précipitées.
| Symptôme observé | Cause possible | Premier réflexe |
|---|---|---|
| Erreur 500 ou 5xx sur plusieurs sites | Incident chez Cloudflare ou chez un autre intermédiaire | Vérifier la page de statut |
| Un seul domaine est inaccessible | Serveur d’origine, DNS ou règle de sécurité | Tester le domaine depuis un autre réseau |
| Erreur 521, 522 ou 524 | Origine indisponible, délai dépassé ou refus de connexion | Contrôler les journaux du serveur |
| Turnstile ou Access ne charge plus | Produit Cloudflare affecté | Suivre l’état du produit concerné |
Pourquoi une panne Cloudflare donne l’impression qu’Internet s’arrête
Un CDN réduit la distance entre un visiteur et le contenu demandé. Cloudflare reçoit la requête, peut servir une copie en cache, applique ses règles de sécurité, puis transmet la demande au serveur d’origine si nécessaire. Cette organisation améliore les performances et la protection, mais elle crée aussi un point de passage commun. Un incident du proxy peut donc toucher des milliers de domaines simultanément.
Le point fragile n’est pas toujours le serveur. Il peut se trouver entre une configuration centrale et son déploiement mondial. Une modification apparemment minime, propagée sur des machines réparties dans plusieurs régions, peut provoquer une défaillance en cascade. Une architecture résiliente doit donc pouvoir bloquer, annuler et isoler une mauvaise configuration avant qu’elle ne se diffuse à tout le réseau.
Tous les produits ne subissent pas nécessairement le même impact. Le CDN peut afficher des erreurs 5xx tandis que Workers KV renvoie des erreurs, que Cloudflare Access refuse certaines authentifications ou que Warp devient temporairement indisponible. À l’inverse, le cache peut encore permettre à certains visiteurs d’afficher une page statique. Deux internautes peuvent donc obtenir des résultats opposés sur le même site.
Deux incidents distincts, deux causes internes documentées
Les incidents du 18 novembre et du 5 décembre 2025 doivent être distingués. Les regrouper donnerait une explication trop vague, car leurs mécanismes diffèrent. Dans les deux cas, Cloudflare a indiqué qu’il ne s’agissait ni d’une cyberattaque ni d’une attaque DDoS.
| Incident | Impact et durée | Cause technique |
|---|---|---|
| 18 novembre 2025, 11 h 20 UTC | Retour de la majeure partie du trafic à 14 h 30 UTC ; systèmes entièrement opérationnels à 17 h 06 UTC | Modification de permissions dans ClickHouse, fichier de fonctionnalités Bot Management trop volumineux et propagation toutes les 5 minutes |
| 5 décembre 2025, 8 h 47 UTC | Résolution à 9 h 12 UTC, soit environ 25 minutes ; près de 28 % du trafic HTTP concerné | Modification de configuration WAF et bug Lua dans le proxy FL1 lors de la désactivation d’un outil de test |
Lors du premier incident, la modification des permissions a généré un fichier incorrect. Après sa diffusion sur le réseau, ce fichier a dépassé une limite logicielle et provoqué des erreurs HTTP 5xx. Lors du second, une protection liée aux React Server Components avait fait passer le tampon WAF de 128 Ko à 1 Mo. La désactivation d’un outil de test a ensuite déclenché un chemin logiciel défectueux dans FL1 : l’objet rule_result.execute attendu par Lua était absent. Le proxy FL2, développé en Rust, n’a pas présenté ce comportement.
Que faire côté internaute ou propriétaire de site
Pour un internaute, la règle est simple : ne réinitialisez pas votre box après une seule erreur. Testez un autre site, un autre navigateur et un autre accès réseau. Si l’incident est confirmé, attendre le rétablissement reste plus efficace que multiplier les tentatives. Ces essais ne corrigent ni la latence ni la disponibilité du réseau Cloudflare.
Pour un propriétaire de site, procédez dans cet ordre :
- Contrôlez le statut global et les produits Cloudflare utilisés.
- Notez l’heure, le code exact, l’URL et la région des visiteurs concernés.
- Vérifiez que le serveur d’origine répond directement, sans modifier la zone DNS.
- Consultez les journaux d’origine pour distinguer un délai applicatif d’une erreur proxy.
- Évitez de changer les règles WAF, les certificats ou le mode proxy pendant un incident confirmé.
Après le retour à la normale, surveillez les erreurs 5xx et les temps de réponse pendant quelques heures. Une disponibilité revenue ne prouve pas que votre origine est saine. Elle indique seulement que le chemin réseau répond de nouveau. Vérifiez donc encore vos journaux avant de déclarer l’incident clos.