Cloudflares stora avbrott den 18 november - en sammanfattning

Den 18 november 2025 föll en stor del av internet samman.
Om du öppnade ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase eller otaliga mindre webbplatser möttes du av en Cloudflare-märkt 5xx-felsida - eller så laddades webbplatserna helt enkelt inte alls. Det som först såg ut som ännu ett stort "internet är trasigt"-ögonblick visade sig vara något mer subtilt och på vissa sätt mer oroande: en självförvållad bugg djupt inne i Cloudflares egen infrastruktur.

Nedan följer en detaljerad genomgång av vad som hände i gårdagens Cloudflare-avbrott (18 november 2025), varför det hände, vem det påverkade och vilka lärdomar infrastrukturteam bör ta med sig från det.

Vad hände egentligen igår?

Tisdagen den 18 november 2025, runt sen morgon UTC, började Cloudflare returnera stora volymer av HTTP 5xx-serverfel för trafik som passerade genom dess nätverk. För slutanvändare innebar det "Internal Server Error" eller "Gateway Error"-sidor när de försökte komma åt många populära webbplatser och appar.

Enligt Cloudflares egen blogg efter incidenten, avbrottet:

• Började påverka kundernas HTTP-trafik kl. 11:28 UTC

• Såg utbredda 5xx-fel över CDN- och säkerhetstjänster

• Hade stora begränsningssteg runt 13:05-14:30 UTC

• Återförde 5xx-felvolymen till baslinjen vid 17:06 UTC Cloudflare-bloggen

Cloudflare själv beskrev det som sitt värsta avbrott sedan 2019, eftersom det inte bara påverkade en funktion eller instrumentpanel - det störde kärnproxylagret som dirigerar majoriteten av kundtrafiken genom sitt nätverk. Cloudflare-bloggen

Tredjepartsövervakning backade upp detta. Cisco ThousandEyes såg ett globalt avbrott som påverkade Cloudflare, med timeouts och 5xx-fel på tjänster som X, OpenAI (ChatGPT) och Anthropic, medan själva nätverksvägarna såg friska ut. Det pekade starkt på ett backend-tjänstefel, inte ett problem på ISP-nivå eller routing. Tusen ögon

Vem påverkades?

Eftersom Cloudflare sitter framför en massiv del av internet (cirka 20% av webbsidorna förlitar sig på Cloudflare för prestanda och säkerhet) var sprängningsradien enorm. AP Nyheter+1

Bland de tjänster som rapporterats som påverkade:

• ChatGPT / OpenAI

