La panne majeure de Cloudflare le 18 novembre

Détails: Écrit par : IT Pro; Catégorie : Blog; Publication : 19 Novembre 2025; Clics : 6204

Le 18 novembre 2025, une énorme tranche d'Internet est tombée.
Si vous avez ouvert ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase, ou d'innombrables petits sites, vous avez été accueilli avec une page d'erreur 5xx de marque Cloudflare – ou les sites ne seraient pas du tout chargés. Ce qui a d'abord regardé comme un autre grand moment d'Internet est cassé.Le moment s'est avéré être quelque chose de plus subtil et, d'une certaine manière, plus inquiétant: un bug auto-infligé au fond de Cloudflare.

Ci-dessous est une promenade détaillée de ce qui s'est passé hier dans Cloudflare panne (18 novembre 2025), pourquoi cela s'est produit, qui cela a affecté, et quelles leçons les équipes d'infrastructure devraient en retirer.

Que s'est-il passé hier ?

À Mardi 18 novembre 2025, vers la fin du matin UTC, Cloudflare a commencé à retourner de grands volumes de Erreurs du serveur HTTP 5xx pour le trafic qui a traversé son réseau. Pour les utilisateurs finaux, cela signifiait Erreur de serveur interne ou Erreur de portail pour essayer d'accéder à de nombreux sites Web et applications populaires.

Selon son propre blog post-incident, la panne:

Démarré impactant le trafic HTTP client à 11:28 UTC
A constaté des erreurs 5xx généralisées dans les services de base CDN et de sécurité
Des mesures d'atténuation importantes ont été prises 13 h 05-14 h 30 UTC
Volume d'erreur 5xx retourné au niveau de référence par 17:06 UTC Le blog Cloudflare

Cloudflare lui-même décrit comme sa pire panne depuis 2019, parce qu'il n'a pas seulement affecté une fonctionnalité ou un tableau de bord – il a perturbé la couche proxy de base qui relie la majorité du trafic client à travers son réseau. Le blog Cloudflare

La surveillance par des tiers a confirmé cela. Cisco Mille-oui a vu un panne mondiale affectant Cloudflare, avec des délais et 5xx erreurs sur des services comme X, OpenAI (ChatGPT) et Anthropic, tandis que les chemins de réseau eux-mêmes semblaient sains. C'est ce qui s'est passé. panne de service du moteur, pas un problème de niveau ISP ou de routage. Mille oui

Qui a été touché?

Parce que Cloudflare se trouve devant une grande partie de l'internet 20% des sites web compte sur Cloudflare pour la performance et la sécurité), le rayon d'explosion était énorme. AP Nouvelles+1

Parmi les services déclarés touchés :

ChatGPT / OpenAI
X (anciennement Twitter)
Canva, Shopify, Dropbox, Coinbase
Ligue des Légendes et autres plateformes de jeux
Divers transports en commun et sites gouvernementaux, y compris New Jersey Transit et les systèmes numériques SNCF AP Nouvelles+1

Trackers de panne comme Downdetector enregistré des milliers de rapports parallèles au sommet. Reuters a signalé environ 5 000 utilisateurs affectés pour X seul à un moment donné, avant que les nombres diminuent à mesure que les corrections sont déployées. Reuters

Du point de vue de l'utilisateur, cela s'est traduit par:

Sites non chargés
Flux de connexion suspendus ou défaillants (surtout lorsque Cloudflare Access ou Turnstile ont été impliqués)
API répondant de façon intermittente ou avec des erreurs 5xx
Tableau de bord et tableaux de bord

En d'autres termes: des parties énormes de l'Internet .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Comment Cloudflare fonctionne normalement (en termes simples)

Pour comprendre pourquoi cette panne était si grave, elle aide à connaître le chemin rugueux d'une requête via le réseau Cloudflare.

Cloudflare agit comme un CDN mandataire inversé et couche de sécurité:

Votre navigateur ou votre application se connecte à Cloudflare au lieu de directement au site d'origine.
Cloudflare termine TLS et HTTP à son bord.
Les demandes s'écoulent dans les cloudflares système proxy de base, appelé FL (=Frontline=) et sa nouvelle génération FL2.
Ce proxy de base :
- S'applique WAF (pare-feu de l'application Web) règles
- Cours Gestion du bot modèles
- Poignées Protection DDoS, cache, sortie vers l'origine
- Routes trafic vers d'autres produits internes comme Travailleurs, R2, Accès, etc. Le blog Cloudflare

