"Cloudflare" pagrindinis lapkričio 18 d. sutrikimas - santrauka

2025 m. lapkričio 18 d. krito didžiulis interneto gabalas.
Jei atsidarėte "ChatGPT", "X" ("Twitter"), "League of Legends", "Shopify", "Coinbase" ar daugybę mažesnių svetainių, jus pasitiko "Cloudflare" ženklu pažymėtas 5xx klaidos puslapis - arba svetainės apskritai neužsikrovė. Tai, kas iš pradžių atrodė kaip dar vienas didelis "internetas sugedo" momentas, pasirodė esąs subtilesnis ir tam tikrais atžvilgiais labiau nerimą keliantis dalykas: "Cloudflare" infrastruktūroje įsivėlusi klaida.

Toliau išsamiai aprašoma, kas nutiko per vakarykštį "Cloudflare" sutrikimą (2025 m. lapkričio 18 d.), kodėl jis įvyko, kam jis turėjo įtakos ir kokias pamokas iš to turėtų pasimokyti infrastruktūros komandos.

Kas iš tikrųjų nutiko vakar?

Antradienį, 2025 m. lapkričio 18 d., apie vėlyvą rytą UTC, "Cloudflare" pradėjo grąžinti didelį kiekį HTTP 5xx serverio klaidų, susijusių su per jos tinklą perduodamu srautu. Galutiniams naudotojams tai reiškė "Internal Server Error" arba "Gateway Error" puslapius, kai jie bandė pasiekti daugelį populiarių svetainių ir programų.

Pasak "Cloudflare" tinklaraščio, paskelbto po incidento, sutrikimas:

• klientų HTTP srautas pradėtas veikti 11:28 UTC

• Pastebėtos plačiai paplitusios 5xx klaidos pagrindinėse CDN ir saugumo paslaugose.

• apie 13:05-14:30 UTC imtasi svarbiausių poveikio mažinimo veiksmų

• Iki 17:06 UTC 5xx klaidų kiekis grįžo į pradinį lygį .

Pati "Cloudflare" šį sutrikimą apibūdino kaip didžiausią nuo 2019 m., nes jis paveikė ne tik vieną funkciją ar prietaisų skydelį - sutriko pagrindinis tarpinio serverio sluoksnis, kuriuo per jos tinklą nukreipiama didžioji dalis klientų srauto. "Cloudflare" tinklaraštis

Trečiųjų šalių stebėsena tai patvirtino. Kompanija "Cisco ThousandEyes" pastebėjo visuotinį sutrikimą, paveikusį "Cloudflare" - tokiose paslaugose kaip X, "OpenAI" (ChatGPT) ir "Anthropic" buvo užfiksuoti laiko trukdžiai ir 5xx klaidos, o patys tinklo keliai atrodė sveiki. Tai aiškiai rodė, kad įvyko galinės paslaugos gedimas, o ne interneto paslaugų teikėjo ar maršruto parinkimo problema. ThousandEyes

Kas nukentėjo?

Kadangi "Cloudflare" yra priešais didžiulę interneto dalį (apie 20 % interneto svetainių priklauso nuo "Cloudflare" našumo ir saugumo), sprogimo spindulys buvo didžiulis. AP News+1

Tarp paslaugų, kurioms, kaip pranešama, buvo padarytas poveikis:

• ChatGPT / OpenAI

• X (buvusi "Twitter")

• "Canva", "Shopify", "Dropbox", "Coinbase".

• League of Legends ir kitos žaidimų platformos

• Įvairios viešojo transporto ir vyriausybinės svetainės, įskaitant "New Jersey Transit" ir Prancūzijos geležinkelių SNCF skaitmenines sistemas AP News+1

Pažeidimų sekimo programos, pavyzdžiui, Downdetector, užfiksavo tūkstančius pranešimų apie vienu metu vykstančius sutrikimus. Vienu metu "Reuters" pranešė apie 5 000 paveiktų naudotojų vien tik X sistemoje, o po to, kai buvo ištaisytos problemos, jų skaičius sumažėjo. Reuters

Vartotojų požiūriu tai pasireiškė taip:

• Svetainės apskritai neužsikrauna.

• prisijungimo srautai stringa arba neveikia (ypač jei buvo naudojami "Cloudflare Access" arba "Turnstile").

• API atsako su pertrūkiais arba su 5xx klaidomis

• neveikia prietaisų skydeliai ir administratoriaus skydeliai

