Cloudflares Hauptausfall am 18. November - Eine Zusammenfassung

Am 18. November 2025 fiel ein riesiger Teil des Internets um.
Wenn Sie ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase oder unzählige kleinere Websites geöffnet haben, wurden Sie mit einer 5xx-Fehlerseite der Cloudflare-Marke begrüßt - oder die Websites würden überhaupt nicht geladen. Was zuerst wie ein weiterer großer "das Internet ist kaputt" -Moment aussah, erwies sich als etwas Subtileres und in gewisser Weise besorgniserregender: ein selbstverschuldeter Bug tief in Cloudflares eigener Infrastruktur.

Unten ist eine detaillierte Walkthrough von Was passierte beim gestrigen Cloudflare-Ausfall (18. November 2025), warum es passiert ist, wen es betroffen hat und welche Lehren Infrastrukturteams daraus ziehen sollten.

Was ist eigentlich gestern passiert?

am Dienstag, 18. November 2025Um den späten Morgen UTC herum begann Cloudflare, große Mengen von HTTP 5xx Server Fehler für den Verkehr, der durch sein Netzwerk ging. Für Endbenutzer bedeutete dies "Internal Server Error" oder "Gateway Error" -Seiten, wenn Sie versuchen, auf viele beliebte Websites und Apps zuzugreifen.

Laut Cloudflares eigenem Post-Incident-Blog ist der Ausfall:

• Beeinflusste den HTTP-Datenverkehr des Kunden bei 11:28 UTC

• Säge weit verbreitete 5xx-Fehler über Kern-CDN und Sicherheitsdienste

• Hatte große Minderungsschritte 13:05-14:30 UTC

• 5xx Fehlervolumen an Baseline zurückgegeben 17:06 UTC Der Cloudflare Blog

Cloudflare selbst beschrieb es als Der schlimmste Ausfall seit 2019, weil es nicht nur ein Feature oder Dashboard beeinflusst hat - es hat die zentrale Proxy-Schicht gestört, die den Großteil des Kundenverkehrs durch sein Netzwerk leitet. Der Cloudflare Blog

Die Überwachung durch Dritte unterstützte dies. Cisco ThousandEyes sah eine weltweiter Ausfall Cloudflare mit Timeouts und 5xx-Fehlern bei Diensten wie X, OpenAI (ChatGPT) und Anthropic, während die Netzwerkpfade selbst gesund aussahen. Das deutete stark auf eine Backend-Service fehlgeschlagen, kein ISP-Level- oder Routing-Problem. TausendAugen

Wer war betroffen?

Weil Cloudflare vor einem riesigen Teil des Internets sitzt (um) 20% der Webseiten Verlassen Sie sich auf Cloudflare für Leistung und Sicherheit, der Explosionsradius war enorm. AP News+1

Unter den als betroffen gemeldeten Diensten:

• ChatGPT / OpenAI

• X (früher Twitter)

• Canva, Shopify, Dropbox, Coinbase

• Liga der Legenden und andere Spieleplattformen

• Verschiedene Öffentliche Verkehrsmittel und staatliche Einrichtungen, einschließlich New Jersey Transit und Frankreichs SNCF Eisenbahn digitale Systeme AP News+1

Outage Tracker wie Downdetector aufgezeichnet Tausende von Concurrent Issue Reports auf dem Höhepunkt. Reuters berichtete über 5.000 betroffene Benutzer für X allein an einem Punkt, bevor die Zählungen als Fixes ausgerollt zurückgingen. Reuters

Aus der Perspektive eines Benutzers manifestiert sich dies als:

• Sites werden überhaupt nicht geladen

• Login-Flows hängen oder scheitern (insbesondere wenn Cloudflare Access oder Turnstile beteiligt waren)

• APIs reagieren intermittierend oder mit 5xx Fehlern

• Dashboards und Admin Panels Timing Out

Mit anderen Worten: Große Teile des Internets „fühlten sich an, obwohl sich die Ursache in den internen Systemen eines einzelnen Anbieters konzentrierte.

Wie Cloudflare normalerweise funktioniert (in einfachen Worten)

