Cloudflares senaste globala avbrott: Vad gick fel och vad det betyder för din webbplats

Den 5 december 2025 drabbades Cloudflare – en av kärnpelarna i det moderna internet – av ytterligare ett större fel som kort bröt stora bitar på nätet. För webbplatsägare, SRE-team och vanliga användare var det en skarp påminnelse om hur bräcklig vår "alltid-på" internet verkligen är.

Nedan finns en djupdykning i vad som hände, varför det spelar roll och vilka lektioner infrastruktur och applikationsteam kan ta från det.

Snabb recap: Vad hände den 5 december 2025?

På morgonen 5 december 2025Cloudflare upplevde en global servicestörning som orsakade många webbplatser att återvända blanka eller felsidor i flera minuter. Avbrottet påverkade ett brett utbud av stora tjänster, inklusive plattformar som LinkedIn, Zoom, Coinbase, Canva, Groww, BookMyShow och andraberoende på region och peering. AP News+1

Nyhetsrum och övervakningsplatser rapporterade:

• Användare som ser "toma sidor" istället för normalt innehåll när du besöker påverkade webbplatser. Sky News+1

• En spik i 5xx fel och anslutningsproblem på webbplatser och API som förlitar sig på Cloudflares kantnätverk. Sökmotor Journal

• Frågor inte bara med kundtrafik, utan också med Cloudflares egen Dashboard och API, vilket försämrade observerbarhet och kontroll när kunderna behövde dem mest. AP News+1

Även om avbrottet varade bara en kort tid - ungefär 08:47 till 09:13 GMT enligt tidig rapportering - sprängradien var tillräckligt stor för att den kort påverkade kritiska plattformar som Coinbase och Antropics Claude AIoch skickade Cloudflares egna lager om 4–4,5 % i förhandshandel. Reuters+1

Cloudflare har sagt att:

• Händelsen orsakades inte av en cyberattack.

• Den härrör från en Intern förändring av brandväggshantering/bearbetning av förfrågningar Som svar på en nyligen avslöjad React Server Components (RSC) sårbarhet. Reuters+1

Med andra ord: en säkerhetsdriven förändring av Cloudflares brandväggslogik introducerade en bieffekt som tillfälligt gjorde stora delar av sitt nätverk otillgängliga.

Vad exakt bröt?

Ur användarperspektivet fanns det två dominerande symptom:

1. Stora webbplatser returnerade fel eller tomma sidor

   • Ett stort antal webbplatser visade HTTP 5xx feleller helt enkelt tomma/vita sidor utan innehåll. Sky News+1

   • För vissa plattformar, som innebar inloggningssidor som inte laddar, instrumentpaneler som inte gör, eller APIs timing out.

2. Cloudflares egen kontrollplan försämrades

   • och Cloudflare Dashboard och relaterade API påverkades också, begränsade kunders förmåga att ändra konfigurationer eller se vad som hände i realtid. AP News+1

På teknisk nivå pekar tidiga uttalanden från Cloudflare och mediarapporter på en förändring i hur brandväggen bearbetade förfrågningar, introducerad för att mildra en sårbarhet i React Server Components. Den förändringen orsakade oavsiktligt Cloudflares nätverk för att effektivt sluta betjäna trafiken korrekt i flera minuter. Reuters+1

Även en kort störning hos en leverantör som sitter framför så många webbplatser skapar en Cascading misslyckande mönsterFrån:

• Webbläsare retry anslutningar, ökande belastning.

• Beroende backends se spikar, köuppbyggnad eller timeouts.

• Övervakning av verktyg snabbt översvämma on-call ingenjörer med varningar, ofta med ofullständiga eller vilseledande data eftersom observerbarhet stack själv kan också förlita sig på Cloudflare.

Varför detta avbrott står ut: "andra större incident på tre veckor"

Detta var inte en isolerad glitch. Det kom mindre än tre veckor efter en tidigare, mycket större Cloudflare-incident den 18 november 2025.

3.1 Den 18 november 2025 avbrott (kontext)

På 18 november 2025Cloudflare led ett stort avbrott som:

• orsakad utbredd 5xx fel och nedbruten prestanda för många webbplatser globalt.

• Påverkade högprofilerade plattformar inklusive X (tidigare Twitter) och OpenAI / ChatGPTbland annat. Decodo

• spåras tillbaka till en bugg i generationens logik för en Bot Management-filsom påverkade många av Cloudflares nyckeltjänster. Cloudflare blogg+1

Cloudflare publicerade senare en detaljerad post-mortem som förklarade att Bot Management-konfigurationsfilen orsakade kaskadfel över interna system - ett klassiskt fall av ett Enstaka felaktiga konfiguration artefakt Ta ner kritiska trafikvägar. Cloudflare blogg

3.2 5 december vs 18 november: liknande mönster, olika utlösare

Jämför de två:

• 18 november 2025

