Glavni izpad Cloudflare 18. novembra - povzetek

18. novembra 2025 se je zrušil velik del interneta.
Če ste odprli ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase ali nešteto manjših spletnih mest, vas je pričakala stran z napako 5xx z oznako Cloudflare - ali pa se spletna mesta sploh niso naložila. Kar je bilo sprva videti kot še en velik "internet je pokvarjen", se je izkazalo za nekaj bolj subtilnega in v nekaterih pogledih bolj zaskrbljujočega: napaka, ki si jo je Cloudflare sam povzročil globoko v svoji infrastrukturi.

V nadaljevanju podrobno predstavljamo, kaj se je zgodilo med včerajšnjim izpadom podjetja Cloudflare (18. novembra 2025), zakaj se je zgodil, koga je prizadel in kakšne lekcije bi si morale infrastrukturne ekipe vzeti iz tega.

Kaj se je dejansko zgodilo včeraj?

V torek, 18. novembra 2025, okoli poznih jutranjih ur po UTC, je podjetje Cloudflare začelo vračati velike količine napak strežnika HTTP 5xx za promet, ki je potekal skozi njegovo omrežje. Za končne uporabnike je to pomenilo strani "Internal Server Error" ali "Gateway Error", ko so poskušali dostopati do številnih priljubljenih spletnih mest in aplikacij.

Po navedbah spletnega dnevnika podjetja Cloudflare po incidentu je bil izpad:

• Na promet HTTP strank je začel vplivati ob 11:28 UTC

• Pri osrednjih storitvah CDN in varnostnih storitvah so se pojavljale razširjene napake 5xx.

• okoli 13:05-14:30 UTC so bili izvedeni pomembni ukrepi za ublažitev posledic

• Do 17:06 UTC se je obseg napak 5xx vrnil na izhodiščno raven .

Sam Cloudflare je izpad opisal kot najhujši izpad po letu 2019, saj ni vplival le na eno funkcijo ali nadzorno ploščo, temveč je prekinil delovanje osrednjega posredniškega sloja, ki usmerja večino prometa strank prek njegovega omrežja. Blog Cloudflare

Spremljanje tretjih oseb je to potrdilo. Cisco ThousandEyes je opazil globalni izpad, ki je prizadel Cloudflare, s časovnimi izpadi in napakami 5xx v storitvah, kot so X, OpenAI (ChatGPT) in Anthropic, medtem ko so bile same omrežne poti videti zdrave. To je jasno kazalo na odpoved zaledne storitve in ne na napako na ravni ponudnika internetnih storitev ali usmerjanja. ThousandEyes

Kdo je bil prizadet?

Ker se Cloudflare nahaja pred ogromnim delom interneta (približno 20 % spletnih strani se zanaša na Cloudflare za učinkovitost in varnost), je bil radij udara ogromen. AP News+1

Med storitvami, za katere so poročali, da so bile prizadete:

• ChatGPT / OpenAI

