Cloudflares Hauptausfall am 18. November - Eine Zusammenfassung

Am 18. November 2025 ist ein großer Teil des Internets zusammengebrochen.
Wenn Sie ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase oder zahllose kleinere Websites öffneten, wurden Sie mit einer mit Cloudflare gekennzeichneten 5xx-Fehlerseite begrüßt - oder die Websites wurden einfach gar nicht geladen. Was zunächst wie ein weiterer großer "Das Internet ist kaputt"-Moment aussah, entpuppte sich als etwas Subtileres und in mancher Hinsicht Besorgnis erregenderes: ein selbstverschuldeter Fehler tief in der eigenen Infrastruktur von Cloudflare.

Im Folgenden finden Sie einen detaillierten Überblick darüber , was beim gestrigen Cloudflare-Ausfall (18. November 2025) passiert ist, warum es dazu kam, wer davon betroffen war und welche Lehren Infrastruktur-Teams daraus ziehen sollten.

Was ist gestern eigentlich passiert?

Am Dienstag, den 18. November 2025, begann Cloudflare am späten Vormittag (UTC) damit, große Mengen an HTTP 5xx Serverfehlern für den Datenverkehr, der durch das Netzwerk lief, zurückzugeben. Für die Endbenutzer bedeutete dies "Internal Server Error" oder "Gateway Error" Seiten, wenn sie versuchten, auf viele beliebte Websites und Anwendungen zuzugreifen.

Laut Cloudflare's eigenem Blog nach dem Vorfall, war der Ausfall:

• Beginn der Beeinträchtigung des HTTP-Verkehrs von Kunden um 11:28 UTC

• Weitverbreitete 5xx-Fehler bei den wichtigsten CDN- und Sicherheitsdiensten wurden angezeigt

• Wichtige Schritte zur Schadensbegrenzung um 13:05-14:30 UTC

• Rückkehr des 5xx-Fehlervolumens auf den Ausgangswert um 17:06 UTC Der Cloudflare Blog

Cloudflare selbst bezeichnete den Ausfall als den schlimmsten seit 2019, da nicht nur eine Funktion oder ein Dashboard betroffen war, sondern die zentrale Proxy-Schicht, die den Großteil des Kundenverkehrs durch das Netzwerk leitet, unterbrochen wurde. Der Cloudflare-Blog

Die Überwachung durch Dritte bestätigte dies. Cisco ThousandEyes sah einen globalen Ausfall, der Cloudflare betraf, mit Timeouts und 5xx-Fehlern bei Diensten wie X, OpenAI (ChatGPT) und Anthropic, während die Netzwerkpfade selbst gesund aussahen. Das deutet stark auf einen Ausfall der Backend-Dienste hin, nicht auf ein ISP- oder Routing-Problem. ThousandEyes

Wer war betroffen?

Da Cloudflare vor einem großen Teil des Internets sitzt (etwa 20 % der Websites im Web verlassen sich in Bezug auf Leistung und Sicherheit auf Cloudflare), war der Radius des Ausfalls enorm. AP Nachrichten+1

Zu den Diensten, die betroffen sein sollen, gehören:

• ChatGPT / OpenAI

