Cloudflares store nedbrud den 18. november - et sammendrag

Den 18. november 2025 faldt en stor del af internettet sammen.
Hvis du åbnede ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase eller utallige mindre sider, blev du mødt af en Cloudflare-branded 5xx-fejlside - eller siderne ville bare slet ikke indlæses. Det, der først lignede endnu et stort "internettet er i stykker"-øjeblik, viste sig at være noget mere subtilt og på nogle måder mere bekymrende: en selvforskyldt fejl dybt inde i Cloudflares egen infrastruktur.

Nedenfor er en detaljeret gennemgang af, hvad der skete i gårsdagens Cloudflare-nedbrud (18. november 2025), hvorfor det skete, hvem det påvirkede, og hvilke erfaringer infrastrukturteams bør tage med sig fra det.

Hvad skete der egentlig i går?

Tirsdag den 18. november 2025, sent om morgenen UTC, begyndte Cloudflare at returnere store mængder HTTP 5xx-serverfejl for trafik, der passerede gennem deres netværk. For slutbrugerne betød det sider med "Internal Server Error" eller "Gateway Error", når de forsøgte at få adgang til mange populære hjemmesider og apps.

Ifølge Cloudflares egen blog efter hændelsen var der tale om et nedbrud:

• Begyndte at påvirke kundernes HTTP-trafik kl. 11:28 UTC

• Så udbredte 5xx-fejl på tværs af centrale CDN- og sikkerhedstjenester

• Havde store afhjælpningstrin omkring 13:05-14:30 UTC

• Returnerede 5xx-fejlvolumen til baseline kl. 17:06 UTC Cloudflare-bloggen

Cloudflare selv beskrev det som sit værste nedbrud siden 2019, fordi det ikke kun påvirkede en funktion eller et dashboard - det forstyrrede det centrale proxylag, der dirigerer størstedelen af kundetrafikken gennem netværket. Cloudflare-bloggen

Tredjepartsovervågning bakkede dette op. Cisco ThousandEyes så et globalt udfald, der påvirkede Cloudflare, med timeouts og 5xx-fejl på tjenester som X, OpenAI (ChatGPT) og Anthropic, mens selve netværksstierne så sunde ud. Det pegede stærkt på en fejl i backend-tjenesten, ikke et problem på ISP-niveau eller med routing. Tusind øjne

Hvem blev påvirket?

Fordi Cloudflare sidder foran en stor del af internettet (omkring 20 % af nettets websteder er afhængige af Cloudflare for at opnå ydeevne og sikkerhed), var eksplosionsradiusen enorm. AP Nyheder+1

Blandt de tjenester, der er rapporteret som påvirkede:

• ChatGPT / OpenAI