Kitaip tariant, "neveikė" didžiulės interneto dalys, nors pagrindinė priežastis buvo vieno paslaugų teikėjo vidaus sistemose.

Kaip paprastai veikia "Cloudflare" (paprastai)

Norint suprasti, kodėl šis sutrikimas buvo toks didelis, naudinga žinoti apytikslį užklausos kelią per "Cloudflare" tinklą.

"Cloudflare" veikia kaip atvirkštinio tarpinio serverio CDN ir saugumo sluoksnis:

1. Jūsų naršyklė arba programa jungiasi prie "Cloudflare", o ne tiesiogiai prie pradinės svetainės.

2. "Cloudflare" savo krašte užbaigia TLS ir HTTP.

3. Užklausos patenka į "Cloudflare" pagrindinę proxy sistemą, vadinamą FL ("Frontline" ) ir naujesnės kartos FL2.

4. Šis pagrindinis tarpinis serveris:

   • taiko WAF (žiniatinklio programų ugniasienės) taisykles

   • paleidžia botų valdymo modelius

   • tvarko DDoS apsaugą, spartinimą, išėjimą į kilmės šalį

   • nukreipia srautą į kitus vidinius produktus, tokius kaip " Workers", " R2", " Access" ir kt. "Cloudflare" tinklaraštis

Įprastai veikiant ši architektūra yra labai atspari: jei viename duomenų centre kyla problemų, srautas nukreipiamas per kitus; konfigūracijos pakeitimai diegiami atsargiai; atskiros funkcijos turėtų veikti ribotai.

Vakarykštis sutrikimas buvo blogas būtent dėl to, kad gedimas įvyko pačiame bendrajame tarpinio serverio kelyje ir buvo glaudžiai susijęs su konfigūracijos failu, kuris dažnai ir automatiškai siunčiamas visame pasaulyje.

Pagrindinė priežastis: nesąžiningas botų valdymo funkcijos failas

Oficialiame "Cloudflare" paaiškinime nurodomas vienas pagrindinis kaltininkas:
Botų valdymo sistemoje naudojamas funkcijų konfigūracijos failas. "Cloudflare" tinklaraštis

Čia pateikiama paprasta įvykių grandinė:

1. "Bot Management" naudoja "funkcijų failą".

   • "Cloudflare" botų aptikimo modelis remiasi "funkcijų" rinkiniu - signalais apie kiekvieną užklausą, pagal kuriuos sprendžiama, ar tai žmogus, ar botas.

   • Šios funkcijos yra įtrauktos į konfigūracijos failą, kuris atnaujinamas kas kelias minutes ir diegiamas visame pasaulyje, kad "Cloudflare" galėtų greitai prisitaikyti prie naujų atakų modelių. "Cloudflare" tinklaraštis

2. Pasikeitusi "ClickHouse" užklausų elgsena

   • Funkcijų failas generuojamas atliekant užklausas "ClickHouse" duomenų bazei.

   • Apie 11:05 UTC "Cloudflare" atliko pakeitimą, kad pagerintų paskirstytų užklausų saugumą ir leidimus - naudotojai gali matyti metaduomenis ne tik iš numatytoji schemos, bet ir iš pagrindinių r0 lentelių. "Cloudflare" tinklaraštis

   • Užklausa, pagal kurią sudaromas funkcijų sąrašas, nefiltravo pagal duomenų bazės pavadinimą; staiga ji ėmė gauti pasikartojančius stulpelius ir iš numatytosios, ir iš r0, iš esmės padvigubindama funkcijų eilučių skaičių.

3. Funkcijų failo dydis išaugo

   • Botų valdymo modulyje nustatyta griežta riba, kiek funkcijų jis gali priimti (nustatyta 200, t. y. gerokai daugiau nei įprastai naudojamų ~60).

   • Kai naujai sukurtas failas viršijo šią ribą, modulis pasiekė ribą ir supanikavo dėl neapdorotos klaidos "Rust" kode, kuriame buvo naudojama funkcija Result::unwrap() klaidos vertei. "Cloudflare" tinklaraštis

4. Pagrindinės tarpinio serverio paslaugos pradėjo grąžinti 5xx klaidas

   • Kadangi "Bot Management" yra integruotas į pagrindinį tarpinių serverių kelią, panika pasireiškė kaip HTTP 5xx atsakymai bet kokiam srautui, kuris priklausė nuo šio modulio.

   • Naujajame FL2 variklyje klientai matė aiškias 5xx klaidas.

   • Senesniame FL variklyje botų balai tyliai tapo lygūs nuliui, todėl botų blokavimo taisyklėse galėjo atsirasti klaidingų teigiamų rezultatų. "Cloudflare" tinklaraštis

