Op 18 November 2025 het 'n groot deel van die internet ingestort.
As jy ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase of tallose kleiner webwerwe oopgemaak het, is jy begroet met 'n Cloudflare-handelsmerk 5xx-foutbladsy – of die webwerwe wou glad nie laai nie. Wat aanvanklik gelyk het na nog 'n groot "die internet is stukkend"-oomblik, het iets meer subtiel en, in sommige opsigte, meer kommerwekkend geblyk te wees: 'n selftoegediende fout diep binne Cloudflare se eie infrastruktuur.
Hieronder is 'n gedetailleerde uiteensetting van wat gebeur het tydens gister se Cloudflare-onderbreking (18 November 2025), hoekom dit gebeur het, wie dit geraak het, en watter lesse infrastruktuurspanne daaruit moet leer.
Wat het eintlik gister gebeur?
Op Dinsdag 18 November 2025, rondom laatoggend UTC, het Cloudflare begin om groot volumes HTTP 5xx-bedienerfoute terug te gee vir verkeer wat deur sy netwerk gegaan het. Vir eindgebruikers het dit "Interne Bedienerfout" of "Poortfout"-bladsye beteken wanneer hulle probeer het om toegang tot baie gewilde webwerwe en toepassings te verkry.
Volgens Cloudflare se eie blog na die voorval het die onderbreking:
Begin om kliënt HTTP-verkeer om 11:28 UTC te beïnvloed
Wysverspreide 5xx-foute oor kern-CDN- en sekuriteitsdienste gesien
Groot versagtingsstappe rondom 13:05–14:30 UTC gehad
5xx-foutvolume teen 17:06 UTC na die basislyn teruggebring Die Cloudflare-blog
Cloudflare self het dit beskryf as sy ergste onderbreking sedert 2019, omdat dit nie net een kenmerk of dashboard beïnvloed het nie – dit het die kern-instaanbedieningslaag wat die meerderheid van kliëntverkeer deur sy netwerk lei, ontwrig. Die Cloudflare-blog
Derdeparty-monitering het dit gestaaf. Cisco ThousandEyes het 'n wêreldwye onderbreking gesien wat Cloudflare beïnvloed het, met tyd-uit en 5xx-foute op dienste soos X, OpenAI (ChatGPT) en Anthropic, terwyl netwerkpaaie self gesond gelyk het. Dit het sterk gedui op 'n agterkantdiensfout, nie 'n ISP-vlak- of roeteringsprobleem nie. ThousandEyes
Wie is geraak?
Omdat Cloudflare voor 'n massiewe gedeelte van die internet sit (ongeveer 20% van die web se webwerwe maak staat op Cloudflare vir werkverrigting en sekuriteit), was die ontploffingsradius enorm. AP News+1
Onder die dienste wat as geraak aangemeld is:
ChatGPT / OpenAI
X (voorheen Twitter)
Canva, Shopify, Dropbox, Coinbase
League of Legends en ander spelplatforms
Verskeie openbare vervoer- en regeringswebwerwe, insluitend New Jersey Transit en Frankryk se SNCF-spoorweg digitale stelsels AP News+1
Onderbrekingsopsporingsprogramme soos Downdetector het duisende gelyktydige probleemverslae op die hoogtepunt aangeteken. Reuters het op een stadium ongeveer 5 000 geaffekteerde gebruikers vir X alleen aangemeld, voordat die tellings afgeneem het namate regstellings uitgerol is. Reuters
Vanuit 'n gebruiker se perspektief het dit gemanifesteer as:
Webwerwe wat glad nie laai nie
Aanmeldvloei wat hang of misluk (veral waar Cloudflare Access of Turnstile betrokke was)
API's wat met tussenposes reageer of met 5xx-foute
Dashboards en administrasiepanele wat tyd-uit kry
Met ander woorde: groot dele van die internet het "in duie gestort", al was die oorsaak gekonsentreer in 'n enkele verskaffer se interne stelsels.
Hoe Cloudflare normaalweg werk (in eenvoudige terme)
Om te verstaan waarom hierdie onderbreking so ernstig was, help dit om die rowwe pad van 'n versoek deur Cloudflare se netwerk te ken.
Cloudflare tree op as 'n omgekeerde proxy-CDN en sekuriteitslaag:
Jou blaaier of toepassing koppel aan Cloudflare in plaas van direk aan die oorsprongwebwerf.
Cloudflare beëindig TLS en HTTP aan sy rand.
Versoeke vloei na Cloudflare se kern-proxystelsel, genaamd FL ("Frontline") en sy nuwer generasie FL2.
Daardie kern-instaanbediener:
Pas WAF-reëls (webtoepassingsfirewall) toe
Laat Botbestuurmodelle loop
Hanteer DDoS-beskerming, kasgeheue, uitgang na oorsprong
Routeer verkeer na ander interne produkte soos Workers, R2, Access, ens. Die Cloudflare-blog
In normale werking is hierdie argitektuur hoogs veerkragtig: as een datasentrum 'n probleem het, word verkeer deur ander gelei; konfigurasieveranderinge word versigtig uitgerol; individuele funksies moet op beperkte maniere faal.
Gister se onderbreking was juis sleg omdat die fout binne die gemeenskaplike instaanbedienerpad self was, en dit was styf gekoppel aan 'n konfigurasielêer wat gereeld en outomaties wêreldwyd gestoot word.
Die oorsaak: 'n botbestuurfunksielêer het verkeerd gegaan
Cloudflare se amptelike verduideliking wys op een sleutelskuldige: 'n funksiekonfigurasielêer wat deur hul Botbestuurstelsel gebruik word. Die Cloudflare-blog
Hier is die ketting van gebeure in gewone taal:
Botbestuur gebruik 'n "funksielêer"
Cloudflare se bot-opsporingsmodel maak staat op 'n stel "funksies" – seine oor elke versoek wat gebruik word om te besluit of dit menslik of 'n bot is.
Hierdie funksies word saamgevoeg in 'n konfigurasielêer wat elke paar minute herskep en wêreldwyd uitgerol word, sodat Cloudflare vinnig kan aanpas by nuwe aanvalpatrone. Die Cloudflare-blog
'n Verandering in ClickHouse-navraaggedrag
Die kenmerklêer word gegenereer deur navrae teen 'n ClickHouse-databasis.
Cloudflare het omstreeks 11:05 UTC 'n verandering aangebring om sekuriteit en toestemmings vir verspreide navrae te verbeter – allo
gebruikers toelaat om metadata te sien nie net van 'n standaardskema nie, maar ook van onderliggende r0-tabelle. Die Cloudflare-blog
Die navraag wat die funksielys bou, het nie volgens databasisnaam gefiltreer nie; skielik het dit duplikaatkolomme van beide standaard en r0 begin kry, wat die aantal funksierye effektief verdubbel het.
Die funksielêer het in grootte ontplof
Die Botbestuurmodule het 'n harde limiet op hoeveel funksies dit sal aanvaar (gestel op 200, heelwat bo die ~60 wat normaalweg in gebruik is).
Toe die nuut gegenereerde lêer daardie limiet oorskry het, het die module die limiet bereik en paniekerig geraak as gevolg van 'n onbehandelde fout in Rust-kode wat Result::unwrap() op 'n foutwaarde gebruik het. Die Cloudflare-blog
Kern-instaanbedieningsdienste het 5xx-foute begin teruggee
Omdat Botbestuur in die kern-instaanbedieningspad geïntegreer is, het die paniek as HTTP 5xx-antwoorde vir enige verkeer wat van daardie module afhanklik was, opgeduik.
Op die nuwe FL2-enjin het kliënte eksplisiete 5xx-foute gesien.
Op die ouer FL-enjin het bottellings stilweg na nul gegaan, wat vals positiewe in botblokkeringsreëls kon veroorsaak. Die Cloudflare-blog
Die regtig nare deel: die lêer het aanhou wissel tussen "goed" en "sleg"
Die ClickHouse-kluster is geleidelik opgedateer, en die kenmerklêer is elke vyf minute herskep.
Soms het die navraag op opgedateerde nodusse geloop (wat 'n slegte lêer geproduseer het), soms op nie-opgedateerde nodusse (wat 'n goeie lêer geproduseer het).
Dit het beteken dat Cloudflare se netwerk vir 'n rukkie tussen normale werking en mislukking ossilleer het namate verskillende weergawes van die lêer versprei is. Die Cloudflare-blog
Hierdie ossillasie het die situasie intern uiters verwarrend gemaak. Aanvanklik het Cloudflare se spanne 'n massiewe DDoS-aanval vermoed omdat die foutpatroon nie soos 'n eenvoudige sagteware-ineenstorting gelyk het nie. Selfs die Cloudflare-statusbladsy, wat buite hul eie infrastruktuur aangebied word, het kortliks foute getoon – 'n toeval wat die vermoede van 'n eksterne aanval verder aangevuur het. Die Cloudflare Blog+1
Eers toe hulle besef het dat die gemeenskaplike faktor die bot-funksielêer was, het die prentjie duidelik geword.
Tydlyn van die voorval
Gebaseer op Cloudflare se nadoodse en derdeparty-verslae, kan ons 'n rowwe tydlyn vir 18 November 2025 saamstel: Die Cloudflare Blog+2ThousandEyes+2
11:05 UTC – 'n Verandering in databasistoegangsbeheer word in ClickHouse ontplooi.
11:20–11:30 UTC – Slegte weergawes van die Bot Management-funksielêer begin gegenereer en versprei word.
11:28 UTC – Eerste kliëntimpak: verhoogde HTTP 5xx-foute gesien op kliëntverkeer.
11:30–11:32 UTC – Eksterne moniteringsinstrumente en outomatiese toetse begin intermitterende mislukkings opspoor.
11:35 UTC – Cloudflare maak 'n interne voorvaloproep oop; ondersoek begin.
~11:48 UTC – Cloudflare publiseer 'n statusopdatering wat 'n voorval bevestig. Stuur weer
11:30–13:05 UTC – Spanne fokus op wat lyk na gedegradeerde Werkers KV-gedrag en ondersoek verskeie moontlike oorsake (insluitend aanvalscenario's).
13:05 UTC – Sleutelversagting: Werkers KV en Cloudflare-toegang word verskuif om die kern-instaanbediener te omseil; impak word verminder. Die Cloudflare-blog
14:30 UTC – Worteloorsaak geïdentifiseer; generering en verspreiding van slegte kenmerklêers word gestaak. 'n Bekende-goeie konfigurasielêer word handmatig ingevoeg en die kern-instaanbediener word herbegin. Meeste kernverkeer keer terug na normaal. Die Cloudflare-blog
14:40–15:30 UTC – Dashboard- en aanmeldprobleme bly voortduur terwyl draaihek en agterstand van verifikasiepogings sekondêre laaispykers veroorsaak. Die Cloudflare-blog
17:06 UTC – Foutkoerse keer terug na die basislyn; Cloudflare verklaar stelsels ten volle normaal. Die Cloudflare-blog
Vanuit 'n gebruiker se oogpunt het die onderbreking die ergste gevoel in die laatoggend tot vroeë middag UTC, hoewel die presiese impakvensters per streek en volgens watter Cloudflare-produkte elke diens afhanklik was, verskil het.
Waarom hierdie onderbreking so belangrik is
Sentraliseringsrisiko
Cloudflare is deel van 'n klein stel sentrale internetinfrastruktuurverskaffers, saam met die groot wolkplatforms (AWS, Azure, GCP) en ander groot CDN's. Wanneer een van hierdie spelers faal, is die impak wyd en dikwels nie voor die hand liggend nie.
Hierdie onderbreking:
Het nie ontstaan uit 'n BGP-roeteringsongeluk of 'n ISP-kabelonderbreking nie.
Het nie ontstaan uit 'n kwaadwillige aanval nie (ten spyte van aanvanklike vermoedens).
Het ontstaan uit 'n enkele konfigurasie en beperk die fout in 'n interne komponent.
Dit is belangrik, want dit wys hoe komplekse, styf gekoppelde stelsels katastrofies kan faal, selfs sonder eksterne inmenging. Wanneer baie organisasies op dieselfde verskaffer bou, word daardie verskaffer 'n de facto sistemies belangrike stuk van die internet.
"Sagte" afhanklikhede het ook seergemaak
Sommige van die geaffekteerde dienste het Cloudflare nie net as 'n dom CDN gebruik nie. Hulle was:
Cloudflare Access gebruik vir verifikasie en zero-trust toegang.
Workers KV gebruik as deel van interne beheervlakke.
Vertrou op Turnstile vir bot-bestande aanmeldings. Die Cloudflare Blog+1
Toe daardie produkte misluk het, was dit nie net webwerf-inhoud wat afgegaan het nie – aanmeldings, administrateurfunksies en interne API's het ook gebreek. Dit maak herstel meer kompleks: jou statusbladsy,
insident-gereedskap, of administrateur-UI, kan ook staatmaak op die einste verskaffer wat so pas misluk het.
Wat Cloudflare sê dit sal verander
Cloudflare se blog beskryf verskeie remediërende stappe wat die maatskappy reeds neem om die risiko van enigiets soortgelyks te verminder: Die Cloudflare-blog
Versterk die inname van outomaties gegenereerde konfigurasielêers
Behandel intern gegenereerde konfigurasies met dieselfde skeptisisme en validering as gebruikerverskafde insette, insluitend streng skema- en groottekontrole voor uitrol.
Meer globale doodskakelaars
Maak dit makliker om problematiese interne modules (soos Botbestuur) vinnig oor die netwerk te deaktiveer, sodat hulle misluk om oop te maak in plaas daarvan om die hele instaanbedieningspad te paniek.
Beskerm stelselbronne teen foutstorms
Verseker dat kerndumps, ontfoutingsmetadata en waarneembaarheidsgereedskap nie die SVE en geheue kan oorweldig wanneer foute begin toeneem nie.
Hersien mislukkingsmodusse oor kerninstaanbedieningsmodules
Oudit sistematies hoe elke interne module optree onder onverwagte insette of konfigurasie, en verseker grasieuse agteruitgang in plaas van globale mislukking.
Verfyn uitrol en isolasie
Alhoewel dit nie in groot besonderhede uitgespel word nie, dui die voorval daarop dat Cloudflare waarskynlik verder sal segmenteer hoe nuwe konfigurasies en databasisgedrag versprei, om die kans te verminder dat 'n enkele slegte verandering die hele vloot beïnvloed.
Hulle het die voorval ook as 'n absolute mislukking van hul veerkragtigheidsverwagtinge geraam, dit "onaanvaarbaar" genoem en die pyn wat dit beide kliënte en gewone internetgebruikers veroorsaak het, eksplisiet erken. Die Cloudflare-blog
Lesse vir infrastruktuur- en SRE-spanne
Selfs al gebruik jy nie iets so groot soos Cloudflare nie, is daar 'n paar baie praktiese ontwerp- en operasionele lesse in hierdie onderbreking:
Behandel interne konfigurasie soos onbetroubare insette
Dit is maklik om aan te neem dat "ons eie" gegenereerde konfigurasie altyd korrek is. Gister wys hoekom dit gevaarlik is:
Valideer altyd die grootte, vorm en limiete van konfigurasielêers voordat jy dit toepas.
Oorweeg eers die kanarie-toepassing van konfigurasie op 'n klein deelversameling van verkeer of nodusse, met outomatiese terugrol op afwykings.
Handhaaf streng boonste perke en stroombrekers rondom funksietellings, geheuevoortoewysing en SVE-gebruik.
Ontwerp vir grasieuse gedeeltelike mislukking
Een fout in die Botbestuurmodule behoort nie die hele proxy-pad te kan paniek nie:
Standaard na oopmaak-fout teenoor toemaak-fout in sommige sekuriteitslae wanneer die alternatief 'n volledige onderbreking is.
Bou duidelike, getoetste doodskakelaars vir nie-kernfunksies.
Verseker dat kritieke substelsels (magtiging, statusbladsy, voorvalgereedskap) in gedegradeerde modus of via alternatiewe roetes kan werk.
Neem die regte seine waar
Die ossillasie tussen "goeie konfigurasie" en "slegte konfigurasie" elke vyf minute het die sein laat lyk soos aanvalsverkeer of raserige eksterne gedrag:
Maak seker dat jy per-weergawe of per-konfigurasie korrelasie in jou waarneembaarheidspyplyn het.
Bou dashboards wat konfigurasieveranderinge visueel duidelik maak bo-op foutgrafieke.
Sluit sterk sintetiese toetse vanuit 'n eksterne uitkykpunt in, sodat jy vinnig interne mislukking van netwerk-/padprobleme kan onderskei.
Moenie al jou eiers in een infra-mandjie sit nie
Vir organisasies wat Cloudflare gebruik:
Oorweeg multi-CDN-opstellings vir werklik missie-kritieke eienskappe.
Vermy om jou statusbladsy heeltemal afhanklik te maak van dieselfde verskaffer as jou primêre stapel (Cloudflare doen dit, maar daar was toevallige probleme met hul statusbladsy-gasheer gister wat dinge verder verwar het). Die Cloudflare Blog+1
Dink twee keer voordat jy jou verifikasie, API-beheervlakke en frontend-aflewering styf aan dieselfde verskaffer koppel sonder terugvalpaaie.
Die groter prentjie
In die afgelope paar maande alleen het ons groot onderbrekings by Microsoft Azure, Amazon Web Services en nou Cloudflare gesien, wat almal tydelik groot dele van verbruikers- en ondernemingsdienste vanlyn gesit het. AP News+2The Washington Post+2
Die patroon is duidelik:
Die internet is toenemend afhanklik van 'n handjievol reuse-infrastruktuurverskaffers.
Onderbrekings is dikwels selftoegedien en kom van komplekse interne veranderinge eerder as eksterne aanvalle.
Selfs verskaffers met wêreldklas SRE-praktyke kan steeds gestruikel word deur onverwagte interaksies tussen konfigurasie, databasisgedrag en hardgekodeerde limiete.
Gister se Cloudflare-voorval is 'n duidelike herinnering dat "die wolk" nie magies is nie. Aan die onderkant is dit steeds sagteware wat deur mense geskryf is, onderhewig aan dieselfde klasse foute as enige ander toepassing – net met ordegroottes meer mense wat daarvan afhanklik is.
Vir gebruikers sal die voorval meestal onthou word as "daardie oggend toe X en ChatGPT nie wou laai nie."
Vir ingenieurs sal dit waarskynlik bestudeer word as 'n handboekvoorbeeld van hoe subtiele konfigurasiefoute in 'n kern verspreide stelsel kan uitkring in 'n wêreldwye internetgebeurtenis.
10603 
IT Pro 
