Panne du réseau mondial de Cloudflare

• Une dégradation des performances des services internes a touché le réseau mondial de Cloudflare, affectant par intermittence plusieurs services
• Des services majeurs comme Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers ont subi une panne temporaire
• L’équipe d’ingénierie a identifié le problème et lancé les correctifs, tandis que les services WARP et Access ont été rétablis en premier
• Ensuite, le taux d’erreur et la latence sont progressivement revenus à des niveaux normaux à l’échelle mondiale, et le service Dashboard a également été restauré
• Tous les services fonctionnent désormais normalement, et l’incident est entièrement résolu

---

Aperçu de l’incident

• Cloudflare a subi une dégradation des services internes (Internal Service Degradation), provoquant des interruptions intermittentes de certains services
  • Les services affectés incluaient notamment Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers
  • L’entreprise a immédiatement lancé les travaux de rétablissement et a continué à publier des mises à jour sur l’avancement de la résolution

Identification du problème et réponse initiale

• Cloudflare a confirmé une dégradation des services internes pendant la phase Investigating
  • Certains clients ont rencontré des erreurs intermittentes et de la latence
  • L’équipe d’ingénierie a mené en parallèle l’analyse de la cause et les opérations de rétablissement
• L’entreprise a ensuite identifié la cause du problème (Identified) et commencé à déployer les correctifs
  • Pendant cette phase, l’accès WARP dans la région de Londres a été temporairement désactivé, et les utilisateurs de cette zone ont subi des échecs de connexion à Internet

Progression du rétablissement des services

• Après le déploiement des correctifs, les services Access et WARP ont été rétablis en premier, ramenant le taux d’erreur à son niveau d’avant l’incident
  • L’accès WARP dans la région de Londres a été réactivé
• Les travaux de restauration des services pour les clients d’Application Services ont ensuite continué
  • Des modifications ont été déployées pour restaurer le service Dashboard
  • Certains clients rencontraient encore des problèmes de connexion ou d’utilisation du Dashboard, mais ceux-ci ont été résolus par des correctifs supplémentaires

Stabilisation de l’ensemble du réseau

• À l’échelle mondiale, le taux d’erreur et la latence ont progressivement diminué jusqu’à revenir à des niveaux normaux
  • Le calcul des scores de Bot Management (bot scores) a été temporairement affecté, puis normalisé au cours du rétablissement
  • L’équipe d’ingénierie a éliminé les erreurs restantes et accéléré le rétablissement de l’ensemble du réseau
• Par la suite, tous les services ont recommencé à fonctionner normalement, avec un taux d’erreur et une latence entièrement revenus à la normale

Clôture de l’incident et suites

• Cloudflare a confirmé que tous les services fonctionnent normalement et a clos l’incident
  • Il n’y a actuellement aucun changement de configuration supplémentaire, et la plateforme fait l’objet d’une surveillance étroite
  • Une enquête post-incident (post-incident investigation) sur la cause de la panne est en cours, et ses résultats seront publiés ultérieurement
• Cette panne est enregistrée comme un incident ayant affecté l’ensemble du réseau mondial

[GN⁺]

Avis Hacker News

• Quelqu’un a partagé une commande permettant de désactiver le proxy CF si l’on dispose d’un token API Cloudflare
  Avec curl, il suffit de récupérer l’ID de zone et les enregistrements DNS, puis d’envoyer une requête PATCH avec "proxied": false
  Attention toutefois au risque de perte de certificat SSL, de dégradation de la sécurité/des performances et d’exposition de l’IP du backend

  • Si vous n’avez qu’une ancienne Global API Key, il faut utiliser les en-têtes X-Auth-Email et X-Auth-Key
    Et si vous avez configuré votre système pour n’autoriser que le trafic Cloudflare, il faut aussi désactiver temporairement cette règle
  • Je me suis dit que j’utiliserais cette méthode la prochaine fois, mais comme je n’avais pas créé de token API à l’avance, je n’ai eu d’autre choix que d’attendre
    Heureusement, tout est revenu en ligne maintenant
  • Je l’ai fait via le provider Terraform, mais cette méthode est utile pour ceux qui n’arrivent pas à accéder au dashboard
  • Bon conseil. À noter qu’avec curl, les requêtes GET sont le comportement par défaut, donc -X GET est inutile
    Si on utilise l’option -d, cela devient automatiquement un POST, et pour PATCH, -X PATCH est bien ce qu’il faut
  • En activant Cloudflare WARP, certains sites recommencent à fonctionner. 1.1.1.1 devrait avoir un effet similaire
    Cela dit, même après le tunneling, certains sites restent partiellement hors service