Um zu verstehen, warum dieser Ausfall so schwerwiegend war, hilft es, den groben Weg einer Anfrage über das Netzwerk von Cloudflare zu kennen.

Cloudflare agiert als Reverse Proxy CDN und Sicherheitsschicht:

1. Ihr Browser oder Ihre App verbindet sich mit Cloudflare anstelle direkt mit der Ursprungsseite.

2. Cloudflare beendet TLS und HTTP an seinem Rand.

3. Anfragen fließen in Cloudflares Kern-Proxysystem, genannt FL („Frontline) und seine neue Generation FL2.

4. Dieser zentrale Proxy:

   • Gilt für WAF (Web Application Firewall) Vorschriften

   • Läufe Bot Management Modelle

   • Griffe DDoS-Schutz, Caching, Egress to Origin

   • Routen Verkehr zu anderen internen Produkten wie Arbeitnehmer, R2, Zugangusw. Der Cloudflare Blog

Im Normalbetrieb ist diese Architektur sehr belastbar: Wenn ein Rechenzentrum ein Problem hat, wird der Datenverkehr durch andere geleitet; Konfigurationsänderungen werden sorgfältig ausgerollt; einzelne Funktionen sollten auf begrenzte Weise ausfallen.

Der gestrige Ausfall war genau schlecht, weil der Fehler war innerhalb des gemeinsamen Proxy-Pfads selbst, und es wurde eng mit einer Konfigurationsdatei gekoppelt, die weltweit geschoben wird häufig und automatisch.

Die Ursache: Eine Bot-Management-Feature-Datei ist tot

Die offizielle Erklärung von Cloudflare weist auf einen Hauptschuldigen hin:
eine Feature-Konfigurationsdatei, die von ihrem Bot Management System verwendet wird. Der Cloudflare Blog

Hier ist die Kette der Ereignisse in einfacher Sprache:

1. Bot Management verwendet eine „Feature-Datei

   • Cloudflares Bot-Erkennungsmodell basiert auf einer Reihe von "Features" - Signale über jede Anfrage, die verwendet werden, um zu entscheiden, ob es sich um einen Menschen oder einen Bot handelt.

2. Diese Funktionen werden in einer Konfigurationsdatei gebündelt, die regeneriert wird alle paar Minuten und weltweit eingeführt, sodass sich Cloudflare schnell an neue Angriffsmuster anpassen kann. Der Cloudflare Blog

3. Eine Änderung des ClickHouse Abfrageverhaltens

   • Die Feature-Datei wird durch Abfragen gegen eine ClickHouse-Datenbank generiert.

4. Cloudflare hat eine Veränderung vorgenommen 11:05 UTC um die Sicherheit und Berechtigungen für verteilte Abfragen zu verbessern - so können Benutzer Metadaten nicht nur von einem default Schema, aber auch vom zugrunde liegenden r0 Tabellen. Der Cloudflare Blog

5. Die Abfrage, die die Feature-Liste erstellt, wurde nicht nach Datenbanknamen gefiltert; plötzlich begann sie Doppelspalten von beiden default und r0, effektiv Verdoppelung der Anzahl der Feature-Zeilen.

6. Die Feature-Datei explodiert in der Größe

   • Das Bot Management Modul hat eine Harte Grenze wie viele Funktionen akzeptiert werden (auf 200 eingestellt, weit über den ~ 60, die normalerweise verwendet werden).

   • Wenn die neu generierte Datei diesen Grenzwert überschritten hat, hat das Modul das Cap und panisch, aufgrund eines nicht behandelten Fehlers im Rust-Code, der verwendet wurde Result::unwrap() auf einen Fehlerwert. Der Cloudflare Blog

7. Core-Proxy-Dienste geben 5xx-Fehler zurück

   • Da Bot Management in den Kern-Proxypfad integriert ist, tauchte die Panik als HTTP 5xx Antworten für jeden Traffic, der von diesem Modul abhängt.

   • Auf dem neuen FL2 Motor, kunden sahen explizite 5xx fehler.

   • Über die Älteren FL Engine, Bot-Scores gingen lautlos auf Null, was zu falschen Positiven in Bot-Blocking-Regeln führen könnte. Der Cloudflare Blog