• TriggerBug in Bot Management funktion fil generation. Cloudflare blogg+1

• EffektBreda 5xx-fel, konfigurationspipelineproblem, global störning.

• 5 december 2025

• TriggerBrandväggshanteringsändringar rullade ut som en mildring för en React Server Components sårbarhet. Reuters+1

• EffektBrief men bred otillgänglighet, tomma sidor, Cloudflare Dashboard/API-problem.

För kunder spelar skillnaden ingen roll: båda incidenterna var klassiska. kontroll-plan-driven avbrott där en konfiguration eller säkerhetsförändring på leverantörsnivå hade systemomfattande konsekvenser.

Ett mönster som går bortom Cloudflare

Cloudflare är inte ensam här. Under de senaste åren har vi sett en rad internetskala avbrott orsakade av konfigurationsfel, programuppdateringar eller säkerhetsbegränsningar hos stora leverantörer:

• Cloudflare, Microsoft Microsoft Microsoft, Amazon Amazon Amazon Amazonoch CrowdStrike har alla haft incidenter som rippade över tusentals beroende tjänster. Reuters+1

• En analys av internet störningar anteckningar dussintals avsevärda globala avbrott under bara första halvan av 2020-taletUnderstryker det växande Koncentrationsrisk förlita sig på en liten uppsättning infrastrukturleverantörer. TrueSolvers

Detta senaste Cloudflare-fel passar in i ett större tema:

Ju mer vi centraliserar säkerhet, DNS, CDN och kant beräkna till en handfull leverantörer, desto mer kan en enda konfigurationsbugg bli en Systemisk risk för hela internet.

Tekniska lektioner från 5 december fel

Från den begränsade offentliga informationen kan vi redan extrahera flera tekniska lektioner som är relevanta för SRE, DevOps och plattformsteam.

5.1 Säkerhetsförändringar behöver samma disciplin som kodutplaceringar

Grundorsaken var en brandvägg begäran-processing förändring Utplacerad som en del av att mildra en React Server Components sårbarhet. Reuters+1

Key takeaways:

• Säkerhetsfixar = produktionsförändringar
  Säkerhetsdrivna konfigurationsuppdateringar måste gå igenom samma utrullning, testning och skyddsräcken som regelbunden funktion ändras. "Det är en säkerhetsplåster" är inte en motivering för att kringgå normala kontroller.

• Staged utrullning & blast radie kontroller
  Varje förändring av det globala brandväggsbeteendet bör vara:

  • Rullas ut till en delmängd av POPs eller kunder först.

  • Skyddad av funktionsflaggor och omedelbara återgångsmekanismer.

  • Övervakad med specifika kanariska mätvärden (t.ex. 5xx-räntor, TTFB, tomma sidkvoter) för att fånga misslyckanden inom några sekunder.

5.2 Kontrollplan robusthet är lika kritisk som dataplan uptime

Det faktum att Cloudflare är Dashboard och API var också försämrade under händelsen är särskilt smärtsamt. AP News+1

För operatörer innebär detta:

• Du behöver out-of-band eller leverantörsoberoende sätt till:

  • Switch DNS.

• Bypass eller inaktivera misslyckande lager (t.ex. tillfälligt går direkt till ursprung).

• Access loggar och mätvärden, även om leverantörens egen UI/API är offline.

Om ditt enda sätt att lösa ett problem beror på samma infrastruktur som för närvarande är trasig, har du förlorat ett kritiskt säkerhetsnät.

5.3 Konfigurationsartefakter kan vara lika farliga som koden

Både November 18 och 5 december incidenter hade samma strukturella mönster:

• Ett konfiguration eller politisk artefakt (Bot Management fil / brandvägg regel beteende)

• Utplacerad genom global automation

• Interagerar dåligt med produktionstrafiken i stor skala. Cloudflare blogg+2Decodo+2

Lektionen: behandla konfiguration med samma rigor som kodFrån:

• Versionskontroll, kodgranskningar och tester.

• Validering mot realistiska trafikreplayer i staging.

• Begränsa blastradien av någon fel konfiguration.

Vad detta innebär för företag som förlitar sig på Cloudflare

De flesta organisationer kan inte bara "sluta använda Cloudflare". Den är djupt integrerad i:

• DNS och anycast routing

• DDoS skydd

• WAF och bot management

• CDN och caching

• Zero-trust access, WARP, Workers, Workers AI och mer. Cloudflare blogg

Men du kan minska effekterna av framtida fel.

6.1 Kartlägg ditt Cloudflare beroende

Först, vet Hur hur hur Du är beroende av Cloudflare:

• Gör ditt DNS Lev helt där?

• Har du avslutat TLS endast på Cloudflare eller ursprung?

• är Kritiska API Allmänt tillgänglig endast via Cloudflare?

• Gör interna team förlitar sig på Cloudflare Tunnel / Access / WARP för att nå känsliga tjänster?