• D’après le CTO de Cloudflare, un bug latent dans le système de blocage des bots s’est emballé après un changement de configuration, provoquant une panne à l’échelle du réseau
  Il a expliqué dans la source qu’il ne s’agissait pas d’une attaque, mais d’un problème interne

  • Il est étonnant que de grandes entreprises ne déploient toujours pas les changements de configuration de façon progressive
    Le code comme la configuration ne sont que des données, et on voit sans cesse se répéter le même schéma de déploiements mondiaux d’un coup qui provoquent des pannes majeures
  • J’aimerais que cette information essentielle soit plus haut dans les commentaires. C’était difficile à trouver au milieu des spéculations sur une cyberattaque
  • Un simple changement de configuration a fait baisser l’action de CF de 4 %. Je me demande quel est l’impact économique de ce type de panne sur l’ensemble du secteur

• Un collègue a débarqué en courant en disant qu’il venait de modifier une configuration Cloudflare juste avant que le site ne tombe, et qu’il avait eu très peur d’en être la cause
  Il a été soulagé en voyant ce post

  • Blague : « C’est encore pire, en fait c’est toi qui as mis tout Cloudflare à terre »
  • Mais qui sait, ce n’est peut-être pas totalement impossible ? Vu la grande panne de Fastly, le doute subsiste
  • Je me demande s’il existe un mot pour cette étrange sensation de soulagement qu’on ressent en apprenant que ce n’est pas quelqu’un qui a fait une erreur
  • Peut-être que ce collègue travaille chez Cloudflare, après tout
  • Moi aussi, j’ai reçu des dizaines de messages de clients disant que leurs sites ne fonctionnaient plus, et comme j’avais changé une configuration hier, j’ai eu une belle suée
    Voir le message « Cloudflare down » m’a vraiment soulagé

• Vérification faite depuis les Pays-Bas, presque tous les services étaient hors ligne
  Le dashboard Cloudflare était inaccessible, tout comme celui de Betterstack
  Ironiquement, la page de statut fonctionnait encore, ce qui rendait impossible toute communication aux clients

  • J’ai vécu la même chose. Si HN tenait encore, c’est parce qu’ils n’utilisent pas Cloudflare
    J’ai écrit ce billet de blog sur l’idée de ne pas mettre un site derrière Cloudflare si ce n’est pas nécessaire
  • Chaque année, on se rappelle qu’il est risqué de trop dépendre d’AWS ou de Cloudflare, mais les alternatives ne sont pas simples
    Malgré tout, lors de ce genre de panne massive, les clients se montrent souvent plus compréhensifs qu’on ne l’imagine
  • Le dashboard Cloudflare n’était pas complètement mort : en insistant, on pouvait finir par désactiver le proxy
    Cela m’a pris quelques minutes, mais j’ai détaché hcker.news de CF
  • En voyant ce genre de situation, je me dis qu’il y aurait peut-être une opportunité business à créer un service qui héberge des pages de statut sur un VPS local
  • Sur mon side project Total Real Returns,
    j’ai mis en bas de page un widget de disponibilité en temps réel relié à une page de statut externe
    Voir le SVG de statut et la page de statut externe

• Quand Cloudflare ou AWS tombent, il y a une certaine satisfaction à voir que mes services self-hosted continuent à fonctionner parfaitement
  Leur disponibilité à 99,999 % est peut-être belle sur le papier, mais à cet instant précis, c’est moi qui suis le plus fiable

  • Même mon petit site personnel bricolé est resté en ligne pendant les pannes d’AWS, d’Azure et de Cloudflare
    Je devrais peut-être lui ajouter un tracker d’uptime
  • Mon site self-hosted, lui, est tombé justement à cause du proxy Cloudflare. Assez ironique
  • Dans les entreprises traditionnelles, les systèmes Oracle ou SAP continuent souvent de tourner, alors que les nouveaux services cloud, eux, tombent
    Les jeunes entreprises SaaS devraient en tirer une leçon
  • Beaucoup demandent comment gérer le DNS. J’héberge aussi sur un Raspberry Pi, mais je venais justement de migrer mon DNS vers Cloudflare
    Le fait que mon petit site tombe est à la fois ridicule et étrangement satisfaisant