8. Der wirklich böse Teil: Die Datei wechselte ständig zwischen "gut" und "schlecht"

   • Der ClickHouse-Cluster wurde schrittweise Aktualisierung, und die Feature-Datei wurde alle fünf Minuten regeneriert.

   • Manchmal lief die Abfrage auf aktualisierten Knoten (Erzeugen einer schlechten Datei), manchmal auf nicht aktualisierten Knoten (Erzeugen einer guten Datei).

   • Das bedeutete für eine Weile, dass das Netzwerk von Cloudflare zwischen normalem Betrieb und Ausfall schwankte, da verschiedene Versionen der Datei propagiert wurden. Der Cloudflare Blog

Diese Oszillation machte die Situation intern extrem verwirrend. Zunächst vermuteten die Teams von Cloudflare eine massiver DDoS-Angriff weil das Fehlermuster nicht wie ein einfacher Softwareabsturz aussah. Sogar die Cloudflare Statusseite, die außerhalb der eigenen Infrastruktur gehostet wird, zeigte kurzzeitig Fehler - ein Zufall, der den Verdacht eines externen Angriffs weiter anheizte. Der Cloudflare Blog+1

Erst als sie erkannten, dass der gemeinsame Faktor die Bot-Feature-Datei war, wurde das Bild klar.

Zeitleiste des Vorfalls

Basierend auf den Postmortem- und Drittberichten von Cloudflare können wir einen groben Zeitplan für den 18. November 2025 zusammenstellen: Der Cloudflare Blog+2TausendAugen+2

• 11:05 UTC Eine Änderung der Datenbankzugriffskontrolle wird in ClickHouse bereitgestellt.

• 11:20–11:30 UTC - Schlechte Versionen der Bot Management-Funktionsdatei werden generiert und verbreitet.

• 11:28 UTC Erste Kundenauswirkungen: Erhöhte HTTP 5xx-Fehler im Kundenverkehr.

• 11:30–11:32 UTC Externe Monitoring-Tools und automatisierte Tests beginnen, intermittierende Fehler zu erkennen.

• 11:35 UTC Cloudflare öffnet einen internen Incident Call; die Untersuchung beginnt.

• 11:48 UTC Cloudflare veröffentlicht ein Statusupdate, das einen Vorfall bestätigt. Wiedergabe

• 11:30-13:05 UTC - Teams konzentrieren sich auf das scheinbar degradierte Verhalten von Workers KV und untersuchen mehrere mögliche Ursachen (einschließlich Angriffsszenarien).

• 13:05 UTC - Key Minderung: Worker KV und Cloudflare Access werden verschoben, um den Core-Proxy zu umgehen; die Auswirkungen werden reduziert. Der Cloudflare Blog

• 14:30 UTC - Ursache identifiziert; Erzeugung und Verbreitung von schlechten Feature-Dateien wird gestoppt. Eine bekannte gute Konfigurationsdatei wird manuell eingefügt und der Core-Proxy neu gestartet. Der meiste Kernverkehr kehrt zum Normalzustand zurück. Der Cloudflare Blog

• 14:40-15:30 UTC - Dashboard- und Anmeldeprobleme bleiben bestehen, da Turnstile und Backlog von Authentifizierungsversuchen sekundäre Lastspitzen erzeugen. Der Cloudflare Blog

• 17:06 UTC – Fehlerraten kehren zur Baseline zurück; Cloudflare erklärt Systeme als völlig normal. Der Cloudflare Blog

Aus Sicht eines Benutzers fühlte sich der Ausfall am schlimmsten an am späten Morgen bis zum frühen Nachmittag UTC, obwohl die genauen Aufprallfenster je nach Region variierten und von welchen Cloudflare-Produkten jeder Dienst abhing.

Warum dieser Ausfall so wichtig ist

Zentralisierungsrisiko