En fonctionnement normal, cette architecture est très résistante: si un centre de données a un problème, le trafic est acheminé par d'autres; les changements de configuration sont déployés avec soin; les caractéristiques individuelles doivent échouer de manière confinée.

Hier, la panne était précisément mauvaise parce que l'échec était dans le chemin proxy commun lui-même, et il a été étroitement couplé avec un fichier de configuration qui est poussé dans le monde entier fréquemment et automatiquement.

La cause racine : un fichier de fonctionnalités de gestion bot disparu

L'explication officielle de Cloudflares indique un coupable clé :
un fichier de configuration des fonctionnalités utilisé par leur système de gestion de bot. Le blog Cloudflare

Voici la chaîne d'événements en langage clair:

Bot Management utilise un fichier de caractéristiques
- Le modèle bot-detection Cloudflares s'appuie sur un ensemble de caractéristiques – signaux sur chaque demande utilisée pour décider si elle est humaine ou un bot.
Ces fonctionnalités sont regroupées dans un fichier de configuration régénéré toutes les quelques minutes et déployé dans le monde entier, afin que Cloudflare puisse s'adapter rapidement aux nouveaux modèles d'attaque. Le blog Cloudflare
Un changement dans le comportement de la requête Clickhouse
- Le fichier de fonctionnalités est généré par des requêtes sur une base de données ClickHouse.
Cloudflare a changé 11:05 UTC améliorer la sécurité et les permissions pour les requêtes distribuées – permettant aux utilisateurs de voir les métadonnées non seulement à partir d'un default schéma mais aussi de sous-jacent r0 les tableaux. Le blog Cloudflare
La requête qui construit la liste des fonctionnalités n'a pas filtré par le nom de la base de données ; soudain elle a commencé à obtenir colonnes dupliquées des deux default et r0, efficacement doubler le nombre de lignes de fonctionnalités.
Le fichier de fonctionnalités a explosé dans la taille
- Le module de gestion du bot limite dure sur le nombre de fonctionnalités qu'il acceptera (réglage à 200, bien au-dessus de la ~60 normalement utilisée).
- Lorsque le fichier nouvellement généré a dépassé cette limite, le module a frappé le capuchon et paniqué, en raison d'une erreur non traitée dans le code Rust utilisé Result::unwrap() sur une valeur d'erreur. Le blog Cloudflare
Les services proxy de base ont commencé à renvoyer 5xx erreurs
- Comme la gestion du bot est intégrée dans le chemin proxy central, la panique est apparue comme Réponses HTTP 5xx pour tout trafic qui dépend de ce module.
- Sur la nouvelle FL2 moteur, les clients ont vu des erreurs 5xx explicites.
- Sur l'ancienne FL moteur, les scores de bot sont passés silencieusement à zéro, ce qui pourrait causer de faux positifs dans les règles de blocage de bot. Le blog Cloudflare
La partie vraiment méchante: le fichier a continué à basculer entre le bon et le mauvais
- Le cluster ClickHouse était en cours mise à jour progressive, et le fichier de fonctionnalités a été régénéré toutes les cinq minutes.
- Parfois, la requête s'exécutait sur des nœuds mis à jour (production d'un mauvais fichier), parfois sur des nœuds non mis à jour (production d'un bon fichier).
- Cela signifiait un certain temps, le réseau de CloudflareS oscillait entre le fonctionnement normal et l'échec puisque différentes versions du fichier étaient propagées. Le blog Cloudflare

Cette oscillation a rendu la situation extrêmement confuse à l'interne. Dans un premier temps, les équipes de Cloudflare Attaque massive DDoS parce que le modèle d'erreur ne ressemblait pas à un simple plantage logiciel. Même le Cloudflare page d'état, qui est hébergé en dehors de leur propre infrastructure, a montré brièvement des erreurs – une coïncidence qui a alimenté davantage la suspicion d'une attaque externe. Le blog Cloudflare+1

Ce n'est qu'une fois qu'ils se sont rendu compte que le facteur commun était le fichier de caractéristiques du bot.

Calendrier de l'incident

Sur la base des rapports postmortem et tiers de Cloudflare, nous pouvons établir une chronologie approximative pour le 18 novembre 2025 : Le blog Cloudflare+2Mille oui+2

11:05 UTC – Un changement de contrôle d'accès aux bases de données est déployé dans ClickHouse.
11 h 20-11 h 30 UTC – Les mauvaises versions du fichier de fonctionnalité de gestion de bot commencent à être générées et propagées.
11:28 UTC – Premier impact client : erreurs HTTP 5xx élevées observées sur le trafic client.
11 h 30-11 h 32 UTC – Les outils de surveillance externe et les tests automatisés commencent à détecter les défaillances intermittentes.
11:35 UTC – Cloudflare ouvre un appel interne d'incident; l'enquête commence.
~11:48 UTC – Cloudflare publie une mise à jour du statut confirmant un incident. Renvoyer
11 h 30-13 h 05 UTC – Les équipes se concentrent sur ce qui semble être dégradé comportement travailleurs KV et d'étudier plusieurs causes possibles (y compris les scénarios d'attaque).
13:05 UTC – Atténuation des clés : les travailleurs KV et Cloudflare Access sont déplacés pour contourner le proxy de base ; l'impact est réduit. Le blog Cloudflare
14 h 30 UTC – Cause racine identifiée; la génération et la propagation de fichiers de mauvaise fonctionnalité est arrêtée. Un fichier de configuration connu est inséré manuellement et le proxy de base est redémarré. La plupart du trafic de base revient à la normale. Le blog Cloudflare
14 h 40-15 h 30 UTC – Les problèmes de tableau de bord et de connexion s'attardent comme Turnstile et l'arriéré des tentatives d'authentification créent des pics de charge secondaires. Le blog Cloudflare
17:06 UTC – Les taux d'erreur retournent au niveau de base; Cloudflare déclare les systèmes complètement normaux. Le blog Cloudflare

