Innenansicht von Cloudflares schlimmstem Ausfall seit 2019: Wie eine einzige Feature-Datei das halbe Internet lahmlegte

An einem Dienstagmorgen Ende November brach das Web zusammen. Nicht auf die dramatische Hollywood-Cyber-Crash-Art — mit blinkenden roten Karten und unheilvollen Warnungen —, sondern auf die leisere, nervigere Art, die die meisten Menschen kennen: Seiten, die nicht laden, Apps, die endlos laden, und Login-Bildschirme, die plötzlich aufhören zu funktionieren. Wenn Sie gegen 11:20 UTC am 18. November 2025 online waren, dachten Sie vielleicht, Ihr WLAN habe einen Anfall. In Wirklichkeit spielte ein Teil des Kreislaufsystems des Internets gerade gleichzeitig verrückt.

Cloudflare, der Gigant hinter dem, was das Unternehmen selbst „Connectivity Cloud“ nennt — ein weitläufiges globales Netzwerk, das Websites beschleunigt, Angriffe filtert, APIs antreibt, Authentifizierung übernimmt, DNS verwaltet und als Bindegewebe für einen erschreckend großen Teil des globalen Traffics fungiert —, erlebte seinen größten Ausfall seit sechs Jahren. Und für ein paar Stunden tat Cloudflare nichts davon. Stattdessen warf es 5xx-Fehler wie Konfetti.

In dem Moment, als es losging, gerieten alle in Aufruhr: Site-Betreiber, Dev-Teams, normale Nutzer, die versuchten, die Login-Seite ihrer Bank zu laden. Auch Cloudflares eigene Ingenieure waren in heller Aufregung und versuchten herauszufinden, warum die zentralen Proxy-Systeme außer Kontrolle gerieten, warum Bots nicht korrekt bewertet wurden und warum der Traffic alle fünf Minuten zwischen gesundem und kaputtem Zustand hin- und herpendelte.

Von außen fühlte es sich wie ein großer Angriff an. Cloudflares eigene interne Teams hielten es für einen Angriff. Sogar die externe Statusseite fiel aus — die außerhalb von Cloudflares Infrastruktur gehostet wird. Es war die Art von Zufall, die sich nicht wie Zufall anfühlt.

Aber der Bösewicht war keine DDoS-Bande, kein Staatsakteur und kein neues Botnet, das seine Muskeln spielen ließ.

Es war eine Datei. Eine Feature-Datei. Eine Textdatei, die sich in ihrer Größe verdoppelte und an einer Grenze vorbeischlüpfte, die still darauf gewartet hatte zu explodieren.

In dieser Datei steckte ein Cluster duplizierter Features, erzeugt durch eine gut gemeinte Änderung an Datenbankberechtigungen. Diese Änderung — klein, routinemäßig und theoretisch harmlos — löste eine Kettenreaktion aus, die einen gewaltigen Teil des globalen Internet-Traffics lahmlegte.

Das ist die Geschichte, wie ein einziges Konfigurationsartefakt im Bot-Management-System von Cloudflare das größte Edge-Netzwerk des Planeten lahmlegte.

Der Morgen, an dem das Internet hustete

Das erste Anzeichen von Ärger zeigte sich gegen 11:20 UTC: ein globaler Spike an HTTP-5xx-Fehlern, der im gesamten Cloudflare-Netzwerk auftauchte. Solche Fehler sind in freier Wildbahn nicht selten, aber im Backbone von Cloudflare sollten sie niedrig und stabil bleiben. Eine plötzliche Explosion bedeutete, dass sich etwas Ernstes nicht so verhielt, wie es sollte.

Das Seltsame war nicht nur der Spike — es war die Schwingung. Das System fiel aus, erholte sich, fiel wieder aus. Fünf-Minuten-Intervalle. Ein merkwürdiger Herzschlag.

Ingenieure zogen sofort Metriken, Logs und Traces heran und verfolgten die Idee, dass dies vielleicht ein massiver verteilter Angriff sei. Sie hatten zuletzt einige gesehen, darunter Hyperscale-Ereignisse im Aisuru-Stil. Aber die Fehler passten nicht sauber zu einer klaren Traffic-Signatur. Etwas Internes schlug wild um sich.

Währenddessen sahen Cloudflare-Nutzer Seiten, die aussahen, als wären ihre Sites innerhalb der Cloudflare-Infrastruktur kaputt. Apps, die von Cloudflare Workers KV abhingen, warfen Fehler. Turnstile lud nicht mehr auf Login-Seiten. Die Authentifizierung innerhalb von Cloudflare Access funktionierte für alle nicht mehr, die nicht bereits eingeloggt waren. Nutzer, die Seiten neu luden, sahen kein normales Retry-Verhalten — sie liefen einfach gegen eine Wand.

