Cloudflare november 18-i jelentős kiesése - Összefoglaló

2025. november 18-án az internet egy hatalmas szelete borult fel.
Ha megnyitotta a ChatGPT, az X (Twitter), a League of Legends, a Shopify, a Coinbase vagy számtalan kisebb webhelyet, egy Cloudflare-jelzésű 5xx hibaoldal fogadta - vagy az oldalak egyáltalán nem töltődtek be. Ami elsőre egy újabb nagy "elromlott az internet" pillanatnak tűnt, kiderült, hogy valami sokkal finomabb és bizonyos szempontból sokkal aggasztóbb: egy saját maga által okozott hiba mélyen a Cloudflare saját infrastruktúrájában.

Az alábbiakban részletesen bemutatjuk , mi történt a tegnapi Cloudflare-kiesés (2025. november 18.) során, miért történt, kiket érintett, és milyen tanulságokat kell levonniuk az infrastrukturális csapatoknak.

Mi történt valójában tegnap?

2025. november 18-án, kedden, UTC késő délelőtt körül a Cloudflare nagy mennyiségű HTTP 5xx szerverhibát kezdett visszaadni a hálózatán áthaladó forgalomra. A végfelhasználók számára ez "Internal Server Error" vagy "Gateway Error" oldalakat jelentett, amikor számos népszerű webhelyet és alkalmazást próbáltak elérni.

A Cloudflare saját, az eseményt követő blogja szerint a kiesés:

• Az ügyfelek HTTP-forgalmát 11:28 UTC-kor kezdte befolyásolni .

• Széleskörű 5xx hibák jelentek meg az alapvető CDN- és biztonsági szolgáltatásokban.

• 13:05-14:30 UTC körül jelentős kárenyhítési lépések történtek .

• Az 5xx hibák száma 17:06 UTC-re visszaállt az alapszintre A Cloudflare blogja

Maga a Cloudflare 2019 óta a legsúlyosabb kiesésként írta le, mivel nem csak egy funkciót vagy műszerfalat érintett - megzavarta az alapvető proxy réteget, amely az ügyfélforgalom nagy részét a hálózatán keresztül irányítja. A Cloudflare blog

A harmadik fél által végzett megfigyelés ezt alátámasztotta. A Cisco ThousandEyes globális kiesést látott, amely a Cloudflare-t érintette, és olyan szolgáltatásoknál, mint az X, az OpenAI (ChatGPT) és az Anthropic, időkiesések és 5xx hibák jelentkeztek, miközben maguk a hálózati útvonalak egészségesnek tűntek. Ez határozottan arra utalt, hogy a háttérszolgáltatás hibája állt fenn, nem pedig internetszolgáltatói szintű vagy útválasztási probléma. ThousandEyes

Ki volt érintett?

Mivel a Cloudflare az internet hatalmas része előtt áll ( a webes webhelyek mintegy 20%-a támaszkodik a Cloudflare-re a teljesítmény és a biztonság szempontjából), a robbanás sugara óriási volt. AP News+1

A jelentések szerint a szolgáltatások közül többek között a következők voltak érintettek:

• ChatGPT / OpenAI