D'un point de vue de l'utilisateur, la panne s'est ressentie le plus mal tard le matin au début de l'après-midi UTC, bien que les fenêtres d'impact exacts varient selon la région et par laquelle Cloudflare produit chaque service dépend.

Pourquoi cette panne est si importante

Risque de centralisation

Cloudflare fait partie d'un petit ensemble de les fournisseurs centraux d'infrastructures Internet;, aux côtés des grandes plateformes cloud (AWS, Azure, GCP) et d'autres grands CDN. Lorsque l'un de ces joueurs échoue, l'impact est large et souvent non évident.

Cette panne :

N'est pas venu d'un problème de routage BGP ou d'une coupure de câble ISP.
Ne vient pas d'une attaque malveillante (malgré les soupçons initiaux).
Venue de une configuration unique et limite le bug dans une composante interne.

C'est important car il montre comment systèmes complexes et étroitement couplés peut échouer catastrophiquement même sans ingérence extérieure. Lorsque de nombreuses organisations s'appuient sur le même fournisseur, celui-ci devient un fournisseur de fait élément d'importance systémique de l'internet.

Les dépendances du logiciel font aussi mal

Certains des services affectés n'étaient pas simplement en utilisant Cloudflare comme un CDN stupide. Ils étaient:

Utilisation Accès Cloudflare pour l'authentification et l'accès de confiance zéro.
Utilisation Travailleurs KV dans le cadre des plans de contrôle interne.
S'appuyant sur Tourniquet pour les connexions bot-résistantes. Le blog Cloudflare+1

Lorsque ces produits ont échoué, ce n'était pas juste le contenu du site Web qui a baissé – logins, fonctions d'administration et API internes aussi. Cela rend la récupération plus complexe : votre page d'état, l'outil d'incident, ou l'interface utilisateur d'administration peuvent également compter sur le fournisseur même qui vient d'échouer.

Ce que dit Cloudflare va changer

Le blog Cloudflares décrit plusieurs mesures d'assainissement que l'entreprise prend déjà pour réduire le risque d'une récurrence similaire : Le blog Cloudflare

L'ingestion de fichiers de configuration générés automatiquement par Harden
Traiter les configs générés en interne avec le même scepticisme et la même validation que les entrées fournies par l'utilisateur, y compris un schéma strict et une vérification de la taille avant le déploiement.
Plus d'interrupteurs de destruction globaux
Rendre plus facile la désactivation rapide des modules internes problématiques (comme Bot Management) à travers le réseau, donc ils échouent ouvert au lieu de paniquer tout le chemin proxy.
Protéger les ressources du système des tempêtes d'erreurs
Assurez-vous que les sauvegardes de base, les métadonnées de débogage et l'outil d'observation ne peuvent pas surcharger le processeur et la mémoire lorsque les erreurs commencent à pic.
Examiner les modes de défaillance des modules proxy de base
Vérifier systématiquement comment chaque module interne se comporte sous une entrée ou une configuration inattendue, et assurer une dégradation gracieuse au lieu d'une défaillance globale.
Affiner les déploiements et l'isolement
Bien qu'il ne soit pas expliqué en détail, l'incident suggère que Cloudflare va probablement segmenter davantage comment les nouvelles configurations et les comportements DB se propagent, afin de réduire le risque qu'un seul mauvais changement affecte la flotte entière.