Innerhalb des Unternehmens flog eine Flut an Incident-Nachrichten hin und her. Der Zufall, dass Cloudflares externe Statusseite ausfiel, befeuerte nur den Verdacht, dass hier ein laufender Angriff im Gange sei. War es nicht. Aber in diesem Moment liefen die Fantasien heiß.

Was noch niemand wusste: Alle fünf Minuten warf Cloudflares Netzwerk eine Münze: Gute Konfigurationsdatei? Alles funktioniert. Schlechte Konfigurationsdatei? Der Proxy-Kern gerät in Panik.

Alles hing davon ab, welcher Datenbank-Node die nächste Query bearbeitete.

Der Auslöser: ein Datenbankberechtigungs-Update, von dem niemand erwartete, dass es wichtig würde

Diese ganze Episode beginnt mit einem ClickHouse-Cluster — der Datenbank-Engine, die einen Teil von Cloudflares Analytics- und Machine-Learning-Feature-Pipeline antreibt.

ClickHouse-Cluster sind gesharded. Cloudflares Setup umfasst zwei zentrale Datenbankschichten:

default — wo verteilte Queries liegen

r0 — wo die zugrunde liegenden Tabellen pro Shard tatsächlich liegen

Historisch sahen Nutzer, die Metadaten über System-Tabellen (wie system.columns) abfragten, nur die Tabellen im default-Schema. Aber Cloudflare-Ingenieure rollten eine Änderung aus: Verteilte Queries sollten unter dem Kontext des auslösenden Nutzers laufen, nicht unter einem gemeinsamen Systemkonto. Ein gutes Ziel: weniger breite Berechtigungen, bessere Isolation, engere Kontrolle.

Um 11:05 UTC ging ein Berechtigungs-Update live, das Datenbanknutzern erlaubte, die zugrunde liegenden Tabellen in r0 nun ebenfalls explizit zu sehen.

Hier lief es aus dem Ruder.

Eine Query, die zur Erzeugung von Cloudflares Bot-Management-Feature-Datei verwendet wurde, sah so aus:

SELECT name, type
FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;

Beachten Sie den fehlenden Filter: Er gibt die Datenbank nicht an. Vor der Berechtigungsänderung spielte das keine Rolle, weil das System nur die Metadaten einer Tabelle zeigte. Aber nach der Änderung? Plötzlich lieferte die Query zwei Sätze identisch aussehender Features — einen aus dem default-Schema, einen aus r0.

Das bedeutete doppelte Features. Und doppelte Features bedeuteten, dass sich die resultierende Feature-Datei effektiv in ihrer Größe verdoppelte.

Diese Datei war kein obskurer Log-Dump, den niemand liest. Sie speist das Machine-Learning-Modell, das jede Cloudflare-Anfrage beim Bot-Scoring durchläuft. Der Kern-Proxy auf jeder Cloudflare-Maschine lädt sie häufig in den Speicher. Sie ist eines der zeitkritischsten Konfigurationsstücke, die Cloudflare erzeugt, ständig aktualisiert und überallhin ausgeliefert.

Und jeder Proxy-Worker-Prozess hatte eine strikte Grenze: Er konnte nicht mehr als 200 Features verarbeiten.

Normale Modelle nutzten ~60. Die Ingenieure hatten reichlich Spielraum. Bis sie plötzlich keinen mehr hatten.

Sobald die Datei diese Obergrenze überschritt, lief der Proxy in einen Rust-Panic in FL2 — der neueren Generation von Cloudflares Frontline-Proxy-Engine — nachdem er frontal in eine unbehandelte Fehlerbedingung im Feature-Loader gerannt war.

Panic → Absturz → überall 5xx-Fehler.

Warum das Netzwerk weiter flackerte

Alle fünf Minuten baute ein geplanter Job die Bot-Feature-Datei neu auf. Aber nur manche Nodes im ClickHouse-Cluster hatten die neuen Berechtigungen. Je nachdem, welcher Node die Query in diesem Moment bearbeitete, erzeugte Cloudflare also entweder:

• eine gültige Feature-Konfigurationsdatei

oder

• eine schlechte, zu groß zum Laden

Gute Datei? Globale Erholung. Schlechte Datei? Globaler Ausfall.