• X (tidigare Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends och andra spelplattformar

• Olika webbplatser för kollektivtrafik och myndigheter, inklusive New Jersey Transit och franska SNCF:s digitala järnvägssystem AP News+1

Avbrottsspårare som Downdetector registrerade tusentals samtidiga problemrapporter när det var som värst. Reuters rapporterade cirka 5 000 drabbade användare för X ensam vid en tidpunkt, innan antalet minskade när korrigeringar rullades ut. Reuters

Från en användares perspektiv manifesterades detta som:

• Webbplatser laddas inte alls

• Inloggningsflöden hängde eller misslyckades (särskilt där Cloudflare Access eller Turnstile var inblandade)

• API:er svarade intermittent eller med 5xx-fel

• Dashboards och adminpaneler tidsinställda

Med andra ord: stora delar av internet "kändes nere", även om grundorsaken var koncentrerad till en enda leverantörs interna system.

Hur Cloudflare normalt fungerar (i enkla termer)

För att förstå varför detta avbrott var så allvarligt hjälper det att känna till den grova vägen för en begäran genom Cloudflares nätverk.

Cloudflare fungerar som en omvänd proxy, CDN och ett säkerhetslager:

1. Din webbläsare eller app ansluter till Cloudflare istället för direkt till ursprungswebbplatsen.

2. Cloudflare terminerar TLS och HTTP vid sin kant.

3. Förfrågningar flödar in i Cloudflares kärnproxysystem, som kallas FL ("Frontline") och dess nyare generation FL2.

4. Denna kärnproxy:

   • Tillämpar WAF-regler (brandvägg för webbapplikationer)

   • Kör Bot Management-modeller

   • Hanterar DDoS-skydd, cachelagring, egress till ursprung

   • dirigerar trafik till andra interna produkter som Workers, R2, Access etc. Cloudflare-bloggen

Vid normal drift är denna arkitektur mycket motståndskraftig: om ett datacenter har problem dirigeras trafiken genom andra; konfigurationsändringar rullas ut noggrant; enskilda funktioner bör misslyckas på begränsade sätt.

Gårdagens avbrott var just dåligt eftersom felet låg i själva den gemensamma proxyvägen, och det var tätt kopplat till en konfigurationsfil som skickas ut över hela världen ofta och automatiskt.

Grundorsaken: en funktionsfil för bot-hantering som blivit oseriös

Cloudflares officiella förklaring pekar på en huvudskyldig:
En konfigurationsfil som används av deras Bot Management-system. Cloudflare-bloggen

Här är händelsekedjan på vanligt språk:

1. Bot Management använder en "funktionsfil"

   • Cloudflares botdetekteringsmodell förlitar sig på en uppsättning "funktioner" - signaler om varje begäran som används för att avgöra om det är mänskligt eller en bot.

   • Dessa funktioner samlas i en konfigurationsfil som regenereras med några minuters mellanrum och rullas ut globalt, så att Cloudflare snabbt kan anpassa sig till nya attackmönster. Cloudflare-bloggen

2. En förändring i ClickHouse-frågornas beteende

   • Funktionsfilen genereras av förfrågningar mot en ClickHouse-databas.

   • Cloudflare gjorde en ändring runt 11:05 UTC för att förbättra säkerheten och behörigheterna för distribuerade frågor - så att användare kan se metadata inte bara från ett standardschema utan också från underliggande r0-tabeller. Cloudflare-bloggen

   • Frågan som bygger funktionslistan filtrerade inte efter databasnamn; plötsligt började den få duplicerade kolumner från både standard och r0, vilket effektivt fördubblade antalet funktionsrader.

3. Funktionsfilen exploderade i storlek

   • Bot Management-modulen har en hård gräns för hur många funktioner den accepterar (inställd på 200, långt över de ~ 60 som normalt används).

   • När den nygenererade filen överskred den gränsen slog modulen i taket och fick panik, på grund av ett ohanterat fel i Rust-koden som använde Result::unwrap() på ett felvärde . Cloudflare-bloggen

4. Kärnproxytjänster började returnera 5xx-fel

   • Eftersom Bot Management är integrerad i kärnproxysökvägen dök paniken upp som HTTP 5xx-svar för all trafik som var beroende av den modulen.

   • På den nya FL2-motorn såg kunderna explicita 5xx-fel.

   • På den äldre FL-motorn gick botpoängen tyst till noll, vilket kan orsaka falska positiva resultat i botblockeringsregler. Cloudflare-bloggen

5. Den riktigt otäcka delen: filen fortsatte att växla mellan "bra" och "dålig"

   • ClickHouse-klustret uppdaterades gradvis, och funktionsfilen regenererades var femte minut.

   • Ibland kördes frågan på uppdaterade noder (vilket gav en dålig fil), ibland på icke-uppdaterade noder (vilket gav en bra fil).

   • Det innebar att Cloudflares nätverk under en tid pendlade mellan normal drift och fel när olika versioner av filen spreds. Cloudflare-bloggen

Denna oscillation gjorde situationen extremt förvirrande internt. Till en början misstänkte Cloudflares team en massiv DDoS-attack eftersom felmönstret inte såg ut som en enkel programkrasch. Även Cloudflares statussida, som ligger utanför deras egen infrastruktur, visade kortvarigt fel - ett sammanträffande som ytterligare spädde på misstankarna om en extern attack. Cloudflare-bloggen+ 1

Först när de insåg att den gemensamma faktorn var bot-funktionsfilen blev bilden klar.

Tidslinje för incidenten

Baserat på Cloudflares postmortem och rapporter från tredje part kan vi sätta ihop en grov tidslinje för den 18 november 2025: Cloudflare-bloggen+2ThousandEyes+2

• 11:05 UTC - En ändring av databasåtkomstkontroll distribueras i ClickHouse.

• 11:20-11:30 UTC - Dåliga versioner av funktionsfilen Bot Management börjar genereras och spridas.

• 11:28 UTC - Första kundpåverkan: förhöjda HTTP 5xx-fel ses på kundtrafik.

• 11:30-11:32 UTC - Externa övervakningsverktyg och automatiserade tester börjar upptäcka intermittenta fel.

• 11:35 UTC - Cloudflare öppnar ett internt incidentanrop; utredning påbörjas.

• ~11:48 UTC - Cloudflare publicerar en statusuppdatering som bekräftar en incident. Skicka igen

• 11:30-13:05 UTC - Team fokuserar på vad som verkar vara försämrat Workers KV-beteende och undersöker flera möjliga orsaker (inklusive attackscenarier).

• 13:05 UTC - Viktig begränsning: Workers KV och Cloudflare Access flyttas för att kringgå kärnproxyn; påverkan minskas. Cloudflare-bloggen

• 14:30 UTC - Grundorsaken identifierad; generering och spridning av dåliga funktionsfiler stoppas. En känd bra konfigurationsfil infogas manuellt och kärnproxyn startas om. Den mesta kärntrafiken återgår till det normala. Cloudflare-bloggen

• 14:40-15:30 UTC - Problem med instrumentpanelen och inloggning kvarstår när Turnstile och eftersläpning av autentiseringsförsök skapar sekundära belastningstoppar. Cloudflare-bloggen

• 17:06 UTC - Felprocenten återgår till baslinjen; Cloudflare förklarar att systemen är helt normala. Cloudflare-bloggen

Ur en användares synvinkel kändes avbrottet värst sent på morgonen till tidig eftermiddag UTC, även om exakta påverkansfönster varierade beroende på region och vilka Cloudflare-produkter varje tjänst var beroende av.

Varför det här avbrottet är så viktigt

Risk för centralisering

Cloudflare är en del av en liten uppsättning centrala leverantörer av internetinfrastruktur, tillsammans med de stora molnplattformarna (AWS, Azure, GCP) och andra stora CDN. När en av dessa aktörer misslyckas är effekterna omfattande och ofta inte uppenbara.

Det här avbrottet:

• Kom inte från ett BGP-routningsmissöde eller en ISP-kabel som klipptes av.

• Kom inte från en illvillig attack (trots inledande misstankar).

• Kom från en enda konfiguration och begränsningsbugg i en intern komponent.

Det är viktigt eftersom det visar hur komplexa, tätt sammankopplade system kan misslyckas katastrofalt även utan extern inblandning. När många organisationer bygger på samma leverantör blir den leverantören de facto en systemviktig del av internet.

"Mjuka" beroenden skadas också

Några av de drabbade tjänsterna använde inte bara Cloudflare som ett dumt CDN. De gjorde det:

• Använder Cloudflare Access för autentisering och nolltrust-åtkomst.

• Använder Workers KV som en del av interna kontrollplaner.

• Förlita sig på Turnstile för bot-resistenta inloggningar. Cloudflare-bloggen+ 1

När dessa produkter inte fungerade var det inte bara webbplatsinnehållet som gick ner - inloggningar, adminfunktioner och interna API:er gick också sönder . Det gör återhämtningen mer komplex: din statussida, incidentverktyg eller administratörsgränssnitt kan också förlita sig på just den leverantör som just misslyckades.

Vad Cloudflare säger att de kommer att ändra

Cloudflares blogg beskriver flera åtgärder som företaget redan vidtar för att minska risken för att något liknande ska inträffa igen: Cloudflare-bloggen

1. Förstärk intag av automatiskt genererade konfigurationsfiler
   Behandla internt genererade konfigurationer med samma skepsis och validering som användartillförd input, inklusive strikt schema- och storlekskontroll före utrullning.

2. Fler globala kill-switchar
   Gör det enklare att snabbt inaktivera problematiska interna moduler (t.ex. Bot Management) i hela nätverket, så att de misslyckas med att öppna istället för att skapa panik i hela proxyvägen.

3. Skydda systemresurser från felstormar
   Se till att kärndumpar, felsökningsmetadata och observerbarhetsverktyg inte kan överväldiga CPU och minne när felen börjar öka.

4. Granska felsituationer i proxykärnans moduler
   Granska systematiskt hur varje intern modul beter sig vid oväntad inmatning eller konfiguration och se till att den gradvis försämras istället för att gå sönder globalt.

5. Förfina utrullningar och isolering
   Även om det inte beskrivs i detalj, tyder incidenten på att Cloudflare sannolikt kommer att ytterligare segmentera hur nya konfigurationer och DB-beteenden sprids, för att minska risken för att en enda dålig förändring påverkar hela flottan.

De framställde också händelsen som ett absolut misslyckande för deras förväntningar på motståndskraft, kallade det "oacceptabelt" och erkände uttryckligen den smärta det orsakade både kunder och vanliga internetanvändare. Cloudflare-bloggen

Lärdomar för infrastruktur- och SRE-team

Även om du inte driver något så enormt som Cloudflare finns det några mycket praktiska design- och driftlektioner i detta avbrott:

Behandla intern konfiguration som otillförlitlig input

Det är lätt att anta att "vår egen" genererade konfiguration alltid är korrekt. Gårdagen visar varför det är farligt:

• Validera alltid konfigurationsfilernas storlek, form och begränsningar innan du använder dem.

• Överväg att först tillämpa konfigurationen på en liten delmängd av trafiken eller noderna, med automatiserad återgång vid avvikelser.

• Håll strikta övre gränser och kretsbrytare kring antal funktioner, förallokering av minne och CPU-användning.

Design för graciöst partiellt misslyckande

En bugg i Bot Management-modulen ska inte kunna orsaka panik i hela proxyvägen:

• Standard för fail-open vs fail-closed i vissa säkerhetslager när alternativet är fullständigt avbrott.

• Bygg tydliga, testade dödsbrytare för icke-kärnfunktioner.

• Se till att kritiska delsystem (autentisering, statussida, incidentverktyg) kan fungera i försämrat läge eller via alternativa vägar.

Observera rätt signaler

Svängningarna mellan "bra konfiguration" och "dålig konfiguration" var femte minut fick signalen att se ut som attacktrafik eller bullrigt externt beteende:

• Se till att du har korrelation per version eller per konfiguration i din observability pipeline.

• Bygg instrumentpaneler som gör konfigurationsändringar visuellt uppenbara ovanpå felgrafer.

• Inkludera starka syntetiska tester från en extern utsiktspunkt, så att du snabbt kan skilja interna fel från nätverks-/vägproblem.

Lägg inte alla ägg i samma infrakorg

För organisationer som använder Cloudflare:

• Överväg multi-CDN-konfigurationer för verkligt verksamhetskritiska egenskaper.

• Undvik att göra din statussida helt beroende av samma leverantör som din primära stack (Cloudflare gör detta, men det uppstod tillfälliga problem med deras statussida igår vilket förvirrade saker ytterligare). Cloudflare-bloggen+ 1

• Tänk två gånger innan du tätt kopplar din autentisering, API-kontrollplan och frontend-leverans till samma leverantör utan reservvägar.

Den större bilden

Bara under de senaste månaderna har vi sett stora avbrott hos Microsoft Azure, Amazon Web Services och nu Cloudflare, som alla tillfälligt har slagit ut stora delar av konsument- och företagstjänster offline. AP News+2TheWashington Post+2

Mönstret är tydligt:

• Internet blir alltmer beroende av en handfull gigantiska infrastrukturleverantörer.

• Avbrotten är ofta självförvållade och beror på komplexa interna förändringar snarare än externa attacker.

• Även leverantörer med SRE-rutiner i världsklass kan fortfarande råka ut för oväntade interaktioner mellan konfiguration, databasbeteende och hårdkodade gränser.

Gårdagens Cloudflare-incident är en skarp påminnelse om att "molnet" inte är magiskt. I grund och botten är det fortfarande programvara som skrivits av människor och som är föremål för samma typer av buggar som alla andra applikationer - bara med storleksordningar fler människor som är beroende av den.

För användarna kommer incidenten mest att bli ihågkommen som "den där morgonen när X och ChatGPT inte gick att ladda".
För ingenjörer kommer den sannolikt att studeras som ett skolboksexempel på hur subtila konfigurationsbuggar i ett centralt distribuerat system kan sprida sig till en global internethändelse.