• X (ehemals Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends und andere Spieleplattformen

• Verschiedene öffentliche Verkehrsmittel und Regierungsseiten, darunter New Jersey Transit und die digitalen Systeme der französischen Eisenbahn SNCF AP News+1

Ausfall-Tracker wie Downdetector verzeichneten in der Spitze Tausende von gleichzeitigen Störungsmeldungen. Reuters berichtete von etwa 5.000 betroffenen Nutzern allein für X, bevor die Zahl mit der Auslieferung der Korrekturen zurückging. Reuters

Aus der Sicht der Nutzer äußerte sich dies folgendermaßen:

• Websites werden überhaupt nicht geladen

• Hängende oder fehlgeschlagene Anmeldevorgänge (insbesondere wenn Cloudflare Access oder Turnstile beteiligt waren)

• APIs, die nur sporadisch oder mit 5xx-Fehlern reagieren

• Zeitüberschreitungen bei Dashboards und Admin-Panels

Mit anderen Worten: Große Teile des Internets waren "gefühlt" nicht erreichbar, obwohl die Ursache in den internen Systemen eines einzigen Anbieters zu suchen war.

Wie Cloudflare normalerweise funktioniert (in einfachen Worten)

Um zu verstehen, warum dieser Ausfall so schwerwiegend war, ist es hilfreich, den groben Weg einer Anfrage durch das Netzwerk von Cloudflare zu kennen.

Cloudflare fungiert als Reverse Proxy CDN und Sicherheitsschicht:

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

2. Cloudflare terminiert TLS und HTTP an seinem Rand.

3. Anfragen fließen in Cloudflare's Kern-Proxy-System, genannt FL ("Frontline") und seine neuere Generation FL2.

4. Dieser Kern-Proxy:

   • Wendet WAF-Regeln (Web Application Firewall) an

   • Führt Bot-Management-Modelle aus

   • DDoS-Schutz, Caching, Egress zum Ursprung

   • Leitet den Datenverkehr an andere interne Produkte wie Workers, R2, Access, etc. Der Cloudflare-Blog

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

Der gestrige Ausfall war genau deshalb so schlimm, weil der Fehler im gemeinsamen Proxy-Pfad selbst lag und eng mit einer Konfigurationsdatei gekoppelt war, die regelmäßig und automatisch weltweit verteilt wird.

Die Hauptursache: eine fehlerhafte Bot-Management-Datei

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

Hier ist die Kette der Ereignisse im Klartext:

1. Bot Management verwendet eine "Feature-Datei"

   • Das Bot-Erkennungsmodell von Cloudflare stützt sich auf eine Reihe von "Merkmalen" - Signale über jede Anfrage, die verwendet werden, um zu entscheiden, ob es sich um einen Menschen oder einen Bot handelt.

   • Diese Merkmale werden in einer Konfigurationsdatei gebündelt, die alle paar Minuten neu generiert und global ausgerollt wird, damit Cloudflare sich schnell an neue Angriffsmuster anpassen kann. Der Cloudflare-Blog

2. Eine Änderung im ClickHouse-Abfrageverhalten

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

   • Cloudflare hat um 11:05 UTC eine Änderung vorgenommen, um die Sicherheit und die Berechtigungen für verteilte Abfragen zu verbessern - so dass Benutzer Metadaten nicht nur aus einem Standardschema, sondern auch aus den zugrunde liegenden r0-Tabellen sehen können. Der Cloudflare-Blog

   • Die Abfrage, die die Feature-Liste erstellt, filterte nicht nach dem Datenbanknamen; plötzlich erhielt sie doppelte Spalten sowohl aus dem Standard- als auch aus dem r0-Schema, wodurch sich die Anzahl der Feature-Zeilen effektiv verdoppelte.

3. Die Größe der Merkmalsdatei explodierte

   • Das Bot-Verwaltungsmodul hat ein hartes Limit für die Anzahl der Features, die es akzeptiert (auf 200 gesetzt, weit über den ~60, die normalerweise verwendet werden).

   • Als die neu generierte Datei diese Grenze überschritt, stieß das Modul an die Obergrenze und geriet in Panik, was auf einen unbehandelten Fehler im Rust-Code zurückzuführen ist, der Result::unwrap() auf einen Fehlerwert anwendet. Der Cloudflare-Blog

4. Kern-Proxy-Dienste beginnen, 5xx-Fehler zurückzugeben

   • Da die Bot-Verwaltung in den Core-Proxy-Pfad integriert ist, tauchte die Panik als HTTP 5xx-Antworten für jeden Verkehr auf, der von diesem Modul abhing.

   • Bei der neuen FL2-Engine sahen die Kunden explizite 5xx-Fehler.

   • Bei der älteren FL-Engine gingen die Bot-Scores stillschweigend auf Null, was zu falsch positiven Ergebnissen bei Bot-Blocking-Regeln führen konnte. Der Cloudflare-Blog

5. Der wirklich unangenehme Teil: Die Datei wechselte ständig zwischen "gut" und "schlecht" hin und her.

   • Der ClickHouse-Cluster wurde nach und nach aktualisiert, und die Feature-Datei wurde alle fünf Minuten neu erstellt.

   • Manchmal lief die Abfrage auf aktualisierten Knoten (was eine schlechte Datei ergab), manchmal auf nicht aktualisierten Knoten (was eine gute Datei ergab).

   • Das bedeutete, dass das Netzwerk von Cloudflare eine Zeit lang zwischen Normalbetrieb und Ausfall schwankte, da verschiedene Versionen der Datei verbreitet wurden. Der Cloudflare-Blog

Dieses Hin und Her machte die Situation intern äußerst verwirrend. Zunächst vermuteten die Teams von Cloudflare einen massiven DDoS-Angriff, da das Fehlermuster nicht wie ein einfacher Software-Absturz aussah. Sogar die Cloudflare-Statusseite, die außerhalb der eigenen Infrastruktur gehostet wird, zeigte kurzzeitig Fehler an - ein Zufall, der den Verdacht auf einen externen Angriff weiter nährte. Der Cloudflare-Blog+1

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

Zeitleiste des Vorfalls

Auf der Grundlage von Cloudflare's Postmortem und Berichten Dritter können wir eine grobe Zeitleiste für den 18. November 2025 zusammenstellen: Der Cloudflare-Blog+2ThousandEyes+2

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

• 11:20-11:30 UTC - Fehlerhafte Versionen der Bot Management Feature-Datei werden generiert und verbreitet.

• 11:28 UTC - Erste Auswirkungen auf Kunden: Erhöhte HTTP 5xx-Fehler werden im Kundenverkehr festgestellt.

• 11:30-11:32 UTC - Externe Überwachungstools und automatisierte Tests beginnen, intermittierende Ausfälle zu erkennen.

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

• ~11:48 UTC - Cloudflare veröffentlicht ein Status-Update, das einen Vorfall bestätigt. erneut senden.

• 11:30-13:05 UTC - Die Teams konzentrieren sich auf das scheinbar gestörte KV-Verhalten der Mitarbeiter und untersuchen mehrere mögliche Ursachen (einschließlich Angriffsszenarien).

• 13:05 UTC - Wichtige Entschärfung: Workers KV und Cloudflare Access werden umgestellt, um den Kern-Proxy zu umgehen; die Auswirkungen werden reduziert. Der Cloudflare-Blog

• 14:30 UTC - Die Ursache wurde identifiziert; die Generierung und Verbreitung von fehlerhaften Feature-Dateien wurde gestoppt. Eine bekannt gute Konfigurationsdatei wird manuell eingefügt und der Core-Proxy wird neu gestartet. Der Großteil des Kernverkehrs kehrt zum Normalzustand zurück. Der Cloudflare-Blog

• 14:40-15:30 UTC - Dashboard- und Login-Probleme halten an, da Turnstile und ein Rückstau von Authentifizierungsversuchen sekundäre Lastspitzen erzeugen. Der Cloudflare-Blog

• 17:06 UTC - Die Fehlerraten kehren zum Ausgangswert zurück; Cloudflare erklärt die Systeme für völlig normal. Der Cloudflare-Blog

Aus Sicht der Nutzer war der Ausfall am späten Vormittag bis zum frühen Nachmittag (UTC) am schlimmsten, obwohl die genauen Auswirkungen je nach Region und je nachdem, von welchen Cloudflare-Produkten der jeweilige Dienst abhängt, variieren.

Warum dieser Ausfall so wichtig ist

Risiko der Zentralisierung

Cloudflare ist Teil einer kleinen Gruppe von zentralen Internet-Infrastrukturanbietern, neben den großen Cloud-Plattformen (AWS, Azure, GCP) und anderen großen CDNs. Wenn einer dieser Akteure ausfällt, hat das weitreichende und oft nicht offensichtliche Auswirkungen.

Dieser Ausfall:

• Wurde nicht durch eine BGP-Routing-Panne oder einen ISP-Kabelbruch verursacht.

• Er wurde nicht durch einen böswilligen Angriff verursacht (trotz anfänglicher Verdächtigungen).

• Es handelte sich um einen einzigen Konfigurations- und Grenzwertfehler in einer internen Komponente.

Das ist wichtig, denn es zeigt, wie komplexe, eng gekoppelte Systeme auch ohne äußere Einwirkung katastrophal versagen können. Wenn viele Organisationen auf denselben Anbieter bauen, wird dieser Anbieter de facto zu einem systemrelevanten Teil des Internets.

Auch "weiche" Abhängigkeiten schaden

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

• Verwendung von Cloudflare Access für die Authentifizierung und den Zero-Trust-Zugang.

• Verwendung von Workers KV als Teil der internen Kontrollebenen.

• Verlassen sich auf Turnstile für Bot-resistente Logins. Der Cloudflare-Blog+1

Wenn diese Produkte ausfallen, fallen nicht nur die Inhalte der Website aus, sondern auch Logins, Verwaltungsfunktionen und interne APIs. Das macht die Wiederherstellung komplexer: Ihre Statusseite, die Vorfallstools oder die Verwaltungsoberfläche können sich auch auf den Anbieter verlassen, der gerade ausgefallen ist.

Was Cloudflare laut eigenen Angaben ändern wird

Im Blog von Cloudflare werden mehrere Abhilfemaßnahmen beschrieben, die das Unternehmen bereits ergriffen hat, um das Risiko zu verringern, dass sich etwas Ähnliches wiederholt: Der Cloudflare-Blog

1. Schärfung der Aufnahme von automatisch generierten Konfigurationsdateien
   Behandeln Sie intern generierte Konfigurationsdateien mit der gleichen Skepsis und Validierung wie vom Benutzer gelieferte Eingaben, einschließlich einer strengen Schema- und Größenprüfung vor dem Rollout.

2. Mehr globale Kill Switches
   Erleichtern Sie die schnelle Deaktivierung problematischer interner Module (z. B. Bot Management) im gesamten Netzwerk, so dass sie offen ausfallen, anstatt den gesamten Proxy-Pfad in Panik zu versetzen.

3. Schutz der Systemressourcen vor Fehlerstürmen
   Stellen Sie sicher, dass Core-Dumps, Debug-Metadaten und Observability-Tools die CPU und den Speicher nicht überlasten können, wenn es zu Fehlerstürmen kommt.

4. Überprüfen Sie die Fehlermodi aller Kern-Proxy-Module
   Prüfen Sie systematisch, wie sich jedes interne Modul bei unerwarteten Eingaben oder Konfigurationen verhält, und stellen Sie sicher, dass es nicht zu einem globalen Ausfall kommt, sondern zu einem geordneten Abbau der Leistung.

5. Verfeinern Sie Rollouts und Isolierung
   Obwohl der Vorfall nicht sehr detailliert beschrieben wurde, deutet er darauf hin, dass Cloudflare die Ausbreitung neuer Konfigurationen und DB-Verhaltensweisen weiter segmentieren wird, um die Wahrscheinlichkeit zu verringern, dass eine einzelne fehlerhafte Änderung die gesamte Flotte betrifft.

Cloudflare bezeichnete den Vorfall als absolutes Versagen ihrer Erwartungen an die Ausfallsicherheit, nannte ihn "inakzeptabel" und räumte ausdrücklich ein, dass er sowohl Kunden als auch normalen Internetnutzern Schmerzen bereitet hat. Der Cloudflare-Blog

Lektionen für Infrastruktur- und SRE-Teams

Auch wenn Sie kein so großes Unternehmen wie Cloudflare betreiben, können Sie aus diesem Ausfall einige sehr praktische Lehren für Design und Betrieb ziehen:

Behandeln Sie interne Konfigurationen wie nicht vertrauenswürdige Eingaben

Es ist leicht, davon auszugehen, dass unsere eigene" generierte Konfiguration immer korrekt ist. Der gestrige Tag zeigt, warum das gefährlich ist:

• Überprüfen Sie immer die Größe, Form und Grenzen von Konfigurationsdateien, bevor Sie sie anwenden.

• Überlegen Sie, ob Sie die Konfiguration nicht zunächst auf eine kleine Teilmenge von Datenverkehr oder Knoten anwenden und bei Anomalien automatisch zurücksetzen sollten.

• Halten Sie strenge Obergrenzen und Sicherungsautomaten für die Anzahl der Funktionen, die Vorabzuweisung von Speicher und die CPU-Nutzung ein.

Entwerfen Sie ein Design für anfällige Teilausfälle

Ein Fehler im Bot-Management-Modul sollte nicht dazu führen, dass der gesamte Proxy-Pfad in Panik gerät:

• Standardmäßig sollte in einigen Sicherheitsebenen Fail-Open gegenüber Fail-Closed gewählt werden, wenn die Alternative ein kompletter Ausfall ist.

• Bauen Sie klare, getestete Kill Switches für Nicht-Kernfunktionen.

• Stellen Sie sicher, dass kritische Subsysteme (Autorisierung, Statusseite, Vorfallstools) im degradierten Modus oder über alternative Routen funktionieren können.

Beobachten Sie die richtigen Signale

Das Schwanken zwischen "good config" und "bad config" alle fünf Minuten ließ das Signal wie Angriffsverkehr oder verrauschtes externes Verhalten aussehen:

• Stellen Sie sicher, dass Sie eine Korrelation pro Version oder pro Konfiguration in Ihrer Beobachtungspipeline haben.

• Erstellen Sie Dashboards, die Konfigurationsänderungen zusätzlich zu den Fehlerdiagrammen visuell sichtbar machen.

• Binden Sie starke synthetische Tests von einem externen Standpunkt aus ein, damit Sie interne Fehler schnell von Netzwerk-/Pfadproblemen unterscheiden können.

Legen Sie nicht alles auf eine Karte

Für Unternehmen, die Cloudflare verwenden:

• Ziehen Sie Multi-CDN-Setups für wirklich geschäftskritische Eigenschaften in Betracht.

• Vermeiden Sie es, Ihre Statusseite vollständig von demselben Anbieter wie Ihren primären Stack abhängig zu machen (Cloudflare tut dies, aber es gab gestern zufällige Probleme mit ihrem Statusseiten-Host, die die Dinge weiter verwirrten). Der Cloudflare-Blog+1

• Überlegen Sie es sich zweimal, bevor Sie Ihre Authentifizierung, API-Kontrollebenen und die Bereitstellung des Frontends ohne Ausweichpfade eng an denselben Anbieter koppeln.

Das große Ganze

Allein in den letzten Monaten gab es größere Ausfälle bei Microsoft Azure, Amazon Web Services und jetzt auch bei Cloudflare, die allesamt große Teile der Verbraucher- und Unternehmensdienste vorübergehend außer Betrieb gesetzt haben. AP News+2DieWashington Post+2

Das Muster ist klar:

• Das Internet ist zunehmend von einer Handvoll riesiger Infrastrukturanbieter abhängig.

• Ausfälle sind oft selbstverschuldet und gehen eher auf komplexe interne Veränderungen als auf Angriffe von außen zurück.

• Selbst Anbieter mit erstklassigen SRE-Praktiken können immer noch durch unerwartete Wechselwirkungen zwischen Konfiguration, Datenbankverhalten und fest kodierten Grenzen gestört werden.

Der gestrige Vorfall bei Cloudflare ist eine deutliche Erinnerung daran, dass "die Cloud" keine Zauberei ist. Im Grunde handelt es sich immer noch um von Menschen geschriebene Software, die denselben Fehlern unterliegt wie jede andere Anwendung - nur dass um Größenordnungen mehr Menschen von ihr abhängig sind.

Für die Benutzer wird der Vorfall meist als "der Morgen, an dem X und ChatGPT nicht geladen werden konnten" in Erinnerung bleiben.
Für Ingenieure wird er wahrscheinlich als Lehrbuchbeispiel dafür gelten, wie subtile Konfigurationsfehler in einem verteilten Kernsystem zu einem globalen Internet-Ereignis führen können.