Ausfall im globalen Netzwerk von Cloudflare

• Im globalen Netzwerk von Cloudflare kam es zu einer internen Service-Degradation, wodurch mehrere Dienste zeitweise und intermittierend beeinträchtigt wurden
• Wichtige Dienste wie Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers waren vorübergehend von Störungen betroffen
• Das Engineering-Team identifizierte das Problem und arbeitete an einer Behebung; WARP- und Access-Dienste wurden zuerst wiederhergestellt
• Danach normalisierten sich Fehlerrate und Latenz weltweit schrittweise, und auch der Dashboard-Dienst wurde wiederhergestellt
• Derzeit laufen alle Dienste wieder normal, und der Vorfall ist vollständig behoben

---

Überblick über den Vorfall

• Cloudflare erlitt eine interne Service-Degradation (Internal Service Degradation), wodurch einige Dienste intermittierend ausfielen
  • Zu den betroffenen Diensten gehörten Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers
  • Das Unternehmen leitete umgehend Wiederherstellungsmaßnahmen ein und aktualisierte fortlaufend den Stand der Problemlösung

Identifizierung des Problems und erste Reaktion

• Cloudflare bestätigte während der Phase Investigating eine interne Service-Degradation
  • Einige Kunden erlebten intermittierende Fehler und erhöhte Latenzen
  • Das Engineering-Team arbeitete parallel an Ursachenanalyse und Wiederherstellung
• Anschließend wurde die Ursache identifiziert (Identified) und mit der Behebung begonnen
  • Während der Korrekturmaßnahme wurde der WARP-Zugang in der Region London vorübergehend deaktiviert, wodurch Nutzer dort Verbindungsabbrüche zum Internet erlebten

Fortschritt bei der Service-Wiederherstellung

• Nach den Korrekturmaßnahmen wurden die Access- und WARP-Dienste zuerst wiederhergestellt, und die Fehlerrate kehrte auf das Niveau vor dem Vorfall zurück
  • Der WARP-Zugang in der Region London wurde wieder aktiviert
• Danach folgten Wiederherstellungsmaßnahmen für Kunden der Application Services
  • Änderungen zur Wiederherstellung des Dashboard-Dienstes wurden ausgerollt
  • Einige Kunden hatten weiterhin Probleme mit dem Login oder der Nutzung des Dashboards, diese wurden jedoch durch weitere Korrekturen behoben

Stabilisierung des gesamten Netzwerks

• Weltweit gingen Fehlerrate und Latenz (latency) schrittweise zurück und normalisierten sich
  • Die Berechnung der Bot Scores von Bot Management war vorübergehend beeinträchtigt, normalisierte sich jedoch im Verlauf der Wiederherstellung
  • Das Engineering-Team beseitigte verbleibende Fehler und beschleunigte die Wiederherstellung des gesamten Netzwerks
• Danach funktionierten alle Dienste wieder ordnungsgemäß, und Fehlerrate sowie Latenz waren vollständig normalisiert

Abschluss des Vorfalls und weitere Maßnahmen

• Cloudflare bestätigte, dass alle Dienste wieder normal betrieben werden, und schloss den Vorfall ab
  • Derzeit gibt es keine weiteren Konfigurationsänderungen, und die Plattform wird engmaschig überwacht
  • Eine Post-Incident-Untersuchung (post-incident investigation) zur Ursache des Ausfalls ist im Gange; die Ergebnisse sollen später veröffentlicht werden
• Dieser Ausfall wird als Vorfall mit Auswirkungen auf das globale Netzwerk insgesamt eingeordnet

[GN⁺]

Hacker-News-Kommentare

• Jemand mit einem Cloudflare-API-Token teilte einen Befehl, mit dem sich der CF-Proxy deaktivieren lässt
  Mit einem curl-Befehl kann man die Zone-ID und DNS-Einträge abrufen und dann per PATCH "proxied": false setzen
  Man sollte aber aufpassen, weil dabei SSL-Zertifikate verloren gehen können, Sicherheit/Performance leiden und die Backend-IP offengelegt werden kann

  • Falls man nur den alten Global API Key hat, kann man stattdessen die Header X-Auth-Email und X-Auth-Key verwenden
    Wer außerdem nur Cloudflare-Traffic erlaubt hat, muss diese Regel vorübergehend deaktivieren
  • Ich dachte mir, dass ich diese Methode beim nächsten Mal nutzen sollte, hatte aber kein API-Token vorab erstellt und konnte daher nur warten
    Zum Glück ist jetzt wieder alles online
  • Ich habe es über den Terraform-Provider gelöst, aber für Leute ohne Zugriff aufs Dashboard ist diese Methode nützlich
  • Guter Tipp. Zur Info: Bei curl ist GET ohnehin der Standard, -X GET ist also nicht nötig
    Mit -d wird automatisch POST verwendet, und für PATCH ist -X PATCH korrekt
  • Wenn man Cloudflare WARP aktiviert, funktionieren manche Seiten wieder. 1.1.1.1 dürfte einen ähnlichen Effekt haben
    Einige Seiten waren aber selbst nach dem Tunneling noch teilweise ausgefallen