Under avbrottet den 12 juni 2025 noterade Cloudflare att produkter som Arbetare KV, WARP, Access, Gateway, Images, Stream, Workers AI, Turnstile, Zaraz och delar av Dashboard påverkades – en påminnelse om hur många lager som kan knytas till en enda leverantör. Cloudflare blogg

6.2 Plan DNS och CDN failover

För högvärdiga tjänster, överväga:

• Sekundär DNS med en annan leverantör som kan ta över snabbt.

• Multi-CDN eller CDN-bypass strategierOm Cloudflare misslyckas kan du:

  • Punkttrafik direkt till ursprung.

  • Eller flytta trafiken till en backup CDN, även om prestanda är tillfälligt sämre.

Detta kommer sällan gratis (kostnad / komplexitet), men för uppdragskritiska tjänster kan det vara värt motståndskraften.

6.3 Bygg app-nivå motståndskraft

Även när kanten är trasig, kan din app misslyckas mer graciöst:

• Tjäna cachade statiska felsidor Det förklarar situationen istället för tomma svar.

• Bygga klient-side retry logik Det backar, snarare än att hamra en kämpande kant.

• Decouple icke-kritisk funktionalitet (analytiker, tredjepartsskript, tung personalisering) så att de kan inaktiveras snabbt.

6.4 Operationellt: behandla leverantörsavbrott som regelbundna speldagsscenarier

Använd detta och den 18 november avbrott som material för Spel-dagarFrån:

• Hur snabbt kan du upptäcka att problemet är med Cloudflare vs ditt eget ursprung?

• Gör on-call runbooks inkluderar:

• Länkar till Cloudflare Status sida och din leverantör kontaktvägar? Cloudflare Status+1

• Förbättrade steg för att kringgå eller omväga trafik?

• övervakar du externa kontroller Det slog din tjänst utan utan utan passerar genom Cloudflare?

Hur Cloudflare kommer sannolikt att svara

Cloudflare har en lång historia av att publicera detaljerade postmortem för stora incidenter (till exempel 20 juni 2024 och 27 juni 2024 incidenter, liksom 12 juni 2025 och 18 november 2025 Avbrott). Cloudflare blogg+3Cloudflare blogg+3Cloudflare blogg

ss="-me-1 flex h-fulla objekt-center rundad-full px-1 text-[#8F8F]">+3

Baserat på detta mönster kan vi rimligen förvänta oss:

• Ett tekniskt blogginlägg som förklarar:

  • Den exakta brandväggslogiken förändras.

  • Varför sårbarheten för React Server Components uppträdde oväntat.

  • Hur länge påverkan varade i olika regioner.

• En lista över RemediationsTill exempel:

  • Starkare konfigurations validering och testning.

  • Tighter iscensatta utbyggnader och automatiserade rollback triggers.

  • Bättre separation mellan de system som tjänar kundtrafik och de som driver Dashboard och API.

För kunder är den transparensen värdefull – men den tar inte bort behovet av att design för leverantörsfel i sina egna arkitekturer.

Den större bilden: centralisering vs motståndskraft

Den 5 december är en del av en större konversation som branschen redan har:

• Vi har centraliserat enorma mängder Routing, DNS, säkerhet, WAF och content delivery till en handfull leverantörer. TrueSolvers+1

• Varje större incident på Cloudflare, Azure, AWS eller CrowdStrike beter sig nu som en finansiella systemet chockDet tar inte bara ner en webbplats, det tar kortfattat Hela hela digital ekonomi.

För tillsynsmyndigheter och stora företag som väcker frågor om:

• Koncentrationsrisk – i vilken utsträckning bör kritisk infrastruktur tvingas ha flerleverantörsredundans?

• Transparens och ansvarsskyldighet Hur snabbt och tydligt delar leverantörerna rot-orsaksdetaljer?

• Investeringar i motståndskraft - spenderar vi tillräckligt på skyddsräcken vs på frakt nya funktioner?

Sammanfattning

För att slå upp, Cloudflare's senaste stora fel den 5 december 2025 kan sammanfattas som:

• Ett Global men kort avbrott orsakad av en intern brandväggsförädlingsförändring som används som en del av en säkerhetsrespons.

• Synlig för användare som tomma sidor och 5xx fel över stora webbplatser, och nedbrytning av Cloudflare egna Dashboard och API.

• och andra betydande incident på mindre än tre veckor, efter den mycket större November 18, 2025 Bot Management-relaterade avbrott.

• En annan datapunkt i den pågående historien om InfrastrukturkoncentrationsriskDär konfigurationsfel hos några leverantörer kort kan bryta internet för alla.

För företag som förlitar sig på Cloudflare är kärnmeddelandet inte ”panik och migrering”, utan:

Anta att dina leverantörer kommer att misslyckasoch utforma din arkitektur, verksamhet och affärsprocesser så att ett kortlivat fel inte blir en existentiell kris.