Dieser Roulette-Effekt machte die frühe Untersuchung brutal verwirrend. Jedes Mal, wenn ein Team dachte, das Problem stabilisiere sich vielleicht, konnte der nächste Verteilungs-Tick das Netzwerk augenblicklich wieder zum Absturz bringen.

Schließlich erreichte das Rollout der Berechtigungen jeden Node. Sobald das geschehen war, hörte das Netzwerk auf zu flackern, weil die Feature-Datei durchgehend schlecht war — und durchgehend alles zum Absturz brachte.

Erst dann pendelte sich der Ausfall in einen stabilen, klaren Fehlerzustand ein.

Der Kaskadeneffekt: KV-Ausfälle, Login-Ausfälle, fehlende Bot-Scores

Sobald der Kern-Proxy erstickte, fielen nachgelagerte Subsysteme wie Dominosteine um:

Workers KV

Das Frontend-Gateway hängt vom Proxy-Pfad ab. 5xx-Fehler schossen in die Höhe.

Turnstile

Cloudflares Widget zur menschlichen Verifizierung hörte einfach auf zu laden. Jeder, der versuchte, sich bei einem Dashboard mit Turnstile auf der Seite anzumelden, wurde blockiert.

Access

Die Authentifizierung brach für neue Sessions zusammen. Bereits eingeloggte Nutzer waren in Ordnung; alle anderen bekamen Fehlerseiten.

Cloudflare-Dashboard

Die meisten Nutzer konnten sich während großer Teile des Ausfalls nicht einloggen. Als die Lage später teilweise wiederhergestellt war, erzeugte ein Ansturm an Wiederholungsversuchen seinen eigenen kleinen Verkehrsstau.

Bot Management selbst

Auf der älteren FL-Proxy-Engine schlugen die Bot-Scores nicht fehl — aber sie fielen auf null. Das bedeutete, dass Kunden, die auf Basis des Bot-Scores blockierten, plötzlich alles blockierten. Falsch-Positive überall.

Das war nicht „ein Teil von Cloudflare spinnt“. Es war der Kern des Kerns.

Die Diagnose des Problems: der lange Weg vom Verdacht zur Grundursache

Ingenieure bemerkten Lastspitzen, Wiederholungsversuche und merkwürdiges Verhalten. Sie versuchten Rate-Limiting und Traffic-Verschiebungen, um zu sehen, ob sich das System stabilisieren würde. Nichts half.

Um 13:05 UTC — fast zwei Stunden nach Beginn der Auswirkungen — begann das Team, den Kern-Proxy für Workers KV und Access zu umgehen. Das reduzierte manche Symptome und verschaffte Atemraum.

Bis 13:37 UTC visierten Teams die Bot-Management-Konfigurationsdatei als Auslöser an. Mehrere parallele Workstreams liefen an: ClickHouse untersuchen, Datenbankänderungen zurückrollen, Gerätelogs studieren, die Pipeline zur Erzeugung der Feature-Datei zurückverfolgen.

Schließlich, um 14:24 UTC, stoppte Cloudflare die Erzeugung und Verteilung neuer Feature-Dateien. Man spielte eine bekanntermaßen gute Version ein und verteilte sie global.

Um 14:30 atmete das Internet auf. Der Kern-Traffic begann wieder zu fließen.

Das Ende des Ausfalls — bis 17:06 UTC — bestand aus Aufräumarbeiten: Dienste neu starten, Warteschlangen leeren, Caches stabilisieren, fehlerhafte Zustände bereinigen.

Aber die eigentliche Grundursache war bereits gefunden: eine stille Annahme tief in einem Feature-Generierungsskript, das davon abhing, dass eine Query eine Spaltenliste fester Größe zurückgibt.

Der Teil, den Cloudflare nicht schönredete: Das hätte nie passieren dürfen

Cloudflares CEO schrieb die Aufschlüsselung nach dem Vorfall selbst. Das ist ungewöhnlich. Es signalisiert Schwere.

Das war ihr schlimmster Ausfall seit 2019. Und das Unternehmen versuchte nicht, es schönzureden. Die Fehler waren klar:

• Eine Änderung an Datenbankberechtigungen veränderte das Query-Verhalten auf unerwartete Weise.

• Einer kritischen ML-Konfigurationsdatei fehlten Schutzmechanismen gegen fehlerhaften Inhalt.

• Der Kern-Proxy scheiterte nicht kontrolliert, als Grenzwerte überschritten wurden; er geriet in Panik.

• Die Systeme zur Fehlerdiagnose selbst verbrauchten genug CPU, um Ausfälle zu verschlimmern.

• Kein Kill-Switch verhinderte die Verteilung der defekten Konfiguration.