• X (korábban Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends és más játékplatformok

• Különböző tömegközlekedési és kormányzati oldalak, köztük a New Jersey Transit és a francia SNCF vasúti digitális rendszere AP News+1

A Downdetectorhoz hasonló üzemzavar-követő eszközök a csúcsidőszakban több ezer egyidejű hibajelentést rögzítettek. A Reuters egy ponton csak az X esetében mintegy 5000 érintett felhasználóról számolt be, majd a javítások terjedésével a számok csökkentek. Reuters

A felhasználók szemszögéből ez a következőképpen jelentkezett:

• Az oldalak egyáltalán nem töltődtek be

• A bejelentkezési folyamatok akadoztak vagy meghiúsultak (különösen, ha Cloudflare Access vagy Turnstile volt érintett).

• Az API-k időszakosan vagy 5xx hibával reagáltak.

• Az irányítópultok és admin panelek időzítése

Más szóval: az internet hatalmas részei "leálltak", még akkor is, ha a kiváltó ok egyetlen szolgáltató belső rendszereiben összpontosult.

Hogyan működik a Cloudflare rendszerint (egyszerűbben fogalmazva)

Ahhoz, hogy megértsük, miért volt ilyen súlyos ez a kiesés, segít megismerni egy kérés durva útját a Cloudflare hálózatán keresztül.

A Cloudflare fordított proxy CDN-ként és biztonsági rétegként működik:

1. A böngésző vagy az alkalmazás a Cloudflare-hez csatlakozik ahelyett, hogy közvetlenül az eredeti webhelyhez kapcsolódna.

2. A Cloudflare a TLS-t és a HTTP-t a peremén terminálja.

3. A kérések a Cloudflare FL ("Frontline") és az újabb generációs FL2 nevű alapvető proxy-rendszerébe áramlanak.

4. Ez az alapvető proxy:

   • Alkalmazza a WAF (webalkalmazási tűzfal) szabályokat .

   • Botkezelési modelleket futtat

   • kezeli a DDoS-védelmet, a gyorsítótárazást, a származási hely felé történő kilépést.

   • Átirányítja a forgalmat más belső termékekhez, mint például a Workers, R2, Access stb. A Cloudflare blog

Normál működés közben ez az architektúra rendkívül rugalmas: ha az egyik adatközpontban probléma van, a forgalmat a többin keresztül irányítják; a konfigurációs változtatásokat óvatosan vezetik ki; az egyes funkcióknak zárt módon kell meghibásodniuk.

A tegnapi kiesés pontosan azért volt rossz, mert a hiba magában a közös proxy-útvonalban volt, és szorosan kapcsolódott egy konfigurációs fájlhoz, amelyet gyakran és automatikusan tolnak világszerte.

A kiváltó ok: egy bot-kezelő funkciófájl, amely elszabadult.

A Cloudflare hivatalos magyarázata egy fő bűnösre mutat:
a botkezelő rendszerük által használt konfigurációs fájl. A Cloudflare blog

Íme az események láncolata közérthetően:

1. A Bot Management egy "funkciófájlt" használ

   • A Cloudflare bot-felismerő modellje egy sor "jellemzőre" támaszkodik - az egyes kérésekkel kapcsolatos jelekre, amelyek alapján eldönthető, hogy emberi vagy botról van-e szó.

   • Ezek a jellemzők egy konfigurációs fájlba vannak foglalva, amely néhány percenként újratermelődik és globálisan ki van terjesztve, így a Cloudflare gyorsan tud alkalmazkodni az új támadási mintákhoz. A Cloudflare blog

2. Változás a ClickHouse lekérdezési viselkedésében

   • A funkciófájlt a ClickHouse adatbázisával szembeni lekérdezések generálják.

   • A Cloudflare 11:05 UTC körül változtatást hajtott végre, hogy javítsa az elosztott lekérdezések biztonságát és jogosultságait - lehetővé téve, hogy a felhasználók ne csak az alapértelmezett sémából, hanem a mögöttes r0 táblákból származó metaadatokat is láthassák. A Cloudflare blog

   • A funkciólistát felépítő lekérdezés nem szűrte az adatbázis neve alapján; hirtelen elkezdett duplikált oszlopokat kapni mind az alapértelmezett, mind az r0 sémából, ami gyakorlatilag megduplázta a funkciósorok számát.

3. A jellemzőfájl mérete robbanásszerűen megnőtt

   • A Bot Management modulnak van egy kemény korlátja arra vonatkozóan, hogy hány feature-t fogad el (200-ra van beállítva, ami jóval több, mint az általában használt ~60).

   • Amikor az újonnan generált fájl túllépte ezt a határt, a modul elérte a felső határt és pánikba esett, egy kezeletlen hiba miatt a Rust kódban, amely Result::unwrap() funkciót használt egy hibaértékre. A Cloudflare blog

4. A core proxy szolgáltatások 5xx hibákat kezdtek visszaadni

   • Mivel a Bot Management integrálva van a core proxy-útvonalba, a pánik HTTP 5xx válaszként jelent meg minden olyan forgalomban, amely ettől a modultól függött.

   • Az új FL2 motoron az ügyfelek explicit 5xx hibákat láttak.

   • A régebbi FL-motoron a bot-pontszámok csendben nullára csökkentek, ami hamis pozitív eredményeket okozhatott a bot-blokkoló szabályokban. A Cloudflare blog

5. Az igazán kellemetlen rész: a fájl folyamatosan váltogatta a "jó" és a "rossz" értékeket.

   • A ClickHouse fürtöt fokozatosan frissítették, és a funkciófájl ötpercenként újratermelődött.

   • Néha a lekérdezés frissített csomópontokon futott (rossz fájlt produkálva), néha nem frissített csomópontokon (jó fájlt produkálva).

   • Ez azt jelentette, hogy egy ideig a Cloudflare hálózata ingadozott a normál működés és a hiba között, mivel a fájl különböző verziói terjedtek. A Cloudflare blog

Ez az oszcilláció rendkívül zavarossá tette a helyzetet belsőleg. A Cloudflare csapatai először masszív DDoS-támadásra gyanakodtak, mivel a hibamintázat nem hasonlított egy egyszerű szoftverösszeomlásra. Még a Cloudflare státuszoldala is, amelyet a saját infrastruktúrájukon kívül tárolnak, rövid időre hibát mutatott - ez az egybeesés tovább táplálta a külső támadás gyanúját. A Cloudflare Blog+1

Csak akkor vált világossá a kép, amikor rájöttek, hogy a közös tényező a bot funkciófájlja volt.

Az incidens idővonala

A Cloudflare utóvizsgálata és harmadik fél jelentései alapján összeállíthatunk egy durva idővonalat 2025. november 18-ra vonatkozóan: A Cloudflare blog+2ThousandEyes+2

• 11:05 UTC - A ClickHouse-ban adatbázis-hozzáférés-szabályozási módosítás kerül bevezetésre.

• 11:20-11:30 UTC - A Bot Management funkciófájl rossz verzióinak generálása és terjesztése megkezdődik.

• 11:28 UTC - Az első ügyfélre gyakorolt hatás: megnövekedett HTTP 5xx hibák észlelhetők az ügyfélforgalomban.

• 11:30-11:32 UTC - A külső felügyeleti eszközök és az automatizált tesztek időszakos hibákat észlelnek.

• 11:35 UTC - A Cloudflare belső incidenshívást indít; megkezdődik a vizsgálat.

• ~11:48 UTC - A Cloudflare állapotfrissítést tesz közzé, amelyben megerősíti az incidenst. Újraküldés

• 11:30-13:05 UTC - A csapatok arra összpontosítanak, ami úgy tűnik, hogy a Workers KV viselkedése romlott, és több lehetséges okot vizsgálnak (beleértve a támadási forgatókönyveket is).

• 13:05 UTC - Kulcsfontosságú kárenyhítés: A Workers KV és a Cloudflare Access a core proxy megkerülésére változik; a hatás csökken. A Cloudflare blog

• 14:30 UTC - A kiváltó okot azonosították; a rossz funkciófájlok generálása és terjesztése leállt. Egy ismert jó konfigurációs fájl manuálisan beillesztésre kerül, és a core proxy újraindul. A legtöbb core forgalom visszatér a normális állapotba. A Cloudflare blog

• 14:40-15:30 UTC - A műszerfal- és bejelentkezési problémák továbbra is fennállnak, mivel a Turnstile és a hitelesítési kísérletek elmaradása másodlagos terhelési csúcsokat okoz. A Cloudflare blog

• 17:06 UTC - A hibaarányok visszatérnek az alapszintre; a Cloudflare teljesen normálisnak nyilvánítja a rendszereket. A Cloudflare blog

A felhasználók szemszögéből nézve az üzemzavar a késő délelőtt és kora délután UTC között volt a legrosszabb, bár a pontos hatásablakok régiónként és attól függően változott, hogy az egyes szolgáltatások mely Cloudflare-termékektől függtek.

Miért olyan fontos ez a kiesés

Központosítási kockázat

A Cloudflare a nagy felhőplatformok (AWS, Azure, GCP) és más nagy CDN-ek mellett a központi internetes infrastruktúra-szolgáltatók egy kis csoportjának része. Ha ezen szereplők egyike kiesik, a hatás széleskörű és gyakran nem nyilvánvaló.

Ez a kiesés:

• Nem egy BGP útválasztási baleset vagy egy internetszolgáltatói kábelszakadás miatt következett be.

• Nem rosszindulatú támadásból eredt (a kezdeti gyanú ellenére).

• Egyetlen belső komponens konfigurációs és korlátozási hibája miatt következett be.

Ez azért fontos, mert megmutatja, hogy az összetett, szorosan összekapcsolt rendszerek külső beavatkozás nélkül is katasztrofálisan meghibásodhatnak. Ha sok szervezet ugyanarra a szolgáltatóra épít, az a szolgáltató az internet de facto rendszerszinten fontos részévé válik.

A "puha" függőségek is ártanak

Az érintett szolgáltatások egy része nem csak buta CDN-ként használta a Cloudflare-t. Hanem:

• A Cloudflare Access-t használták hitelesítésre és zéró bizalmi hozzáféréshez.

• A Workers KV-t a belső vezérlési síkok részeként használták.

• Turnstile-ra támaszkodtak a bot-ellenálló bejelentkezésekhez. A Cloudflare Blog+1

Amikor ezek a termékek meghibásodtak, nem csak a webhely tartalma ment tönkre - a bejelentkezések, az admin funkciók és a belső API-k is tönkrementek. Ez összetettebbé teszi a helyreállítást: az Ön állapotoldala, az incidenskezelő eszközök vagy az admin felhasználói felület is támaszkodhat arra a szolgáltatóra, amelyik éppen meghibásodott.

Amit a Cloudflare szerint változtatni fog

A Cloudflare blogjában számos helyreállítási lépést vázol fel, amelyeket a vállalat már megtett annak érdekében, hogy csökkentse a hasonló esetek megismétlődésének kockázatát: A Cloudflare blog

1. Az automatikusan generált konfigurációs fájlok bekebelezésének keményítése
   Kezelje a belsőleg generált konfigurációkat ugyanolyan szkeptikusan és validálva, mint a felhasználó által megadott inputot, beleértve a szigorú séma- és méretellenőrzést a bevezetés előtt.

2. Több globális kill switch
   Könnyítse meg a problémás belső modulok (például a Bot Management) gyors letiltását az egész hálózaton, hogy azok ne a teljes proxy-útvonal pánikba esése helyett nyitva maradjanak.

3. A rendszer erőforrásainak védelme a hibaviharoktól
   Biztosítsa, hogy a core dumps, a hibakeresési metaadatok és a megfigyelhetőségi eszközök ne terheljék túl a CPU-t és a memóriát, amikor a hibák tetőzni kezdenek.

4. Tekintse át a hibamódokat a core proxy modulok között
   Rendszeresen ellenőrizze, hogy az egyes belső modulok hogyan viselkednek váratlan bemenet vagy konfiguráció esetén, és biztosítsa a kíméletes leépülést a globális hiba helyett.

5. A bevezetések és az elszigetelés finomítása
   Bár az incidens nem részletezte hatalmas részletességgel, az eset arra utal, hogy a Cloudflare valószínűleg tovább szegmentálja az új konfigurációk és a DB viselkedés terjedésének módját, hogy csökkentse annak esélyét, hogy egyetlen rossz változás az egész flottára hatással legyen.

Az incidenst a rugalmassági elvárásaik abszolút kudarcának is nevezték, "elfogadhatatlannak" nevezték, és kifejezetten elismerték a fájdalmat, amit az ügyfeleknek és az egyszerű internetfelhasználóknak okozott. A Cloudflare blog

Tanulságok az infrastruktúra- és SRE-csapatok számára

Még ha nem is üzemeltetsz olyan hatalmasat, mint a Cloudflare, akkor is van néhány nagyon gyakorlatias tervezési és üzemeltetési tanulság ebből a kiesésből:

Kezelje a belső konfigurációt nem megbízható bemenetként

Könnyű azt feltételezni, hogy a "saját" generált konfigurációnk mindig helyes. A tegnapi nap megmutatta, hogy ez miért veszélyes:

• Mindig ellenőrizze a konfigurációs fájlok méretét, alakját és korlátait, mielőtt alkalmazza azokat.

• Vegyük fontolóra a konfiguráció kanáris alkalmazását először a forgalom vagy a csomópontok egy kis részhalmazára, anomáliák esetén automatikus visszaállítással.

• Tartsunk szigorú felső korlátokat és megszakítókat a funkciók száma, a memória előzetes kiosztása és a CPU-használat körül.

Tervezzünk kíméletes részleges meghibásodást

Egy hiba a botmenedzsment modulban nem okozhat pánikot a teljes proxy-útvonalon:

• Alapértelmezett fail-open helyett fail-closed a biztonság egyes rétegeiben, ha az alternatíva a teljes kiesés.

• Építsünk egyértelmű, tesztelt kill switcheket a nem alapvető funkciókhoz.

• Biztosítsa, hogy a kritikus alrendszerek (auth, státuszoldal, incidenskezelő eszközök) degradált üzemmódban vagy alternatív útvonalakon keresztül is működhessenek.

Figyelje a megfelelő jelzéseket

A "jó konfiguráció" és a "rossz konfiguráció" közötti ötpercenkénti oszcilláció miatt a jelek támadási forgalomnak vagy zajos külső viselkedésnek tűntek:

• Győződjön meg róla, hogy a megfigyelhetőségi csővezetékében verziónkénti vagy konfigurációnkénti korrelációval rendelkezik.

• Építsen olyan műszerfalakat, amelyek a konfigurációváltozásokat vizuálisan nyilvánvalóvá teszik a hibagrafikonok tetején.

• Tartalmazzon erős szintetikus teszteket külső nézőpontból, hogy gyorsan meg tudja különböztetni a belső hibát a hálózati/útvonalproblémáktól.

Ne tegye minden tojását egy infra kosárba.

A Cloudflare-t használó szervezetek számára:

• Fontolja meg a több CDN-t tartalmazó beállításokat a valóban kritikus tulajdonságok esetében.

• Kerülje, hogy az állapotoldala teljes mértékben ugyanattól a szolgáltatótól függjön, mint az elsődleges stackje (a Cloudflare ezt teszi, de tegnap véletlenül gondok voltak az állapotoldaluk hostjával, ami tovább zavarta a dolgokat). A Cloudflare Blog+1

• Gondolja meg kétszer is, mielőtt a hitelesítést, az API vezérlő síkokat és a frontend szállítást szorosan ugyanahhoz a szolgáltatóhoz köti tartalék útvonalak nélkül.

A nagyobb kép

Csak az elmúlt néhány hónapban a Microsoft Azure, az Amazon Web Services és most a Cloudflare esetében is jelentős kieséseket tapasztaltunk, amelyek mindegyike átmenetileg a fogyasztói és vállalati szolgáltatások nagy részét tette offline állapotba. AP News+2TheWashington Post+2

A minta egyértelmű:

• Az internet egyre inkább egy maroknyi óriási infrastruktúra-szolgáltatótól függ.

• Az üzemzavarok gyakran saját maguk okozzák, és nem külső támadások, hanem összetett belső változások miatt következnek be.

• Még a világszínvonalú SRE-gyakorlatokkal rendelkező szolgáltatókat is megbuktathatják a konfiguráció, az adatbázisok viselkedése és a keményen kódolt korlátok közötti váratlan kölcsönhatások.

A tegnapi Cloudflare incidens élesen emlékeztet arra, hogy a "felhő" nem varázslat. Alapvetően még mindig emberek által írt szoftverről van szó, amely ugyanolyan hibáknak van kitéve, mint bármely más alkalmazás - csak nagyságrendekkel több ember függ tőle.

A felhasználók számára ez az incidens leginkább úgy marad emlékezetes, mint "az a reggel, amikor az X és a ChatGPT nem töltődött be".
A mérnökök valószínűleg tankönyvi példaként fogják tanulmányozni, hogyan válhatnak egy elosztott rendszerben lévő finom konfigurációs hibák globális internetes eseménnyé.