Cloudflares store strømbrudd 18. november - en oppsummering

Den 18. november 2025 falt en stor del av internett sammen.
Hvis du åpnet ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase eller utallige mindre nettsteder, ble du møtt med en Cloudflare-merket 5xx-feilside - eller så ble ikke nettstedene lastet inn i det hele tatt. Det som først så ut som nok et stort "internett er ødelagt"-øyeblikk, viste seg å være noe mer subtilt og på noen måter mer bekymringsfullt: en selvpåført feil dypt inne i Cloudflares egen infrastruktur.

Nedenfor følger en detaljert gjennomgang av hva som skjedde under gårsdagens Cloudflare-nedbrudd (18. november 2025), hvorfor det skjedde, hvem det påvirket og hva infrastrukturteam bør lære av det.

Hva skjedde egentlig i går?

Tirsdag 18. november 2025, sent på morgenen UTC, begynte Cloudflare å returnere store mengder HTTP 5xx-serverfeil for trafikk som passerte gjennom nettverket. For sluttbrukere betydde det "Internal Server Error"- eller "Gateway Error"-sider når de prøvde å få tilgang til mange populære nettsteder og apper.

I følge Cloudflares egen blogg etter hendelsen, var strømbruddet

• Begynte å påvirke kundenes HTTP-trafikk kl. 11:28 UTC

• Så utbredte 5xx-feil på tvers av CDN- og sikkerhetstjenester

• Hadde store avbøtende tiltak rundt 13:05-14:30 UTC

• Returnerte 5xx-feilvolumet til baseline innen 17:06 UTC Cloudflare-bloggen

Cloudflare selv beskrev det som det verste strømbruddet siden 2019, fordi det ikke bare påvirket én funksjon eller ett dashbord - det forstyrret det sentrale proxy-laget som dirigerer mesteparten av kundetrafikken gjennom nettverket. Cloudflare-bloggen

Tredjepartsovervåking støttet dette. Cisco ThousandEyes så et globalt strømbrudd som påvirket Cloudflare, med tidsavbrudd og 5xx-feil på tjenester som X, OpenAI (ChatGPT) og Anthropic, mens selve nettverksbanene så friske ut. Det pekte sterkt mot en feil i backend-tjenesten, ikke et problem på ISP-nivå eller ruting. ThousandEyes

Hvem ble berørt?

Fordi Cloudflare ligger foran en massiv del av internett (rundt 20 % av nettstedene på nettet er avhengige av Cloudflare for ytelse og sikkerhet), var sprengningsradiusen enorm. AP Nyheter+1

Blant tjenestene som er rapportert som påvirket:

• ChatGPT / OpenAI