Cloudflare ist Teil einer kleinen Gruppe von Anbieter zentraler InternetinfrastrukturenNeben den großen Cloud-Plattformen (AWS, Azure, GCP) und anderen großen CDNs. Wenn einer dieser Spieler scheitert, ist die Wirkung breit und oft nicht offensichtlich.

Dieser Ausfall:

• Kam nicht von einem bgp-routing-fehler oder einem isp-kabelschnitt.

• Kam nicht von einem böswilligen Angriff (trotz anfänglicher Verdachtsmomente).

• Kam aus Eine einzige Konfiguration und Limits Bug in einer internen Komponente.

Das ist wichtig, weil es zeigt, wie Komplexe, eng gekoppelte Systeme kann auch ohne äußere Einmischung katastrophal ausfallen. Wenn viele Organisationen auf dem gleichen Anbieter aufbauen, wird dieser Anbieter zu einem de-facto Systemisch wichtiger Teil des Internets.

"Soft" Abhängigkeiten schmerzen auch

Einige der betroffenen Dienste nutzten Cloudflare nicht nur als dummes CDN. Sie waren:

• Verwendung Cloudflare Zugriff für Authentifizierung und Zero-Trust-Zugriff.

• Verwendung Arbeitnehmer KV als Teil interner Steuerungsebenen.

• Verlassen auf Drehkreuz für bot-resistente Logins. Der Cloudflare Blog+1

Als diese Produkte versagten, waren es nicht nur Website-Inhalte, die untergingen - Logins, Administratorfunktionen und interne APIs Auch pleite. Das macht die Wiederherstellung komplexer: Ihre Statusseite, Incident Tooling oder Admin-Benutzeroberfläche könnte sich auch auf den Anbieter verlassen, der gerade fehlgeschlagen ist.

Was Cloudflare sagt, wird sich ändern

Cloudflares Blog skizziert mehrere Sanierungsschritte, die das Unternehmen bereits unternimmt, um das Risiko einer Wiederholung von etwas Ähnlichem zu reduzieren: Der Cloudflare Blog

1. Harden Ingestion von automatisch generierten Konfigurationsdateien
   Behandeln Sie intern generierte Konfigurationen mit der gleichen Skepsis und Validierung wie von Benutzern bereitgestellte Eingaben, einschließlich einer strengen Schema- und Größenüberprüfung vor dem Rollout.

2. Mehr globale Kill Switches
   Machen Sie es einfacher, problematische interne Module (wie Bot Management) im gesamten Netzwerk schnell zu deaktivieren, so dass sie fehlschlagen offen anstatt den gesamten Proxy-Pfad in Panik zu versetzen.

3. Schützen Sie Systemressourcen vor Fehlerstürmen
   Stellen Sie sicher, dass Core-Dumps, Debug-Metadaten und Observability-Tools CPU und Speicher nicht überfordern können, wenn Fehler zu hoch werden.

4. Überprüfen Sie Fehlermodi in allen Core-Proxy-Modulen
   Prüfen Sie systematisch, wie sich jedes interne Modul unter unerwarteten Eingaben oder Konfigurationen verhält, und sorgen Sie für eine anmutige Verschlechterung anstelle eines globalen Versagens.

5. Verfeinern Rollouts und Isolation
   Obwohl der Vorfall nicht im Detail beschrieben wird, deutet der Vorfall darauf hin, dass Cloudflare wahrscheinlich weiter segmentieren wird, wie sich neue Konfigurationen und DB-Verhalten ausbreiten, um die Wahrscheinlichkeit zu verringern, dass eine einzige schlechte Änderung die gesamte Flotte betrifft.

Sie bezeichneten den Vorfall auch als absoluten Misserfolg ihrer Resilienzerwartungen, nannten ihn "inakzeptabel" und erkannten ausdrücklich den Schmerz an, den er sowohl Kunden als auch normalen Internetnutzern verursachte. Der Cloudflare Blog

Unterricht für Infrastruktur & SRE Teams

Auch wenn Sie nichts so Großes wie Cloudflare ausführen, gibt es einige sehr praktische Design- und Betriebslektionen in diesem Ausfall:

Behandeln Sie interne Konfigurationen wie nicht vertrauenswürdige Eingaben

Es ist leicht anzunehmen, dass "unsere eigene" generierte Konfiguration immer korrekt ist. Gestern zeigt, warum das gefährlich ist:

• Immer validieren Größe, Form und Grenzen Konfigurationsdateien vor deren Anwendung.

• Berücksichtigung Kanarische Applikation von Config zu einer kleinen Teilmenge von Traffic oder Knoten zuerst, mit automatisiertem Rollback bei Anomalien.

• Streng halten Obergrenzen und Leistungsschalter um Feature Counts, Memory Preallocation und CPU-Auslastung.

Design für anmutigen Teilfehler

Ein Fehler im Bot Management-Modul sollte nicht in der Lage sein Panik im gesamten Proxy-Pfad:

• Standardmäßig bis Fail-Open vs. Fail-Closed in einigen Sicherheitsschichten, wenn die Alternative ein vollständiger Ausfall ist.

• Bauen Sie klar, getestet Killerschalter Nicht-Kern-Features.

• Stellen Sie sicher, dass kritische Subsysteme (Auth, Statusseite, Incident Tooling) im gestörten Modus oder über alternative Routen arbeiten können.

Beobachten Sie die rechts Signale

Die Oszillation zwischen "guter Konfiguration" und "schlechter Konfiguration" alle fünf Minuten ließ das Signal wie Angriffsverkehr oder lautes äußeres Verhalten aussehen:

• Stellen Sie sicher, dass Sie Perversion oder Pro-Fig. Korrelation in Ihrer Observability Pipeline.

• Erstellen Sie Dashboards, die Konfigurationsänderungen visuell sichtbar auf der Oberseite von Fehlergraphen machen.

• stark einschließen synthetische Tests von einem externen Blickwinkel aus, so dass Sie interne Fehler schnell von Netzwerk- / Pfadproblemen unterscheiden können.

Legen Sie nicht alle Ihre Eier in einen Infra-Korb

Für Organisationen, die Cloudflare verwenden:

• Berücksichtigung Mehrfach-CDN Setups für wirklich missionskritische Eigenschaften.

• Vermeiden Sie es, Ihre Statusseite völlig abhängig vom gleichen Anbieter wie Ihr Primärstack (Cloudflare macht dies, aber es gab zufällige Probleme mit ihrem Statusseiten-Host gestern, die die Dinge weiter verwirrten). Der Cloudflare Blog+1

• Denken Sie zweimal darüber nach, bevor Sie Ihre Authentifizierung, API-Kontrollebenen, und Frontendlieferung zum gleichen Anbieter ohne Fallback-Pfade.

Das größere Bild

Allein in den letzten Monaten haben wir große Ausfälle bei Microsoft Azure, Amazon Web Services, und jetzt Cloudflare, die alle vorübergehend große Teile von Verbraucher- und Unternehmensdiensten offline geschaltet haben. AP News+2Die Washington Post+2

Das Muster ist klar:

• Das Internet wird immer mehr abhängig von einer Handvoll riesiger Infrastrukturanbieter.

• Ausfälle sind oft selbstverschuldet, die eher von komplexen internen Veränderungen als von externen Angriffen herrühren.

• Selbst Anbieter mit erstklassigen SRE-Praktiken können immer noch durch unerwartete Interaktionen zwischen Konfiguration, Datenbankverhalten und fest codierten Grenzen.

Der gestrige Cloudflare-Vorfall erinnert stark daran, dass "Die Wolke" ist keine MagieAm Ende ist es immer noch Software, die von Menschen geschrieben wurde und den gleichen Fehlerklassen wie jede andere Anwendung unterliegt - nur mit Größenordnungen mehr Menschen, die davon abhängen.

Für benutzer wird der vorfall meist als an jenem morgen in erinnerung bleiben, an dem x und chatgpt nicht geladen wurden.
Für Ingenieure wird es wahrscheinlich als Lehrbuchbeispiel dafür untersucht, wie Subtile Konfigurationsfehler in einem verteilten Kernsystem können zu einem globalen Internetereignis führen.