5. Tikrai nemaloni dalis: failas vis persijungdavo iš "gero" į "blogą".

   • ClickHouse klasteris buvo palaipsniui atnaujinamas, o funkcijų failas buvo atkuriamas kas penkias minutes.

   • Kartais užklausa vykdavo atnaujintuose mazguose (gaudavo blogą failą), kartais - neatnaujintuose mazguose (gaudavo gerą failą).

   • Tai reiškė, kad kurį laiką "Cloudflare" tinklas svyravo tarp normalaus veikimo ir gedimo, nes buvo platinamos skirtingos failo versijos. "Cloudflare" tinklaraštis

Dėl šio svyravimo situacija viduje tapo labai paini. Iš pradžių "Cloudflare" komandos įtarė masinę DDoS ataką, nes klaidų modelis neatrodė panašus į paprastą programinės įrangos gedimą. Net "Cloudflare" būsenos puslapyje, kuris talpinamas ne jų pačių infrastruktūroje, trumpam pasirodė klaidų - šis sutapimas dar labiau pakurstė įtarimus dėl išorinės atakos. "Cloudflare" tinklaraštis+1

Tik supratus, kad bendras veiksnys yra boto funkcijos failas, vaizdas tapo aiškus.

Incidento laiko juosta

Remdamiesi "Cloudflare" atliktu poataskaitiniu tyrimu ir trečiųjų šalių ataskaitomis, galime sudaryti apytikslę 2025 m. lapkričio 18 d. įvykio laiko juostą: "Cloudflare" tinklaraštis+2tūkstančiai akių+2

• 11:05 UTC - "ClickHouse" įdiegiamas prieigos prie duomenų bazės kontrolės pakeitimas.

• 11:20-11:30 UTC - pradedamos generuoti ir platinti blogos "Bot Management" funkcijos failo versijos.

• 11:28 UTC - Pirmasis poveikis klientams: klientų sraute pastebimos padidėjusios HTTP 5xx klaidos.

• 11:30-11:32 UTC - išorinės stebėjimo priemonės ir automatiniai testai pradeda fiksuoti nutrūkstamus gedimus.

• 11:35 UTC - "Cloudflare" pradeda vidinį incidentą; pradedamas tyrimas.

• ~11:48 UTC - "Cloudflare" paskelbia atnaujintą būsenos pranešimą, patvirtinantį incidentą. Pakartotinis siuntimas

• 11:30-13:05 UTC - komandos sutelkia dėmesį į tai, kas atrodo kaip pablogėjusi "Workers KV" elgsena, ir tiria įvairias galimas priežastis (įskaitant atakų scenarijus).

• 13:05 UTC - Pagrindiniai padarinių sušvelninimo veiksmai: "Workers KV" ir "Cloudflare Access" perkeliami taip, kad apeitų pagrindinį tarpinį serverį; poveikis sumažėja. "Cloudflare" tinklaraštis

• 14:30 UTC - Nustatyta pagrindinė priežastis; blogų funkcijų failų generavimas ir platinimas sustabdytas. Rankiniu būdu įterpiamas žinomas geras konfigūracijos failas ir iš naujo paleidžiamas pagrindinis tarpinis serveris. Didžioji dalis pagrindinio proxy serverio duomenų srauto grįžta į įprastas vėžes. "Cloudflare" tinklaraštis

• 14:40-15:30 UTC - Išlieka prietaisų skydelio ir prisijungimo problemos, nes dėl "Turnstile" ir atsilikusių autentifikavimo bandymų susidaro antriniai apkrovos šuoliai. "Cloudflare" tinklaraštis

• 17:06 UTC - Klaidų lygis grįžta į pradinį lygį; "Cloudflare" skelbia, kad sistemos veikia visiškai normaliai. "Cloudflare" tinklaraštis

Vartotojų požiūriu, sutrikimai buvo didžiausi nuo vėlyvo ryto iki ankstyvos popietės UTC, nors tikslūs poveikio langai skyrėsi priklausomai nuo regiono ir nuo to, nuo kokių "Cloudflare" produktų priklausė kiekviena paslauga.

Kodėl šis sutrikimas toks svarbus

Centralizacijos rizika