• Ces derniers temps, on a l’impression que les grandes pannes d’infrastructure se multiplient. AWS comme Cloudflare sont très loin de leurs SLA

  • Cela coïncide avec le moment où les grandes entreprises ont procédé à des licenciements massifs en promettant de remplacer par de l’IA
  • Ce genre de panne rappelle que le nombre de “9” dans les SLA ne veut pas dire grand-chose
    Ce ne sont pas des mesures de disponibilité réelle, mais des chiffres définis arbitrairement par les entreprises
  • Certains appellent ça la « vibe code theory » : une théorie semi-humoristique selon laquelle plus on code à l’instinct, plus les bugs et les pannes augmentent
  • Une autre analyse pointe la culture du déploiement dans l’urgence, entre gel des mises en production en fin d’année et pression sur les objectifs du T4
  • Ou alors, selon une lecture plus complotiste, il pourrait s’agir d’une cyberattaque menée à l’échelle d’un État

• Le problème de centralisation est grave : quand Cloudflare ou AWS s’arrêtent, c’est la moitié du web qui s’arrête avec eux

  • Et les utilisateurs ne semblent pas trop s’en soucier. Comme l’idée générale est que « c’est Internet qui est en panne », les services individuels peuvent facilement se défausser de leur responsabilité
    C’est aussi pour cela que cette structure ne change pas
  • La défense DDoS repose sur des économies d’échelle. Plus on a de clients, plus on dispose de bande passante, et meilleure est la protection
    Il est difficile pour un petit CDN de rivaliser, ce qui finit par créer une forme de monopole naturel
    La stratégie de Cloudflare avec son offre gratuite visait précisément cet effet de réseau
  • Plus encore qu’un point unique de défaillance, ce qui inquiète, c’est que cette centralisation pourrait déformer l’avenir des standards du web et de l’auto-hébergement
    Elle pourrait aussi devenir une cible privilégiée pour la censure gouvernementale
  • Let’s Encrypt représente aussi un risque potentiel.
    Les deux tiers du web en dépendent, la durée de vie des certificats raccourcit, et en cas de piratage ou de panne, c’est l’ensemble du web qui pourrait être paralysé
    L’organisation est aujourd’hui bienveillante, mais il ne faut pas oublier que Google aussi l’a longtemps été dans sa perception publique
  • Depuis la vague AWS, les développeurs en sont venus à ne compter que sur le cloud plutôt que sur des serveurs dédiés
    Les sauvegardes au niveau logiciel sont nombreuses, mais la culture du multi-hébergement au niveau infrastructure a largement disparu

• Ironiquement, DownDetector utilisait aussi Cloudflare Turnstile, et s’est donc retrouvé en panne lui aussi

  • Les signalements de panne AWS ont également explosé, mais il s’agit probablement en grande partie de faux positifs
  • J’ai vu ça moi aussi

• Le message visuel d’excuse de Cloudflare — « Your browser: Working / Host: Working / Cloudflare: Error » — était marquant

  • C’était la première fois que je voyais cet écran. Cela dit, dans mon cas, le « Host » était Cloudflare Pages, donc le sens était un peu ambigu
  • Le fait qu’en cliquant sur « Cloudflare », on soit encore renvoyé vers une explication disant que le problème vient du serveur client est assez drôle
  • J’ai apprécié l’honnêteté du message, mais les utilisateurs, eux, ont surtout réagi par des « réparez le Wi‑Fi »
  • Au moins, on comprenait clairement la situation et on pouvait réagir. Si nécessaire, désactiver le proxy permettait de limiter l’impact sur le service
  • Moi aussi, j’ai passé une heure à éplucher les logs avant de comprendre que le problème ne venait pas de mon serveur

• Les sites qui utilisent Cloudflare Challenge (« I’m not a robot ») se sont eux aussi arrêtés avec des erreurs HTTP 500
  Un message demandait de « débloquer challenges.cloudflare.com »

  • En ce moment, le niveau de gestion des erreurs est vraiment médiocre. Les entreprises cherchent à se déresponsabiliser en rejetant la faute sur l’utilisateur,
    ou n’affichent qu’un écran de chargement infini. En réalité, le backend renvoie souvent une erreur claire que le frontend masque
    J’ai même vu récemment un cas où une erreur disant que le mot de passe était trop long était affichée comme « e-mail déjà utilisé »
  • Avec cette panne, la recherche IA de chat.bing.com (GPT5) s’est aussi arrêtée
    Situation ironique où l’on doit prouver à une IA qu’on est humain
  • Certains sites (comme pinkbike) affichaient le message « you have been blocked »
  • Donc, non seulement les robots, mais aussi les vraies personnes se retrouvent bloqués /s
  • Le frontend semble croire à tort que l’utilisateur a bloqué le domaine via son DNS ou une extension
    Le déni sarcastique façon /s sur l’idée que le Captcha Cloudflare puisse tomber est assez drôle