• X (nekdanji Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends in druge igralne platforme

• različna spletna mesta javnega prevoza in vladnih služb, vključno z digitalnimi sistemi New Jersey Transit in francoskih železnic SNCF AP News+1

Naprave za spremljanje izpadov, kot je Downdetector, so na vrhuncu zabeležile na tisoče hkratnih poročil o težavah. Agencija Reuters je v nekem trenutku poročala o približno 5000 prizadetih uporabnikih samo za X, nato pa se je število zmanjšalo, ko so se odpravljali popravki. Reuters

Z vidika uporabnika se je to pokazalo kot:

• spletna mesta se sploh ne nalagajo.

• se prijavni tokovi zaustavljajo ali so neuspešni (zlasti če sta bila vključena Cloudflare Access ali Turnstile).

• API-ji se odzivajo občasno ali z napakami 5xx

• nadzorne plošče in upraviteljske plošče so prenehale delovati.

Z drugimi besedami: velik del interneta se je "počutil neodziven", čeprav je bil glavni vzrok skoncentriran v notranjih sistemih enega samega ponudnika.

Kako Cloudflare običajno deluje (poenostavljeno)

Da bi razumeli, zakaj je bil ta izpad tako hud, je treba poznati grobo pot zahteve skozi omrežje Cloudflare.

Cloudflare deluje kot reverzni posrednik CDN in varnostna plast:

1. Vaš brskalnik ali aplikacija se poveže z družbo Cloudflare namesto neposredno z izvornim spletnim mestom.

2. Cloudflare na svojem robu zaključi protokola TLS in HTTP.

3. Zahtevki se stekajo v Cloudflarov osrednji sistem proxy, imenovan FL ("Frontline" ), in njegovo novejšo generacijo FL2.

4. Ta osrednji proxy strežnik:

   • uporablja pravila WAF (požarni zid za spletne aplikacije)

   • izvaja modele za upravljanje botov

   • skrbi za zaščito pred napadi DDoS, predpomnilnik in izhod do izvora

   • usmerja promet v druge notranje izdelke, kot so Workers, R2, Access itd. Blog podjetja Cloudflare

Pri običajnem delovanju je ta arhitektura zelo odporna: če ima en podatkovni center težave, se promet usmerja prek drugih; spremembe konfiguracije se skrbno uvajajo; posamezne funkcije naj bi odpovedale na zadržane načine.

Včerajšnji izpad je bil slab ravno zato, ker je bila napaka znotraj same skupne poti posrednika in je bila tesno povezana s konfiguracijsko datoteko, ki se pogosto in samodejno prenaša po vsem svetu.

Glavni vzrok: datoteka funkcije za upravljanje botov, ki se je ponesrečila

Uradna razlaga podjetja Cloudflare kaže na enega ključnega krivca:
konfiguracijska datoteka funkcije, ki jo uporablja njihov sistem za upravljanje botov. Blog podjetja Cloudflare

Tukaj je veriga dogodkov v preprostem jeziku:

1. Upravljanje botov uporablja "datoteko funkcij".

   • Cloudflarov model za odkrivanje botov temelji na nizu "funkcij" - signalov o vsaki zahtevi, na podlagi katerih se odloči, ali gre za človeka ali bota.

   • Te funkcije so zbrane v konfiguracijski datoteki, ki se obnovi vsakih nekaj minut in se razširi po vsem svetu, tako da se lahko Cloudflare hitro prilagodi novim vzorcem napadov. Blog podjetja Cloudflare

2. Sprememba v obnašanju poizvedb ClickHouse

   • Datoteka s funkcijami se ustvarja s poizvedbami v podatkovni zbirki ClickHouse.

   • Podjetje Cloudflare je okoli 11:05 UTC izvedlo spremembo za izboljšanje varnosti in dovoljenj za porazdeljene poizvedbe - uporabnikom je omogočilo prikaz metapodatkov ne le iz privzete sheme, temveč tudi iz osnovnih tabel r0. Blog podjetja Cloudflare

   • Poizvedba, ki sestavlja seznam funkcij, ni filtrirala po imenu zbirke podatkov; nenadoma je začela dobivati podvojene stolpce iz privzete sheme in r0, kar je dejansko podvojilo število vrstic funkcij.

3. Velikost datoteke z značilnostmi se je povečala

   • Modul za upravljanje botov ima trdno omejitev, koliko funkcij lahko sprejme (nastavljena je na 200, kar je precej več od običajno uporabljenih ~60).

   • Ko je novo ustvarjena datoteka presegla to omejitev, je modul zaradi neobdelane napake v kodi Rust, ki je uporabila funkcijo Result::unwrap() na vrednosti napake, naletel na omejitev in začel paničariti. Blog Cloudflare

4. Osrednje storitve posredniškega strežnika so začele vračati napake 5xx

   • Ker je upravljanje botov vključeno v osrednjo proxy pot, se je panika pojavila kot odgovori HTTP 5xx za ves promet, ki je bil odvisen od tega modula.

   • Na novem motorju FL2 so stranke videle eksplicitne napake 5xx.

   • Na starejšem motorju FL so ocene botov tiho padle na nič, kar je lahko povzročilo lažno pozitivne rezultate v pravilih za blokiranje botov. Blog podjetja Cloudflare

5. Resnično neprijeten del: datoteka je ves čas preklapljala med "dobro" in "slabo".

   • Grozd ClickHouse se je postopoma posodabljal, datoteka z značilnostmi pa se je obnavljala vsakih pet minut.

   • Včasih se je poizvedba izvajala na posodobljenih vozliščih (nastala je slaba datoteka), včasih na neposodobljenih vozliščih (nastala je dobra datoteka).

   • To je pomenilo, da je omrežje Cloudflare nekaj časa nihalo med normalnim delovanjem in odpovedjo, saj so se širile različne različice datoteke. Blog podjetja Cloudflare

Zaradi tega nihanja so bile razmere znotraj podjetja zelo zmedene. Ekipe podjetja Cloudflare so najprej posumile na množičen napad DDoS, saj vzorec napake ni bil videti kot preprosta okvara programske opreme. Celo na strani stanja podjetja Cloudflare, ki je nameščena zunaj njihove lastne infrastrukture, so se za kratek čas pojavile napake - naključje, ki je še dodatno okrepilo sum o zunanjem napadu. Blog+ 1 podjetja Cloudflare

Šele ko so ugotovili, da je skupni dejavnik datoteka z značilnostmi bota, je slika postala jasna.

Časovni potek incidenta

Na podlagi obdukcije družbe Cloudflare in poročil tretjih oseb lahko sestavimo grobo časovnico za 18. november 2025: Blog Cloudflare+2ThousandEyes+2

• 11:05 UTC - v podjetju ClickHouse je bila uvedena sprememba nadzora dostopa do podatkovne zbirke.

• 11:20-11:30 UTC - začnejo se ustvarjati in razširjati slabe različice datoteke funkcije Bot Management.

• 11:28 UTC - Prvi vpliv na stranko: v prometu stranke se pojavijo povišane napake HTTP 5xx.

• 11:30-11:32 UTC - Zunanja orodja za spremljanje in samodejni testi začnejo zaznavati občasne napake.

• 11:35 UTC - Podjetje Cloudflare sproži interni klic o incidentu; začne se preiskava.

• ~11:48 UTC - Cloudflare objavi posodobitev stanja, ki potrjuje incident. Ponovno pošljite

• 11:30-13:05 UTC - Ekipe se osredotočijo na to, kar se zdi poslabšano obnašanje delavcev KV, in raziščejo več možnih vzrokov (vključno s scenariji napada).

• 13:05 UTC - ključna ublažitev: Workers KV in Cloudflare Access sta preusmerjena tako, da obideta osrednji proxy; vpliv je zmanjšan. Blog podjetja Cloudflare

• 14:30 UTC - Korenski vzrok je ugotovljen; generiranje in širjenje datotek s slabimi značilnostmi je ustavljeno. Ročno se vstavi znana dobra konfiguracijska datoteka in ponovno se zažene osrednji posrednik. Večina prometa v jedru se vrne v normalno stanje. Blog Cloudflare

• 14:40-15:30 UTC - Težave z nadzorno ploščo in prijavo ostajajo, saj Turnstile in zaostanek poskusov avtentikacije povzročata sekundarne skoke obremenitve. Blog Cloudflare

• 17:06 UTC - Število napak se vrne na izhodiščno raven; Cloudflare razglasi, da so sistemi popolnoma normalni. Blog Cloudflare

Z vidika uporabnikov je bil izpad najhujši v poznih jutranjih in zgodnjih popoldanskih urah po UTC, čeprav so se natančna obdobja vpliva razlikovala glede na regijo in glede na to, od katerih izdelkov Cloudflare je bila posamezna storitev odvisna.

Zakaj je ta izpad tako pomemben

Tveganje centralizacije

Cloudflare je del majhnega nabora osrednjih ponudnikov internetne infrastrukture, poleg glavnih platform v oblaku (AWS, Azure, GCP) in drugih velikih CDN. Kadar eden od teh akterjev odpove, je vpliv obsežen in pogosto ni očiten.

Ta izpad:

• ni bil posledica napake pri usmerjanju BGP ali prekinitve kabla ponudnika internetnih storitev.

• Ni bil posledica zlonamernega napada (kljub začetnim sumom).

• Nastal je zaradi napake v eni sami konfiguraciji in omejitev v notranji komponenti.

To je pomembno, ker kaže, kako lahko zapleteni, tesno povezani sistemi katastrofalno odpovedo tudi brez zunanjega vmešavanja. Ko veliko organizacij gradi na istem ponudniku, ta ponudnik postane de facto sistemsko pomemben del interneta.

Tudi "mehke" odvisnosti škodijo

Nekatere od prizadetih storitev niso uporabljale Cloudflareja le kot nemega CDN. Bile so:

• uporabljale storitev Cloudflare Access za preverjanje pristnosti in dostop brez zaupanja.

• Uporabljale so Workers KV kot del notranjih kontrolnih ravnin.

• se zanašale na Turnstile za prijave, odporne proti botom. Blog+ 1 podjetja Cloudflare

Ko so ti izdelki odpovedali, se ni pokvarila le vsebina spletnega mesta - pokvarili so se tudi prijave, upraviteljske funkcije in notranji vmesniki API. Zaradi tega je okrevanje bolj zapleteno: vaša statusna stran, orodja za incidente ali uporabniški vmesnik upravitelja se lahko zanašajo tudi na ponudnika, ki je pravkar odpovedal.

Kaj bo po besedah podjetja Cloudflare spremenil

V blogu podjetja Cloudflare je opisanih več popravnih ukrepov, ki jih podjetje že izvaja, da bi zmanjšalo tveganje, da se kaj podobnega ponovi: Blog podjetja Cloudflare

1. Zaostritev vnosa samodejno generiranih konfiguracijskih datotek
   Interno ustvarjene konfiguracijske datoteke obravnavajte enako skeptično in jih potrjujte kot vhodne podatke, ki jih posreduje uporabnik, vključno s strogim preverjanjem sheme in velikosti pred uvedbo.

2. Več globalnih izključitvenih stikal
   Olajšajte hitro onemogočanje problematičnih notranjih modulov (kot je upravljanje botov) v celotnem omrežju, tako da se ne bodo odprli, namesto da bi povzročili paniko na celotni poti posrednika.

3. Zaščita sistemskih virov pred napakami
   Zagotovite, da izpisi jedra, metapodatki za odpravljanje napak in orodja za opazovanje ne morejo preobremeniti procesorja in pomnilnika, ko se napake začnejo množiti.

4. Preglejte načine napak v osrednjih proxy modulih
   Sistematično preverjajte, kako se vsak notranji modul obnaša ob nepričakovanem vhodu ali konfiguraciji, in zagotovite postopno degradacijo namesto globalnega izpada.

5. Izboljšajte uvajanje in izolacijo
   Čeprav incident ni podrobno opisan, pa kaže, da bo družba Cloudflare verjetno še bolj razčlenila način širjenja novih konfiguracij in obnašanja DB, da bi zmanjšala možnost, da ena sama slaba sprememba vpliva na celotno floto.

Prav tako so incident opredelili kot popoln neuspeh svojih pričakovanj glede odpornosti, ga označili za "nesprejemljivega" in izrecno priznali bolečino, ki jo je povzročil strankam in navadnim uporabnikom interneta. Blog podjetja Cloudflare

Lekcije za ekipe za infrastrukturo in SRE

Tudi če ne upravljate nečesa tako velikega, kot je Cloudflare, je v tem izpadu nekaj zelo praktičnih spoznanj o zasnovi in delovanju:

Notranjo konfiguracijo obravnavajte kot nezaupljiv vhodni podatek.

Enostavno je domnevati, da je "naša" generirana konfiguracija vedno pravilna. Včerajšnji dan je pokazal, zakaj je to nevarno:

• Vedno preverite velikost, obliko in omejitve konfiguracijskih datotek, preden jih uporabite.

• Razmislite o kanarskem načinu uporabe konfiguracije najprej za majhno podskupino prometa ali vozlišč z avtomatiziranim povratkom ob nepravilnostih.

• Ohranite stroge zgornje meje in varovala za število funkcij, predhodno dodeljevanje pomnilnika in uporabo procesorja.

Načrtovanje za prijazno delno odpoved

Ena napaka v modulu za upravljanje botov ne bi smela povzročiti panike na celotni poti posrednika:

• Privzeta možnost fail-open proti fail-closed na nekaterih varnostnih ravneh, kadar je alternativa popoln izpad.

• Vzpostavite jasna, preizkušena stikala za izklop za funkcije, ki niso ključne.

• Zagotovite, da lahko kritični podsistemi (avtentikacija, statusna stran, orodja za incidente) delujejo v poslabšanem načinu ali prek nadomestnih poti.

Opazujte prave signale

Zaradi nihanja med "dobro konfiguracijo" in "slabo konfiguracijo" vsakih pet minut je bil signal videti kot napadalni promet ali hrupno zunanje vedenje:

• Prepričajte se, da imate v svojem postopku opazovanja korelacijo na različico ali na konfiguracijo.

• Ustvarite nadzorne plošče, na katerih bodo spremembe konfiguracije vizualno očitne na vrhu grafov napak.

• Vključite močne sintetične teste z zunanjega zornega kota, da lahko hitro ločite notranjo napako od težav z omrežjem/potjo.

Ne dajte vseh jajc v eno košarico infrastrukture

Za organizacije, ki uporabljajo Cloudflare:

• Razmislite o nastavitvah z več CDN za resnično kritične lastnosti.

• Izogibajte se popolni odvisnosti statusne strani od istega ponudnika, kot je vaš primarni sklad (Cloudflare to počne, vendar je včeraj prišlo do naključnih težav z gostiteljem njihove statusne strani, kar je stvari še dodatno zmedlo). BlogCloudflare+1

• Dvakrat premislite, preden tesno povežete avtentikacijo, nadzorne ravni API in dostavo sprednjega dela z istim ponudnikom brez rezervnih poti.

Večja slika

Samo v zadnjih nekaj mesecih smo bili priča velikim izpadom v Microsoft Azure, Amazon Web Services in zdaj Cloudflare, zaradi katerih so bili začasno izključeni veliki deli storitev za potrošnike in podjetja. AP News+2TheWashington Post+2

Vzorec je jasen:

• Internet je vse bolj odvisen od peščice velikih ponudnikov infrastrukture.

• Za izpade si pogosto krivijo sami, saj so posledica zapletenih notranjih sprememb in ne zunanjih napadov.

• Celo ponudniki z vrhunskimi praksami SRE se lahko še vedno znajdejo v težavah zaradi nepričakovanih interakcij med konfiguracijo, obnašanjem podatkovnih zbirk in trdno zakodiranimi omejitvami.

Včerajšnji incident podjetja Cloudflare je jasen opomnik, da "oblak" ni čaroben. Na dnu je še vedno programska oprema, ki so jo napisali ljudje in je podvržena istim vrstam napak kot katera koli druga aplikacija - le da je od nje odvisnih za več velikostnih razredov več ljudi.

Uporabniki si bodo incident zapomnili predvsem kot "tisto jutro, ko se X in ChatGPT nista naložila".
Inženirji ga bodo verjetno preučevali kot učbeniški primer tega, kako se lahko subtilne konfiguracijske napake v osrednjem distribuiranem sistemu razširijo v globalni internetni dogodek.