Ils ont également qualifié l'incident d'un échec absolu de leurs attentes de résilience, l'appelant « inacceptable » et reconnaissant explicitement la douleur qu'il causait aux clients et aux internautes ordinaires. Le blog Cloudflare

Enseignements pour les équipes d'infrastructure et de SRE

Même si vous n'êtes pas en train d'exécuter quelque chose d'aussi énorme que Cloudflare, il ya quelques leçons très pratiques de conception et de fonctionnement dans cette panne:

Traiter la configuration interne comme une entrée non fiable

Il est facile de supposer que la configuration générée par notre propre configuration est toujours correcte. Hier montre pourquoi cela est dangereux:

Toujours valider taille, forme et limites des fichiers de configuration avant de les appliquer.
Envisager application canaire de config à un petit sous-ensemble de trafic ou de nœuds d'abord, avec retour automatique sur anomalies.
Restez stricts Limites supérieures et les disjoncteurs autour des comptes de fonctionnalités, la préallocation de mémoire, et l'utilisation de CPU.

Design pour l'échec partiel gracieux

Un bug dans le module de gestion du bot ne devrait pas pouvoir paniquer tout le chemin proxy:

Par défaut à non ouvert vs fermé dans certaines couches de sécurité lorsque l'alternative est une panne complète.
Construire clair, testé les interrupteurs de destruction pour les caractéristiques non essentielles.
Veiller à ce que les sous-systèmes critiques (auth, page d'état, outillage incident) puissent fonctionner en mode dégradé ou par d'autres voies.

Observer droite signaux

L'oscillation entre la configuration de bon et la configuration de mauvais toutes les cinq minutes a fait que le signal ressemblait à un trafic d'attaque ou à un comportement externe bruyant:

Assurez-vous que vous avez par version ou par session corrélation dans votre pipeline d'observation.
Construire des tableaux de bord qui rendent les changements de configuration visuellement évidents sur les graphiques d'erreur.
Inclure forte Essais synthétiques d'un point de vue externe, de sorte que vous pouvez rapidement distinguer la défaillance interne des problèmes réseau/chemin.

Ne mettez pas tous vos œufs dans un panier infra

Pour les organisations utilisant Cloudflare:

Envisager multi-CDN configurations pour des propriétés vraiment critiques pour la mission.
Évitez de faire votre page d'état entièrement dépendant du même fournisseur que votre pile primaire (Cloudflare fait cela, mais il y a eu un problème de coïncidence avec leur hôte de page d'état hier qui a confondu les choses plus loin). Le blog Cloudflare+1
Réfléchissez deux fois avant d'attacher étroitement votre authentification, Plans de contrôle des APIet livraison frontale pour le même vendeur sans chemins de repli.

Aperçu général

Au cours des derniers mois seulement, nous avons vu des pannes importantes à Microsoft Azure, Services Web Amazon, et maintenant Cloudflare, qui tous ont temporairement assommé de gros morceaux de services de consommation et d'entreprise hors ligne. AP Nouvelles+2Le poste de Washington+2

Le modèle est clair :

Internet est de plus en plus dépendant d'une poignée de fournisseurs d'infrastructures géants.
Les pannes sont souvent auto-infligé, provenant de changements internes complexes plutôt que d'attaques externes.
Même les fournisseurs ayant des pratiques SRE de classe mondiale peuvent encore être trippés par interactions inattendues entre la configuration, le comportement de la base de données et les limites codées en dur.

Hier, Cloudflare incident est un rappel terrible que Le nuage n'est pas magique. Au fond, il est encore un logiciel écrit par les humains, soumis aux mêmes classes de bugs que toute autre application — juste avec des ordres de grandeur plus de gens en fonction.

Pour les utilisateurs, l'incident sera le plus souvent rappelé comme le matin où X et ChatGPT ne seraient pas charger.
Pour les ingénieurs, il sera probablement étudié comme exemple de manuel des bogues de configuration subtiles dans un système distribué central peuvent se transformer en un événement Internet global.