• Laut dem Cloudflare-CTO hat ein potenzieller Bug im Bot-Blockierungssystem nach einer Konfigurationsänderung außer Kontrolle geraten und einen netzwerkweiten Ausfall verursacht
  In der Quelle wird erklärt, dass es kein Angriff, sondern ein internes Problem war

  • Es ist erstaunlich, dass große Unternehmen Konfigurationsänderungen immer noch nicht schrittweise ausrollen
    Code und Konfiguration sind beides Daten, und das Muster, weltweit alles auf einmal auszurollen und dadurch Großstörungen zu verursachen, wiederholt sich ständig
  • Ich wünschte, diese Kerninformation stünde ganz oben in den Kommentaren. Zwischen all den Spekulationen über Cyberangriffe war sie schwer zu finden
  • Wegen einer einzigen Konfigurationsänderung fiel die CF-Aktie um 4 %. Mich würde der wirtschaftliche Schaden solcher Ausfälle für die ganze Branche interessieren

• Ein Kollege kam plötzlich angerannt und sagte, direkt nachdem er eine Cloudflare-Einstellung geändert hatte, sei die Website ausgefallen, und er habe erschrocken gedacht, er sei schuld
  Dieser Beitrag habe ihn beruhigt

  • „Noch schlimmer: Du hast ganz Cloudflare lahmgelegt“, war der Witz dazu
  • Aber wer weiß, vielleicht doch? Es gab ja schon den großen Fastly-Ausfall, also bleibt ein Restverdacht
  • Ich frage mich, ob es ein Wort für dieses seltsame Gefühl der Erleichterung gibt, wenn man weiß, dass nicht tatsächlich jemand einen Fehler gemacht hat
  • Vielleicht ist dieser Kollege ja Cloudflare-Mitarbeiter
  • Ich habe auch Dutzende Nachrichten von Kunden bekommen, dass ihre Seiten nicht erreichbar seien, und weil ich gestern etwas an der Konfiguration geändert hatte, bekam ich kalte Schweißausbrüche
    Als ich „Cloudflare down“ sah, war ich ehrlich erleichtert

• In den Niederlanden schien fast jeder Dienst ausgefallen zu sein
  Auch das Cloudflare-Dashboard war nicht erreichbar, und beim Betterstack-Dashboard war es genauso
  Ironischerweise lief die Statusseite noch, sodass man Kunden nicht benachrichtigen konnte

  • Ich hatte dieselbe Erfahrung. Der einzige Grund, warum HN noch funktionierte, ist wohl, dass sie Cloudflare nicht nutzen
    Ich habe dazu einen Blogbeitrag geschrieben: „Wenn du es nicht brauchst, stell es nicht hinter Cloudflare“
  • Jedes Jahr merkt man wieder, wie riskant die übermäßige Abhängigkeit von AWS oder Cloudflare ist, aber ein Ersatz ist nicht leicht
    Trotzdem zeigen Kunden bei solchen großflächigen Ausfällen überraschend viel Verständnis
  • Das Cloudflare-Dashboard war nicht komplett tot, man konnte den Proxy mit genug Hartnäckigkeit abschalten
    Es hat ein paar Minuten gedauert, aber ich habe hcker.news von CF getrennt
  • Wenn man so etwas sieht, wirkt ein Dienst, der eine Statusseite auf einem lokalen VPS hostet, wie eine mögliche Geschäftschance
  • In meinem Side-Project Total Real Returns
    habe ich unten ein Live-Uptime-Widget eingebaut, das mit einer externen Statusseite verknüpft ist
    Siehe Status-SVG und
    externe Statusseite

• Wenn Cloudflare oder AWS ausfallen, hat es einen gewissen Reiz zu sehen, wie die eigenen self-hosted Dienste völlig unbeeindruckt weiterlaufen
  Im Moment bin ich stabiler als deren 99,999 % Verfügbarkeit

  • Selbst meine dürftige private Website hat AWS-, Azure- und Cloudflare-Ausfälle komplett überlebt
    Vielleicht sollte ich jetzt einen Uptime-Tracker einbauen
  • Meine self-hosted Seite war wegen des Cloudflare-Proxys ausgerechnet selbst down. Ernüchternd
  • Klassische Unternehmen erleben gerade, dass Oracle- oder SAP-Systeme weiterlaufen, während nur die neuen cloudbasierten Dienste stillstehen
    Daraus sollten junge SaaS-Firmen etwas lernen
  • Viele fragen, wie man DNS handhabt. Ich hoste ebenfalls auf einem Raspberry Pi und hatte DNS gerade erst zu Cloudflare umgezogen
    Dass meine kleine Seite nun down war, war zugleich lustig und auf seltsame Weise befriedigend