"Cloudflare" priklauso nedideliam centrinių interneto infrastruktūros teikėjų rinkiniui, kartu su pagrindinėmis debesijos platformomis (AWS, "Azure", GCP) ir kitais dideliais CDN. Kai sutrinka vieno iš šių dalyvių veikla, poveikis būna platus ir dažnai neakivaizdus.

Šis sutrikimas:

• Neatsitiko dėl BGP maršruto parinkimo nesklandumų ar interneto paslaugų teikėjo kabelio nutrūkimo.

• Nebuvo piktavališkos atakos (nepaisant pradinių įtarimų).

• Įvyko dėl vienos konfigūracijos ir apribojimų klaidos vidiniame komponente.

Tai svarbu, nes parodo, kaip sudėtingos, glaudžiai tarpusavyje susietos sistemos gali katastrofiškai sugesti net ir be išorinio įsikišimo. Kai daug organizacijų remiasi tuo pačiu paslaugų teikėju, tas paslaugų teikėjas tampa de facto sistemiškai svarbia interneto dalimi.

"Minkštos" priklausomybės taip pat kenkia

Kai kurios nukentėjusios paslaugos naudojosi "Cloudflare" ne tik kaip nebyliu CDN. Jos buvo:

• Naudojo "Cloudflare Access" autentifikavimui ir nulinio pasitikėjimo prieigai.

• Naudojo "Workers KV" kaip vidinių kontrolės planų dalį.

• Pasikliaudamos " Turnstile" botams atspariems prisijungimams. "Cloudflare" tinklaraštis+1

Sugedus šiems produktams, sutriko ne tik svetainės turinys - neveikė ir prisijungimai, administratoriaus funkcijos bei vidinės API. Dėl to atkūrimas tampa sudėtingesnis: jūsų būsenos puslapis, incidentų priemonės ar administratoriaus vartotojo sąsaja taip pat gali priklausyti nuo to paties teikėjo, kuris ką tik sugedo.

Ką "Cloudflare" sako, kad pakeis

"Cloudflare" tinklaraštyje aprašyti keli taisomieji veiksmai, kurių bendrovė jau imasi, kad sumažintų riziką, jog kas nors panašaus pasikartos: "Cloudflare" tinklaraštis

1. Sugriežtinti automatiškai generuojamų konfigūracijos failų priėmimą
   Į viduje sukurtus konfigūracijos failus žiūrėkite taip pat skeptiškai ir tikrinkite juos taip pat, kaip ir naudotojo pateiktą įvestį, įskaitant griežtą schemos ir dydžio tikrinimą prieš paleidžiant.

2. Daugiau visuotinių išjungimo jungiklių
   Lengviau greitai išjungti probleminius vidinius modulius (pvz., "Bot Management") visame tinkle, kad jie nepavyktų atidaryti, o ne sukelti paniką visame tarpinio serverio kelyje.

3. Apsaugokite sistemos išteklius nuo klaidų audrų
   Užtikrinkite, kad branduolio ištrynimai, derinimo metaduomenys ir stebėjimo įrankiai negalėtų perkrauti procesoriaus ir atminties, kai klaidų padaugėja.

4. Peržiūrėkite pagrindinių tarpinių serverių modulių gedimų režimus
   Sistemingai tikrinkite, kaip kiekvienas vidinis modulis elgiasi esant netikėtiems įvesties ar konfigūracijos parametrams, ir užtikrinkite, kad būtų užtikrintas grakštus pablogėjimas, o ne visuotinis gedimas.

5. Tobulinkite diegimą ir izoliavimą
   Nors incidentas nėra labai išsamiai aprašytas, tačiau tai rodo, kad "Cloudflare" tikriausiai dar labiau suskirstys, kaip plinta naujos konfigūracijos ir DB elgsena, kad sumažintų tikimybę, jog vienas blogas pakeitimas paveiks visą parką.

Be to, jie incidentą įvardijo kaip absoliučią savo atsparumo lūkesčių nesėkmę, pavadino jį "nepriimtinu" ir aiškiai pripažino, kad jis sukėlė skausmo ir klientams, ir paprastiems interneto naudotojams. "Cloudflare" tinklaraštis

Pamokos infrastruktūros ir SRE komandoms

Net jei nevaldote tokio didžiulio objekto kaip "Cloudflare", iš šio sutrikimo galima pasimokyti praktinių projektavimo ir veiklos pamokų:

Su vidine konfigūracija elkitės kaip su nepatikima įvestimi