• Und die Rollout-Pipeline für die Feature-Datei vertraute internen Daten implizit.

Für ein Unternehmen, das sich Resilienz, Redundanz und Fehlerisolation auf Netzwerkebene auf die Fahnen schreibt, sind das schmerzhafte Wahrheiten.

Ein überraschend menschlicher Moment: die interne Angst vor einem koordinierten Angriff

Ein Detail stach in der Diskussion der Community hervor: Cloudflares Ingenieure dachten wirklich, der Ausfall könnte ein Angriff sein. Dass die Statusseite unabhängig davon — und zufällig — ausfiel, sah so aus, als würde jemand Cloudflare und dessen externen Health-Checker gleichzeitig angreifen.

War es nicht. Aber es machte die ersten Minuten chaotisch.

Kunden online äußerten denselben Verdacht. Nach einem Jahr voller massiver Cloud-Ausfälle im großen Maßstab bilden sich die Menschen keine Bedrohungen ein. Sie haben genug gesehen, um zu wissen: Wenn das Internet aufstöhnt, ist das oft kein Zufall.

Reaktionen der Community: Frustration, Verwirrung und einige scharfe Fragen

In den Diskussionen rund um den Ausfall äußerten Menschen echte Bedenken:

Warum dauerte die Diagnose so lange? Kommentatoren fragten sich, warum das Change-Management das ClickHouse-Update nicht sofort sichtbar machte.

Sollte Cloudflare Kunden entschädigen? Das SLA bietet technisch gesehen Gutschriften, aber Nutzer argumentieren, das decke die tatsächlichen geschäftlichen Auswirkungen nicht ab.

Warum wirken Cloudflare-Ausfälle in letzter Zeit häufiger? Manche verwiesen auf jüngste Probleme bei anderen großen Clouds und argumentierten, die Zuverlässigkeit der gesamten Branche wirke wackliger.

Warum liegt Bot Management im kritischen Anfragepfad? Technisch ergibt das Sinn, aber es schafft einen Single Point of Misconfiguration, dessen sich kaum ein Kunde bewusst ist.

Das waren keine Wutkommentare. Es waren praktische Fragen von Menschen, die darauf angewiesen sind, dass Cloudflare langweilig, konsistent und unsichtbar ist.

Die Lösung und der Weg nach vorn

Cloudflare legte die Post-Mortem-Maßnahmen klar dar:

• Die Aufnahme interner Konfigurationsdateien genauso härten wie nicht vertrauenswürdige Nutzereingaben

• Globale Kill-Switches hinzufügen, um außer Kontrolle geratene Config-Rollouts zu verhindern

• Fehlerbehandlung über alle Proxy-Module hinweg verbessern

• Sicherstellen, dass Debug-Systeme die CPUs während Ausfällen nicht überlasten

• Grenzwerte und Annahmen zur Speicherzuweisung überdenken

Das ist eine ambitionierte Liste, aber Cloudflare hat eine Geschichte: Jeder größere Ausfall führt zu einer architektonischen Verbesserung. Ihr Netzwerk ist heute widerstandsfähiger als 2019, wegen vergangener Ausfälle. Nach diesem hier wird es noch kampferprobter sein.

Eine einzige Datei, eine globale Kettenreaktion

Es ist verrückt, sich vorzustellen, dass eine verdoppelte Feature-Datei — ein einfaches Datenartefakt, kein Code — Workloads über Kontinente hinweg zu Fall bringen konnte. Aber das ist die Welt, in der wir leben: vernetzte Systeme, in denen die kleinste interne Annahme einen planetaren Explosionsradius haben kann.

Bei diesem Ausfall ging es nicht um einen Hacker oder ein außer Kontrolle geratenes Botnet. Es ging um eine versteckte Abhängigkeit, aufgedeckt durch eine routinemäßige Berechtigungsänderung, vervielfacht über Zehntausende Maschinen innerhalb von Minuten.

Cloudflare entschuldigte sich, übernahm die Verantwortung für den Fehler und begann die Post-Mortem-Arbeit. Aber die Erkenntnis reicht über Cloudflare hinaus:

Das Internet ist heute ein Geflecht verteilter Systeme, die alle den Daten, Pipelines und selbstaktualisierenden Agenten der jeweils anderen vertrauen. Wenn eine Annahme bricht, spürt alles danach die Folgen.

Das ist nicht beruhigend. Aber es ist die Realität des modernen Web.

Am 18. November 2025 verdoppelte sich eine Feature-Datei in ihrer Größe. Und für ein paar Stunden schrumpfte das Internet mit ihr.