• In letzter Zeit scheinen großflächige Infrastrukturausfälle stark zuzunehmen. AWS und Cloudflare bleiben beide weit hinter ihrem SLA zurück

  • Das fällt zeitlich mit dem Punkt zusammen, an dem Großunternehmen nach Massenentlassungen durch AI ersetzen wollten
  • Durch solche Ausfälle merkt man, dass die Anzahl der „Neunen“ im SLA bedeutungslos ist
    Es sind keine echten Verfügbarkeitswerte, sondern nur von Unternehmen willkürlich definierte Kennzahlen
  • Manche nennen das die „vibe code theory“: eine halb scherzhafte Theorie, dass mit mehr aus dem Bauch heraus geschriebenem Code auch Bugs und Ausfälle zunehmen
  • Eine andere Analyse ist, dass eine Kultur des überhasteten Deployments dahintersteckt, weil Sperrfristen zum Jahresende und Druck durch Q4-Ziele zusammenkommen
  • Oder es steckt doch ein staatlich koordinierter Cyberangriff dahinter, wenn man es verschwörerisch sehen will

• Das Zentralisierungsproblem ist gravierend: Wenn Cloudflare oder AWS stehen bleiben, steht das halbe Web still

  • Auch die Nutzer kümmert das kaum. Weil dann gefühlt einfach „das Internet kaputt“ ist, können einzelne Dienste sich der Verantwortung entziehen
    Genau deshalb ändert sich an dieser Struktur nichts
  • Bei der DDoS-Abwehr wirken Skaleneffekte. Je mehr Kunden es gibt, desto größer die Bandbreite und desto stärker die Abwehr
    Kleine CDNs können kaum konkurrieren, und am Ende entsteht eine natürliche Monopolstruktur
    Dass Cloudflare einen kostenlosen Tarif angeboten hat, war eine Strategie, genau diese Netzwerkeffekte auszunutzen
  • Noch besorgniserregender als ein Single Point of Failure ist, dass diese Zentralisierung Webstandards und die Zukunft des selbstbestimmten Hostings verzerren könnte
    Außerdem könnte sie zu einem konzentrierten Angriffsziel für staatliche Zensur werden
  • Auch Let's Encrypt birgt ein potenzielles Risiko.
    Zwei Drittel des Webs hängen davon ab, Zertifikatslaufzeiten werden immer kürzer, und wenn es dort einen Hack oder Ausfall gäbe, könnte das ganze Web lahmgelegt werden
    Im Moment ist es eine wohlwollende Organisation, aber man sollte nicht vergessen, dass das früher auch über Google gesagt wurde
  • Seit dem AWS-Boom verlassen sich Entwickler nur noch auf die Cloud statt auf dedizierte Server
    Es gibt viele Backups auf Software-Ebene, aber das Grundverständnis für Multi-Hosting auf Infrastruktur-Ebene ist verloren gegangen

• Ironischerweise nutzte auch DownDetector Cloudflare Turnstile und fiel deshalb mit aus

  • Die Zahl der AWS-Störungsmeldungen schoss ebenfalls hoch, aber vermutlich waren viele davon Fehlalarme
  • Das habe ich auch beobachtet

• Die visuelle Entschuldigung von Cloudflare mit „Your browser: Working / Host: Working / Cloudflare: Error“ war eindrucksvoll

  • So einen Bildschirm habe ich noch nie gesehen. In meinem Fall war „Host“ allerdings Cloudflare Pages, was die Aussage etwas seltsam machte
  • Dass ein Klick auf „Cloudflare“ einen immer noch darauf hinweist, das Problem liege beim Kundensever, ist schon etwas komisch
  • Ich mochte die ehrliche Nachricht, aber die Nutzer reagierten trotzdem nur mit „Repariert mal das WLAN“
  • Trotzdem war die Lage dadurch klarer und man konnte entsprechend reagieren. Bei Bedarf lässt sich der Proxy deaktivieren, um die Auswirkungen zu begrenzen
  • Ich habe auch eine Stunde lang Logs durchsucht, bevor mir klar wurde, dass es nicht mein Server war

• Seiten, die Cloudflare Challenge („I’m not a robot“) verwenden, fielen ebenfalls mit HTTP-500-Fehlern aus
  Es erschien die Meldung, man solle challenges.cloudflare.com entsperren

  • Das Niveau der Fehlerbehandlung ist heute viel zu niedrig. Unternehmen schieben die Schuld gern auf die Nutzer oder zeigen endlose Ladebildschirme
    Dabei liefert das Backend oft klare Fehler zurück, die das Frontend dann verbirgt
    Neulich habe ich sogar gesehen, wie ein Fehler wegen eines zu langen Passworts als „Diese E-Mail wird bereits verwendet“ angezeigt wurde
  • Durch diesen Ausfall stand auch die AI-Suche von chat.bing.com (GPT5) still
    Ironischerweise musste man also einer AI beweisen, dass man ein Mensch ist
  • Manche Seiten, etwa pinkbike, zeigten die Meldung „you have been blocked“
  • Es wurden also nicht nur Roboter, sondern auch echte Menschen blockiert /s
  • Das Frontend scheint fälschlich anzunehmen, der Nutzer habe die Domain per DNS oder Browser-Erweiterung blockiert
    Diese /s-hafte Verneinung, dass Cloudflare Captcha ja unmöglich ausfallen könne, ist schon witzig