• X (tidligere Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends og andre spilplatforme

• Forskellige offentlige transport- og regeringswebsteder, herunder New Jersey Transit og Frankrigs SNCF-jernbanes digitale systemer AP News+1

Afbrydelsestrackere som Downdetector registrerede tusindvis af samtidige problemrapporter på det højeste. Reuters rapporterede om 5.000 berørte brugere for X alene på et tidspunkt, før antallet faldt, efterhånden som rettelserne blev rullet ud. Reuters

Fra en brugers perspektiv manifesterede dette sig som:

• Websteder indlæses slet ikke

• Login-flows hang eller fejlede (især hvor Cloudflare Access eller Turnstile var involveret)

• API'er reagerede periodisk eller med 5xx-fejl

• Dashboards og admin-paneler gik i stå

Med andre ord: Store dele af internettet "føltes nede", selv om grundårsagen var koncentreret i en enkelt udbyders interne systemer.

Hvordan Cloudflare normalt fungerer (i enkle vendinger)

For at forstå, hvorfor dette nedbrud var så alvorligt, hjælper det at kende den omtrentlige vej for en anmodning gennem Cloudflares netværk.

Cloudflare fungerer som et CDN med omvendt proxy og et sikkerhedslag:

1. Din browser eller app opretter forbindelse til Cloudflare i stedet for direkte til oprindelsesstedet.

2. Cloudflare afslutter TLS og HTTP ved sin kant.

3. Anmodninger strømmer ind i Cloudflares kerneproxysystem, kaldet FL ("Frontline") og dets nyere generation FL2.

4. Denne kerneproxy:

   • Anvender WAF-regler (firewall for webapplikationer)

   • Kører Bot Management-modeller

   • Håndterer DDoS-beskyttelse, caching, egress to origin

   • Ruter trafik til andre interne produkter som Workers, R2, Access osv. Cloudflare-bloggen

Under normal drift er denne arkitektur meget modstandsdygtig: Hvis et datacenter har et problem, dirigeres trafikken gennem andre; konfigurationsændringer rulles omhyggeligt ud; individuelle funktioner bør fejle på indesluttede måder.

Gårsdagens udfald var netop slemt, fordi fejlen var inde i selve den fælles proxysti, og den var tæt forbundet med en konfigurationsfil, der bliver sendt ud i hele verden ofte og automatisk.

Den grundlæggende årsag: en bot-management-funktionsfil, der er gået amok

Cloudflares officielle forklaring peger på en vigtig synder:
en konfigurationsfil, der bruges af deres Bot Management-system. Cloudflare-bloggen

Her er kæden af begivenheder i almindeligt sprog:

1. Bot Management bruger en "funktionsfil"

   • Cloudflares bot-detektionsmodel er afhængig af et sæt "features" - signaler om hver anmodning, der bruges til at afgøre, om det er et menneske eller en bot.

   • Disse funktioner er samlet i en konfigurationsfil, der regenereres med få minutters mellemrum og udrulles globalt, så Cloudflare hurtigt kan tilpasse sig nye angrebsmønstre. Cloudflare-bloggen

2. En ændring i ClickHouse-forespørgslernes adfærd

   • Funktionsfilen genereres af forespørgsler mod en ClickHouse-database.

   • Cloudflare foretog en ændring omkring 11:05 UTC for at forbedre sikkerheden og tilladelserne til distribuerede forespørgsler - så brugerne ikke kun kan se metadata fra et standardskema, men også fra underliggende r0-tabeller. Cloudflare-bloggen

   • Forespørgslen, der opbygger funktionslisten, filtrerede ikke efter databasenavn; pludselig begyndte den at få duplikerede kolonner fra både standard og r0, hvilket effektivt fordoblede antallet af funktionsrækker.

3. Funktionsfilen eksploderede i størrelse

   • Bot Management-modulet har en hård grænse for, hvor mange funktioner det vil acceptere (sat til 200, langt over de ca. 60, der normalt bruges).

   • Da den nyligt genererede fil overskred denne grænse, ramte modulet loftet og gik i panik på grund af en uhåndteret fejl i Rust-koden, der brugte Result::unwrap() på en fejlværdi . Cloudflare-bloggen

4. Kerneproxytjenester begyndte at returnere 5xx-fejl

   • Fordi Bot Management er integreret i kerneproxystien, viste panikken sig som HTTP 5xx-svar for al trafik, der var afhængig af dette modul.

   • På den nye FL2-motor så kunderne eksplicitte 5xx-fejl.

   • På den ældre FL-motor gik bot-scores lydløst til nul, hvilket kunne forårsage falske positiver i bot-blokeringsregler. Cloudflare-bloggen

5. Den virkelig slemme del: filen blev ved med at skifte mellem "god" og "dårlig"

   • ClickHouse-klyngen blev gradvist opdateret, og feature-filen blev regenereret hvert femte minut.

   • Nogle gange kørte forespørgslen på opdaterede noder (og producerede en dårlig fil), andre gange på ikke-opdaterede noder (og producerede en god fil).

   • Det betød, at Cloudflares netværk i et stykke tid svingede mellem normal drift og fejl, da forskellige versioner af filen blev udbredt. Cloudflare-bloggen

Denne svingning gjorde situationen ekstremt forvirrende internt. Først mistænkte Cloudflares teams et massivt DDoS-angreb, fordi fejlmønsteret ikke lignede et simpelt softwarecrash. Selv Cloudflares statusside, som ligger uden for deres egen infrastruktur, viste kortvarigt fejl - et sammentræf, der gav yderligere næring til mistanken om et eksternt angreb. Cloudflare-bloggen+1

Først da de indså, at den fælles faktor var bot-funktionsfilen, blev billedet klart.

Tidslinje for hændelsen

Baseret på Cloudflares postmortem og tredjepartsrapporter kan vi sammensætte en grov tidslinje for den 18. november 2025: Cloudflare-bloggen+2ThousandEyes+2

• 11:05 UTC - En ændring af databaseadgangskontrol implementeres i ClickHouse.

• 11:20-11:30 UTC - Dårlige versioner af Bot Management-funktionsfilen begynder at blive genereret og udbredt.

• 11:28 UTC - Første kundepåvirkning: forhøjede HTTP 5xx-fejl ses på kundetrafikken.

• 11:30-11:32 UTC - Eksterne overvågningsværktøjer og automatiserede tests begynder at opdage periodiske fejl.

• 11:35 UTC - Cloudflare åbner et internt hændelsesopkald; undersøgelse begynder.

• ~11:48 UTC - Cloudflare udgiver en statusopdatering, der bekræfter en hændelse. Send igen

• 11:30-13:05 UTC - Teams fokuserer på, hvad der ser ud til at være forringet Workers KV-adfærd, og undersøger flere mulige årsager (herunder angrebsscenarier).

• 13:05 UTC - Vigtig afhjælpning: Workers KV og Cloudflare Access skiftes til at omgå kerneproxyen; påvirkningen reduceres. Cloudflare-bloggen

• 14:30 UTC - Grundårsagen er identificeret; generering og udbredelse af dårlige funktionsfiler er stoppet. En kendt god konfigurationsfil indsættes manuelt, og kerneproxyen genstartes. Det meste af kernetrafikken vender tilbage til det normale. Cloudflare-bloggen

• 14:40-15:30 UTC - Dashboard- og loginproblemer fortsætter, da Turnstile og efterslæb af godkendelsesforsøg skaber sekundære belastningsspidser. Cloudflare-bloggen

• 17:06 UTC - Fejlrater vender tilbage til baseline; Cloudflare erklærer systemerne helt normale. Cloudflare-bloggen

Fra en brugers synspunkt føltes nedbruddet værst sent om morgenen til tidligt på eftermiddagen UTC, selvom de nøjagtige påvirkningsvinduer varierede efter region og efter hvilke Cloudflare-produkter hver tjeneste var afhængig af.

Hvorfor dette nedbrud betyder så meget

Risiko for centralisering

Cloudflare er en del af et lille sæt af centrale internetinfrastrukturudbydere sammen med de store cloud-platforme (AWS, Azure, GCP) og andre store CDN'er. Når en af disse aktører svigter, er konsekvenserne store og ofte ikke indlysende.

Dette udfald:

• Kom ikke fra et BGP-routing-uheld eller et ISP-kabelbrud.

• Kom ikke fra et ondsindet angreb (på trods af indledende mistanke).

• Det skyldtes en enkelt konfigurations- og begrænsningsfejl i en intern komponent.

Det er vigtigt, fordi det viser, hvordan komplekse, tæt koblede systemer kan fejle katastrofalt, selv uden indblanding udefra. Når mange organisationer bygger på den samme udbyder, bliver denne udbyder de facto en systemisk vigtig del af internettet.

"Bløde" afhængigheder gør også ondt

Nogle af de berørte tjenester brugte ikke bare Cloudflare som et dumt CDN. Det gjorde de også:

• Brugte Cloudflare Access til autentificering og zero-trust-adgang.

• Brugte Workers KV som en del af interne kontrolplaner.

• Brugte Turnstile til bot-resistente logins. Cloudflare-bloggen+1

Når disse produkter svigtede, var det ikke kun webstedsindholdet, der gik ned - logins, administratorfunktioner og interne API'er gik også i stykker. Det gør genoprettelsen mere kompleks: Din statusside, dit hændelsesværktøj eller din administratorbrugerflade er måske også afhængig af den selvsamme udbyder, som lige er gået ned.

Hvad Cloudflare siger, at de vil ændre

Cloudflares blog skitserer flere afhjælpningstrin, som virksomheden allerede er i gang med for at reducere risikoen for, at noget lignende gentager sig: Cloudflare-bloggen

1. Skærp indlæsningen af automatisk genererede konfigurationsfiler
   Behandl internt genererede konfigurationer med samme skepsis og validering som brugerleverede input, herunder streng skema- og størrelseskontrol før udrulning.

2. Flere globale kill switches
   Gør det nemmere hurtigt at deaktivere problematiske interne moduler (som Bot Management) på tværs af netværket, så de fejler åbent i stedet for at skabe panik i hele proxy-stien.

3. Beskyt systemressourcer mod fejlstorme
   Sørg for, at kernedumps, debug-metadata og observationsværktøjer ikke overvælder CPU og hukommelse, når fejlene begynder at hobe sig op.

4. Gennemgå fejltilstande på tværs af kerneproxymoduler
   Gennemgå systematisk, hvordan hvert internt modul opfører sig under uventet input eller konfiguration, og sørg for elegant nedbrydning i stedet for global fiasko.

5. Finpuds udrulning og isolering
   Selv om det ikke er beskrevet i detaljer, tyder hændelsen på, at Cloudflare sandsynligvis vil segmentere yderligere, hvordan nye konfigurationer og DB-adfærd spredes, for at reducere risikoen for, at en enkelt dårlig ændring påvirker hele flåden.

De indrammede også hændelsen som en absolut fiasko i forhold til deres forventninger til robusthed, kaldte det "uacceptabelt" og anerkendte udtrykkeligt den smerte, det forårsagede både kunder og almindelige internetbrugere. Cloudflare-bloggen

Lektioner for infrastruktur- og SRE-teams

Selv hvis du ikke driver noget så stort som Cloudflare, er der nogle meget praktiske design- og driftslektioner i dette nedbrud:

Behandl intern konfiguration som input, der ikke er tillid til

Det er nemt at antage, at "vores egen" genererede konfiguration altid er korrekt. I går viste vi, hvorfor det er farligt:

• Valider altid størrelse, form og grænser for konfigurationsfiler, før du anvender dem.

• Overvej først at anvende konfigurationen på en lille delmængde af trafikken eller knudepunkterne med automatisk tilbagerulning ved uregelmæssigheder.

• Hold strenge øvre grænser og strømafbrydere omkring antallet af funktioner, præallokering af hukommelse og CPU-brug.

Design til yndefulde delvise fejl

En fejl i Bot Management-modulet bør ikke kunne få hele proxy-stien til at gå i panik:

• Standard til fail-open vs fail-closed i nogle sikkerhedslag, når alternativet er komplet udfald.

• Byg klare, testede kill switches til ikke-kernefunktioner.

• Sørg for, at kritiske undersystemer (auth, statusside, incident tooling) kan fungere i forringet tilstand eller via alternative ruter.

Hold øje med de rigtige signaler

Svingningen mellem "god config" og "dårlig config" hvert femte minut fik signalet til at ligne angrebstrafik eller støjende ekstern adfærd:

• Sørg for, at du har korrelation pr. version eller pr. konfiguration i din observationspipeline.

• Byg dashboards, der gør konfigurationsændringer visuelt indlysende oven på fejlgrafer.

• Inkluder stærke syntetiske tests fra et eksternt udsigtspunkt, så du hurtigt kan skelne mellem interne fejl og netværks-/stiproblemer.

Læg ikke alle dine æg i én infrastrukturkurv

For organisationer, der bruger Cloudflare:

• Overvej multi-CDN-opsætninger til virkelig missionskritiske egenskaber.

• Undgå at gøre din statusside helt afhængig af den samme udbyder som din primære stak (Cloudflare gør dette, men der var tilfældigvis problemer med deres statussidevært i går, hvilket forvirrede tingene yderligere). Cloudflare-bloggen+1

• Tænk dig om en ekstra gang, før du kobler din autentificering, API-kontrolplan og frontend-levering tæt sammen med den samme leverandør uden reserveveje.

Det større billede

Alene i de sidste par måneder har vi set store udfald hos Microsoft Azure, Amazon Web Services og nu Cloudflare, som alle midlertidigt har sat store dele af forbruger- og virksomhedstjenesterne ud af drift. AP News+2TheWashington Post+2

Mønsteret er klart:

• Internettet er i stigende grad afhængigt af en håndfuld gigantiske infrastrukturudbydere.

• Afbrydelser er ofte selvforskyldte og skyldes komplekse interne ændringer snarere end angreb udefra.

• Selv udbydere med SRE-praksis i verdensklasse kan stadig blive snydt af uventede interaktioner mellem konfiguration, databaseadfærd og hårdkodede grænser.

Gårsdagens Cloudflare-hændelse er en skarp påmindelse om, at "skyen" ikke er magisk. I bund og grund er det stadig software, der er skrevet af mennesker, og som er udsat for de samme typer fejl som alle andre applikationer - bare med langt flere mennesker, der er afhængige af den.

For brugerne vil hændelsen for det meste blive husket som "den morgen, hvor X og ChatGPT ikke ville indlæses".
For ingeniører vil den sandsynligvis blive studeret som et skoleeksempel på, hvordan subtile konfigurationsfejl i et centralt distribueret system kan sprede sig til en global internetbegivenhed.