• X (tidligere Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends og andre spillplattformer

• Ulike offentlige transport- og myndighetsnettsteder, inkludert New Jersey Transit og SNCFs digitale jernbanesystem i Frankrike AP News+1

Avbruddssporere som Downdetector registrerte tusenvis av samtidige problemrapporter på det meste. Reuters rapporterte om 5000 berørte brukere for X alene på et tidspunkt, før antallet gikk ned etter hvert som løsningene ble rullet ut. Reuters

Fra et brukerperspektiv manifesterte dette seg som:

• Nettsteder lastes ikke inn i det hele tatt

• Innloggingsflyter henger eller mislykkes (spesielt der Cloudflare Access eller Turnstile var involvert)

• API-er svarte av og til eller med 5xx-feil

• Dashbord og administrasjonspaneler med tidsavbrudd

Med andre ord: Store deler av internett "føltes nede", selv om årsaken var konsentrert i en enkelt leverandørs interne systemer.

Hvordan Cloudflare normalt fungerer (i enkle ordelag)

For å forstå hvorfor dette strømbruddet var så alvorlig, er det nyttig å vite hvordan en forespørsel i grove trekk går gjennom Cloudflares nettverk.

Cloudflare fungerer som et omvendt proxy-CDN og sikkerhetslag:

1. Nettleseren eller appen din kobler seg til Cloudflare i stedet for direkte til opprinnelsesstedet.

2. Cloudflare terminerer TLS og HTTP på sin kant.

3. Forespørsler strømmer inn i Cloudflares kjerneproxy-system, kalt FL ("Frontline") og den nyere generasjonen FL2.

4. Denne kjerneproxyen:

   • Anvender WAF-regler (brannmur for webapplikasjoner)

   • Kjører Bot Management-modeller

   • Håndterer DDoS-beskyttelse, hurtigbufring, utgang til opprinnelse

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

I normal drift er denne arkitekturen svært robust: Hvis ett datasenter har et problem, rutes trafikken gjennom andre; konfigurasjonsendringer rulles ut forsiktig; individuelle funksjoner bør mislykkes på begrensede måter.

Gårsdagens strømbrudd var nettopp ille fordi feilen var inne i selve den felles proxy-stien, og den var tett koblet til en konfigurasjonsfil som blir sendt ut over hele verden ofte og automatisk.

Årsaken: en bot-administrasjonsfil som gikk på avveie

Cloudflares offisielle forklaring peker på én hovedårsak:
En konfigurasjonsfil som brukes av deres Bot Management-system. Cloudflare-bloggen

Her er hendelsesforløpet i klartekst:

1. Bot Management bruker en "funksjonsfil"

   • Cloudflares bot-deteksjonsmodell er avhengig av et sett med "funksjoner" - signaler om hver forespørsel som brukes til å avgjøre om det er et menneske eller en bot.

   • Disse funksjonene er samlet i en konfigurasjonsfil som regenereres med noen minutters mellomrom og rulles ut globalt, slik at Cloudflare kan tilpasse seg raskt til nye angrepsmønstre. Cloudflare-bloggen

2. En endring i ClickHouse-spørringsatferd

   • Funksjonsfilen genereres av spørringer mot en ClickHouse-database.

   • Cloudflare gjorde en endring rundt 11:05 UTC for å forbedre sikkerheten og tillatelsene for distribuerte spørringer - slik at brukerne ikke bare kan se metadata fra et standardskjema, men også fra underliggende r0-tabeller. Cloudflare-bloggen

   • Spørringen som bygger funksjonslisten, filtrerte ikke etter databasenavn; plutselig begynte den å få dupliserte kolonner fra både standard og r0, noe som i praksis doblet antallet funksjonsrader .

3. Funksjonsfilen eksploderte i størrelse

   • Bot Management-modulen har en hard grense for hvor mange funksjoner den godtar (satt til 200, langt over de ca. 60 som normalt er i bruk).

   • Da den nylig genererte filen overskred denne grensen, fikk modulen panikk på grunn av en uhåndtert feil i Rust-koden som brukte Result::unwrap() på en feilverdi . Cloudflare-bloggen

4. Kjerneproxytjenester begynte å returnere 5xx-feil

   • Fordi Bot Management er integrert i kjerneproxy-banen, dukket panikken opp som HTTP 5xx-svar for all trafikk som var avhengig av den modulen.

   • På den nye FL2-motoren så kundene eksplisitte 5xx-feil.

   • På den eldre FL-motoren gikk bot-score stille til null, noe som kunne forårsake falske positiver i bot-blokkeringsregler. Cloudflare-bloggen

5. Den virkelig ekle delen: filen fortsatte å veksle mellom "god" og "dårlig"

   • ClickHouse-klyngen ble gradvis oppdatert, og funksjonsfilen ble regenerert hvert femte minutt.

   • Noen ganger ble spørringen kjørt på oppdaterte noder (som produserte en dårlig fil), andre ganger på ikke-oppdaterte noder (som produserte en god fil).

   • Det betydde at Cloudflares nettverk en stund pendlet mellom normal drift og feil etter hvert som ulike versjoner av filen ble spredt. Cloudflare-bloggen

Denne svingningen gjorde situasjonen ekstremt forvirrende internt. Først mistenkte Cloudflares team et massivt DDoS-angrep fordi feilmønsteret ikke så ut som en enkel programvarekrasj. Til og med Cloudflares statusside, som ligger utenfor deres egen infrastruktur, viste feil i en kort periode - et sammentreff som ytterligere forsterket mistanken om et eksternt angrep. Cloudflare-bloggen+ 1

Først da de innså at den felles faktoren var bot-funksjonsfilen, ble bildet klart.

Tidslinje for hendelsen

Basert på Cloudflares postmortem og tredjepartsrapporter kan vi sette sammen en grov tidslinje for 18. november 2025: Cloudflare-bloggen+2ThousandEyes+2

• 11:05 UTC - En endring i databasetilgangskontrollen distribueres i ClickHouse.

• 11:20-11:30 UTC - Dårlige versjoner av Bot Management-funksjonsfilen begynner å bli generert og spredt.

• 11:28 UTC - Første kundepåvirkning: forhøyede HTTP 5xx-feil i kundetrafikken.

• 11:30-11:32 UTC - Eksterne overvåkingsverktøy og automatiserte tester begynner å oppdage periodiske feil.

• 11:35 UTC - Cloudflare åpner en intern hendelsesanrop; etterforskning begynner.

• ~11:48 UTC - Cloudflare publiserer en statusoppdatering som bekrefter en hendelse. Send på nytt

• 11:30-13:05 UTC - Teamene fokuserer på det som ser ut til å være degradert KV-atferd og undersøker flere mulige årsaker (inkludert angrepsscenarioer).

• 13:05 UTC - Viktige tiltak: Workers KV og Cloudflare Access flyttes for å omgå kjerneproxyen; virkningen reduseres. Cloudflare-bloggen

• 14:30 UTC - Rotårsaken er identifisert; generering og spredning av dårlige funksjonsfiler stoppes. En kjent god konfigurasjonsfil settes inn manuelt, og kjerneproxyen startes på nytt. Det meste av kjernetrafikken går tilbake til det normale. Cloudflare-bloggen

• 14:40-15:30 UTC - Problemer med dashbord og innlogging vedvarer ettersom Turnstile og etterslep av autentiseringsforsøk skaper sekundære belastningstopper. Cloudflare-bloggen

• 17:06 UTC - Feilfrekvenser går tilbake til grunnlinjen; Cloudflare erklærer systemer helt normale. Cloudflare-bloggen

Fra et brukersynspunkt føltes strømbruddet verst sent på morgenen til tidlig ettermiddag UTC, selv om det nøyaktige tidsvinduet varierte etter region og etter hvilke Cloudflare-produkter hver tjeneste var avhengig av.

Hvorfor dette strømbruddet er så viktig

Sentraliseringsrisiko

Cloudflare er en del av et lite sett med sentrale leverandører av internettinfrastruktur, sammen med de store skyplattformene (AWS, Azure, GCP) og andre store CDN-er. Når en av disse aktørene svikter, får det store og ofte ikke-åpenbare konsekvenser.

Dette strømbruddet:

• Skyldtes ikke et uhell med BGP-ruting eller en avbrutt ISP-kabel.

• Kom ikke fra et ondsinnet angrep (til tross for innledende mistanker).

• Det skyldtes en enkelt konfigurasjons- og begrensningsfeil i en intern komponent.

Dette er viktig fordi det viser hvordan komplekse, tett koblede systemer kan svikte katastrofalt selv uten ekstern innblanding. Når mange organisasjoner bygger på samme leverandør, blir denne leverandøren de facto en systemisk viktig del av internett.

"Myke" avhengigheter ble også rammet

Noen av de berørte tjenestene brukte ikke bare Cloudflare som et dumt CDN. De gjorde det:

• De brukte Cloudflare Access for autentisering og nulltillitstilgang.

• Brukte Workers KV som en del av interne kontrollplaner.

• Stole på Turnstile for bot-resistente pålogginger. Cloudflare-bloggen+ 1

Når disse produktene sviktet, var det ikke bare innholdet på nettstedet som gikk ned - pålogginger, administratorfunksjoner og interne API-er gikk også i stykker . Det gjør gjenopprettingen mer kompleks: Statussiden, hendelsesverktøyet eller brukergrensesnittet for administratorer kan også være avhengig av den samme leverandøren som nettopp sviktet.

Hva Cloudflare sier at de vil endre

Cloudflares blogg beskriver flere tiltak selskapet allerede har iverksatt for å redusere risikoen for at noe lignende skal skje igjen: Cloudflare-bloggen

1. Forsterke inntak av automatisk genererte konfigurasjonsfiler
   Behandle internt genererte konfigurasjonsfiler med samme skepsis og validering som brukerleverte filer, inkludert streng kontroll av skjema og størrelse før utrulling.

2. Flere globale kill-switcher
   Gjør det enklere å raskt deaktivere problematiske interne moduler (som Bot Management) på tvers av nettverket, slik at de mislykkes når de åpnes i stedet for å skape panikk i hele proxy-banen.

3. Beskytt systemressurser mot feilstormer
   Sørg for at kjernedumper, feilsøkingsmetadata og observerbarhetsverktøy ikke overbelaster CPU og minne når feilene begynner å øke.

4. Gjennomgå feilmoduser på tvers av proxy-kjernemoduler
   Gå systematisk gjennom hvordan hver interne modul oppfører seg under uventede inndata eller konfigurasjon, og sørg for en gradvis nedbrytning i stedet for global feil.

5. Avgrens utrullinger og isolering
   Selv om hendelsen ikke er beskrevet i detalj, tyder hendelsen på at Cloudflare sannsynligvis vil segmentere ytterligere hvordan nye konfigurasjoner og DB-atferd sprer seg, for å redusere sjansen for at en enkelt dårlig endring påvirker hele flåten.

De har også innrammet hendelsen som en absolutt svikt i deres forventninger til robusthet, og kaller det "uakseptabelt" og anerkjenner eksplisitt smerten det forårsaket både kunder og vanlige internettbrukere. Cloudflare-bloggen

Lærdom for infrastruktur- og SRE-team

Selv om du ikke driver noe så stort som Cloudflare, er det noen veldig praktiske design- og driftslærdommer å trekke ut av dette strømbruddet:

Behandle intern konfigurasjon som upålitelig input

Det er lett å anta at "vår egen" genererte konfigurasjon alltid er korrekt. Gårsdagen viser hvorfor det er farlig:

• Valider alltid konfigurasjonsfilenes størrelse, form og begrensninger før du bruker dem.

• Vurder å bruke konfigurasjonen på en liten delmengde av trafikken eller nodene først, med automatisk tilbakestilling ved avvik.

• Ha strenge øvre grenser og kretsbrytere rundt antall funksjoner, forhåndsallokering av minne og CPU-bruk.

Design for grasiøs delvis svikt

Én feil i Bot Management-modulen bør ikke kunne skape panikk i hele proxy-stien:

• Standard for fail-open vs fail-closed i noen sikkerhetslag når alternativet er fullstendig avbrudd.

• Bygg tydelige, testede nødstopp for ikke-kjernefunksjoner.

• Sørg for at kritiske delsystemer (autentisering, statusside, hendelsesverktøy) kan fungere i degradert modus eller via alternative ruter.

Observer de riktige signalene

Pendlingen mellom "god konfigurasjon" og "dårlig konfigurasjon" hvert femte minutt fikk signalet til å se ut som angrepstrafikk eller støyende ekstern atferd:

• Sørg for at du har korrelasjon per versjon eller per konfigurasjon i observasjonspipelinen din.

• Lag dashbord som gjør konfigurasjonsendringer visuelt tydelige på toppen av feilgrafer.

• Inkluder sterke syntetiske tester fra et eksternt utsiktspunkt, slik at du raskt kan skille mellom interne feil og nettverks-/stiproblemer.

Ikke legg alle eggene i én infrastrukturkurv

For organisasjoner som bruker Cloudflare:

• Vurder oppsett med flere CDN-er for virkelig virksomhetskritiske egenskaper.

• Unngå å gjøre status-siden helt avhengig av den samme leverandøren som den primære stakken (Cloudflare gjør dette, men det var tilfeldige problemer med status-siden deres i går, noe som forvirret ting ytterligere). Cloudflare-bloggen+ 1

• Tenk deg om to ganger før du kobler autentisering, API-kontrollplan og frontend-levering tett til samme leverandør uten reserveløsninger.

Det større bildet

Bare i løpet av de siste månedene har vi sett store strømbrudd hos Microsoft Azure, Amazon Web Services og nå Cloudflare, som alle midlertidig har slått store deler av forbruker- og bedriftstjenester offline. AP News+2TheWashington Post+2

Mønsteret er tydelig:

• Internett blir stadig mer avhengig av en håndfull gigantiske infrastrukturleverandører.

• Avbrudd er ofte selvforskyldt, og skyldes komplekse interne endringer snarere enn eksterne angrep.

• Selv leverandører med SRE-praksis i verdensklasse kan likevel bli satt ut av spill av uventede interaksjoner mellom konfigurasjon, databaseatferd og hardkodede grenser.

Gårsdagens Cloudflare-hendelse er en sterk påminnelse om at "skyen" ikke er magisk. I bunn og grunn er det fortsatt programvare som er skrevet av mennesker, og som er utsatt for de samme typene feil som alle andre applikasjoner - bare med mange flere mennesker som er avhengige av den.

For brukerne vil hendelsen for det meste bli husket som "den morgenen da X og ChatGPT ikke lot seg laste inn".
For ingeniører vil den sannsynligvis bli studert som et skoleeksempel på hvordan subtile konfigurasjonsfeil i et distribuert kjernesystem kan spre seg til en global internetthendelse.