Lengva manyti, kad "mūsų pačių" sugeneruota konfigūracija visada teisinga. Vakarykštė diena parodė, kodėl tai pavojinga:

• Visada patikrinkite konfigūracijos failų dydį, formą ir ribas prieš juos taikydami.

• Apsvarstykite galimybę pirmiausia taikyti konfigūraciją nedideliam duomenų srauto ar mazgų poaibiui, o esant anomalijoms ją automatiškai atšaukti.

• Laikykitės griežtų viršutinių ribų ir ribotuvų, susijusių su funkcijų skaičiumi, išankstiniu atminties paskirstymu ir procesoriaus naudojimu.

Suprojektuokite grakštų dalinį gedimą

Dėl vienos "Bot Management" modulio klaidos neturėtų kilti panika visame tarpinio serverio kelyje:

• Kai kuriuose saugumo lygmenyse, kai alternatyva yra visiškas sutrikimas, pagal nutylėjimą pasirinkite " fail-open" ir "fail-closed".

• Sukurkite aiškius, išbandytus nepagrindinių funkcijų išjungimo jungiklius.

• Užtikrinkite, kad kritinės svarbos posistemės (autentifikavimo, būsenos puslapio, incidentų įrankių) galėtų veikti pablogėjusiu režimu arba alternatyviais keliais.

Stebėkite tinkamus signalus

Dėl kas penkias minutes vykstančių svyravimų tarp "geros konfigūracijos" ir "blogos konfigūracijos" signalas atrodė kaip atakų srautas arba triukšmingas išorinis elgesys:

• Užtikrinkite, kad jūsų stebėjimo vamzdyne būtų koreliacija pagal versiją arba konfigūraciją.

• Sukurkite prietaisų skydelius, kuriuose konfigūracijos pokyčiai vizualiai matomi ant klaidų grafikų.

• Įtraukite stiprius sintetinius testus iš išorinio stebėjimo taško, kad galėtumėte greitai atskirti vidines klaidas nuo tinklo / kelio problemų.

Nedėkite visų kiaušinių į vieną infrastruktūros krepšelį

Organizacijoms, naudojančioms "Cloudflare":

• apsvarstykite kelių CDN nustatymus, jei tai iš tikrųjų kritinės svarbos savybės.

• Venkite, kad jūsų būsenos puslapis būtų visiškai priklausomas nuo to paties tiekėjo, kaip ir jūsų pagrindinis stekas ("Cloudflare" tai daro, tačiau vakar atsitiktinai kilo problemų dėl jų būsenos puslapio prieglobos, kurios dar labiau viską supainiojo). "Cloudflare" tinklaraštis+1

• Dukart pagalvokite prieš tvirtai susiedami autentifikavimo, API valdymo plokštumų ir priekinės dalies pristatymą su tuo pačiu tiekėju be atsarginių kelių.

Platesnis vaizdas

Vien per pastaruosius kelis mėnesius patyrėme didelių "Microsoft Azure", "Amazon Web Services", o dabar ir "Cloudflare" sutrikimų, dėl kurių laikinai neveikė didelės vartotojų ir įmonių paslaugų dalys. AP News+2TheWashington Post+2

Dėsningumas aiškus:

• Internetas tampa vis labiau priklausomas nuo keleto milžiniškų infrastruktūros paslaugų teikėjų.

• Dažnai sutrikimai įvyksta dėl pačių paslaugų teikėjų kaltės, dėl sudėtingų vidinių pokyčių, o ne dėl išorinių atakų.

• Net ir pasaulinio lygio SRE praktiką taikantys paslaugų teikėjai vis dar gali suklupti dėl netikėtos konfigūracijos, duomenų bazių elgsenos ir kietai užkoduotų apribojimų sąveikos.

Vakarykštis "Cloudflare" incidentas - ryškus priminimas, kad "debesis" nėra stebuklingas. Iš esmės tai tebėra žmonių parašyta programinė įranga, kuriai būdingos tos pačios klasės klaidos, kaip ir bet kuriai kitai programai, tik nuo jos priklauso daug kartų daugiau žmonių.

Naudotojai šį incidentą dažniausiai prisimins kaip "tą rytą, kai "X" ir "ChatGPT" nepavyko įkelti".
Inžinieriai jį tikriausiai nagrinės kaip vadovėlinį pavyzdį, kaip subtilios konfigūracijos klaidos pagrindinėje paskirstytosios sistemos dalyje gali virsti pasauliniu interneto įvykiu.