Hlavný výpadok spoločnosti Cloudflare z 18. novembra - zhrnutie

18. novembra 2025 sa prepadol obrovský kus internetu.
Ak ste otvorili ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase alebo nespočetné množstvo menších stránok, privítala vás chybová stránka s označením Cloudflare 5xx - alebo sa stránky jednoducho nenačítali vôbec. To, čo spočiatku vyzeralo ako ďalší veľký moment "internet je pokazený", sa ukázalo ako niečo jemnejšie a v niektorých ohľadoch znepokojujúcejšie: chyba, ktorú si spoločnosť Cloudflare spôsobila sama hlboko vo svojej vlastnej infraštruktúre.

Nižšie uvádzame podrobný prehľad toho, čo sa stalo počas včerajšieho výpadku Cloudflare (18. novembra 2025), prečo k nemu došlo, koho sa dotkol a aké ponaučenie by si z neho mali vziať tímy zodpovedné za infraštruktúru.

Čo sa vlastne včera stalo?

V utorok 18. novembra 2025 okolo neskorého rána UTC začala spoločnosť Cloudflare vracať veľké množstvo chýb servera HTTP 5xx pre prevádzku, ktorá prešla jej sieťou. Pre koncových používateľov to znamenalo stránky "Internal Server Error" alebo "Gateway Error" pri pokuse o prístup k mnohým obľúbeným webovým stránkam a aplikáciám.

Podľa vlastného blogu spoločnosti Cloudflare po incidente došlo k výpadku:

• Začalo ovplyvňovať prevádzku HTTP zákazníkov o 11:28 UTC

• Zaznamenali sa rozsiahle chyby 5xx v hlavných službách CDN a bezpečnostných službách

• okolo 13:05 - 14:30 UTC boli vykonané hlavné kroky na zmiernenie následkov

• Objem chýb 5xx sa vrátil na základnú úroveň do 17:06 UTC Blog Cloudflare

Samotná spoločnosť Cloudflare to označila za svoj najhorší výpadok od roku 2019, pretože neovplyvnil len jednu funkciu alebo ovládací panel - narušil základnú vrstvu proxy servera, ktorá smeruje väčšinu prevádzky zákazníkov cez jej sieť. Blog Cloudflare

Monitoring tretích strán to potvrdil. Spoločnosť Cisco ThousandEyes zaznamenala globálny výpadok, ktorý ovplyvnil spoločnosť Cloudflare, s timeoutmi a chybami 5xx v službách ako X, OpenAI (ChatGPT) a Anthropic, zatiaľ čo samotné sieťové cesty vyzerali zdravo. To jednoznačne poukazovalo na zlyhanie backendovej služby, nie na problém na úrovni poskytovateľa internetových služieb alebo smerovania. ThousandEyes

Kto bol postihnutý?

Keďže Cloudflare sa nachádza pred obrovskou časťou internetu (približne 20 % webových lokalít sa spolieha na Cloudflare z hľadiska výkonu a bezpečnosti), rádius výbuchu bol obrovský. AP News+1

Medzi službami, ktoré boli hlásené ako ovplyvnené:

• ChatGPT / OpenAI

• X (predtým Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends a ďalšie herné platformy

• rôzne stránky verejnej dopravy a vládnych inštitúcií vrátane New Jersey Transit a digitálnych systémov francúzskych železníc SNCF AP News+1

Zariadenia na sledovanie výpadkov, ako napríklad Downdetector, zaznamenali v čase najväčšieho výpadku tisíce súbežných hlásení o problémoch. Agentúra Reuters zaznamenala v jednom momente približne 5 000 postihnutých používateľov len v prípade X, potom sa počet znížil, keď sa zaviedli opravy. Reuters

Z pohľadu používateľa sa to prejavilo ako:

• stránky sa vôbec nenačítavajú

• zlyhanie alebo zlyhanie prihlasovacích tokov (najmä v prípadoch, keď sa to týkalo služieb Cloudflare Access alebo Turnstile).

• API reagovali prerušovane alebo s chybami 5xx

• nefunkčné prístrojové panely a panely administrátora

Inými slovami: obrovské časti internetu sa "cítili nefunkčné", hoci hlavná príčina bola sústredená v interných systémoch jedného poskytovateľa.

Ako Cloudflare zvyčajne funguje (zjednodušene)

Aby sme pochopili, prečo bol tento výpadok taký závažný, pomôže nám poznať približnú cestu požiadavky cez sieť Cloudflare.

Cloudflare funguje ako reverzný proxy server CDN a bezpečnostná vrstva:

1. Váš prehliadač alebo aplikácia sa namiesto priameho pripojenia k pôvodnej lokalite pripája k službe Cloudflare.

2. Cloudflare ukončuje TLS a HTTP na svojom okraji.

3. Požiadavky prúdia do základného systému proxy servera Cloudflare, ktorý sa nazýva FL ("Frontline ") a jeho novšia generácia FL2.

4. Tento hlavný proxy server:

   • aplikuje pravidlá WAF (web application firewall)

   • Spúšťa modely správy botov

   • Zabezpečuje ochranu pred DDoS, ukladanie do vyrovnávacej pamäte a výstup na miesto pôvodu

   • Smeruje prevádzku do iných interných produktov, ako sú Workers, R2, Access atď. Blog Cloudflare

V bežnej prevádzke je táto architektúra vysoko odolná: ak má jedno dátové centrum problém, prevádzka sa presmeruje cez iné; zmeny konfigurácie sa zavádzajú opatrne; jednotlivé funkcie by mali zlyhať obsiahnutými spôsobmi.

Včerajší výpadok bol zlý práve preto, že zlyhanie bolo vnútri samotnej spoločnej cesty proxy servera a bolo úzko spojené s konfiguračným súborom, ktorý sa často a automaticky posúva po celom svete.

Hlavná príčina: súbor s funkciou správy botov, ktorý sa pokazil

Oficiálne vysvetlenie spoločnosti Cloudflare poukazuje na jedného kľúčového vinníka:
konfiguračný súbor funkcie, ktorý používa ich systém Bot Management. Blog Cloudflare

Tu je reťazec udalostí v zrozumiteľnom jazyku:

1. Správa botov používa "súbor funkcie".

   • Model detekcie botov spoločnosti Cloudflare sa spolieha na súbor "funkcií" - signálov o každej požiadavke, ktoré sa používajú na rozhodnutie, či ide o človeka alebo bota.

   • Tieto funkcie sa spájajú do konfiguračného súboru, ktorý sa každých niekoľko minút regeneruje a globálne rozširuje, aby sa spoločnosť Cloudflare mohla rýchlo prispôsobiť novým modelom útokov. Blog Cloudflare

2. Zmena v správaní dotazov ClickHouse

   • Súbor funkcií sa generuje na základe dotazov voči databáze ClickHouse.

   • Spoločnosť Cloudflare vykonala okolo 11:05 UTC zmenu, aby zlepšila bezpečnosť a oprávnenia pre distribuované dotazy - umožnila používateľom vidieť metadáta nielen z predvolenej schémy, ale aj zo základných tabuliek r0. Blog spoločnosti Cloudflare

   • Dotaz, ktorý zostavuje zoznam funkcií, nefiltroval podľa názvu databázy; zrazu začal získavať duplicitné stĺpce z predvolenej schémy aj z r0, čím sa počet riadkov funkcií fakticky zdvojnásobil.

3. Súbor funkcií sa zväčšil

   • Modul Bot Management (Správa botov) má pevný limit na počet funkcií, ktoré akceptuje (nastavený na 200, čo je výrazne viac ako bežne používaných ~60).

   • Keď novovytvorený súbor prekročil tento limit, modul narazil na limit a spanikáril v dôsledku neobsluhovanej chyby v kóde Rust, ktorý používal Result::unwrap() na chybovú hodnotu. Blog Cloudflare

4. Základné služby proxy začali vracať chyby 5xx

   • Pretože Bot Management je integrovaný do jadra proxy cesty, panika sa objavila ako odpovede HTTP 5xx pre akúkoľvek prevádzku, ktorá závisela od tohto modulu.

   • Na novom engine FL2 sa zákazníkom zobrazovali explicitné chyby 5xx.

   • Na staršom engine FL skóre botov potichu kleslo na nulu, čo mohlo spôsobiť falošne pozitívne výsledky v pravidlách blokovania botov. Blog Cloudflare

5. Skutočne nepríjemná časť: súbor sa neustále prepínal medzi "dobrým" a "zlým"

   • Klaster ClickHouse sa postupne aktualizoval a súbor s funkciami sa regeneroval každých päť minút.

   • Niekedy sa dopyt spustil na aktualizovaných uzloch (čím vznikol zlý súbor), inokedy na neaktualizovaných uzloch (čím vznikol dobrý súbor).

   • To znamenalo, že sieť Cloudflare chvíľu oscilovala medzi normálnou prevádzkou a poruchou, pretože sa šírili rôzne verzie súboru. Blog Cloudflare

Táto oscilácia spôsobila, že situácia bola interne veľmi neprehľadná. Tímy spoločnosti Cloudflare mali najprv podozrenie na masívny útok DDoS, pretože vzorec chýb nevyzeral ako obyčajná porucha softvéru. Dokonca aj stavová stránka Cloudflare, ktorá je umiestnená mimo ich vlastnej infraštruktúry, nakrátko vykazovala chyby - táto zhoda okolností ešte viac podporila podozrenie z externého útoku. Blog spoločnosti Cloudflare+1

Až keď si uvedomili, že spoločným faktorom je súbor s funkciami bota, obraz sa vyjasnil.

Časová os incidentu

Na základe posmrtnej správy spoločnosti Cloudflare a správ tretích strán môžeme zostaviť hrubú časovú os incidentu z 18. novembra 2025: Blog Cloudflare+2ThousandEyes+2

• 11:05 UTC - V službe ClickHouse je nasadená zmena riadenia prístupu k databáze.

• 11:20-11:30 UTC - Začínajú sa generovať a šíriť zlé verzie súboru funkcií Bot Management.

• 11:28 UTC - Prvý dopad na zákazníka: v prevádzke zákazníka sa objavujú zvýšené chyby HTTP 5xx.

• 11:30-11:32 UTC - Externé monitorovacie nástroje a automatizované testy začínajú zisťovať občasné zlyhania.

• 11:35 UTC - Spoločnosť Cloudflare otvára interný hovor o incidente; začína sa vyšetrovanie.

• ~11:48 UTC - Spoločnosť Cloudflare zverejňuje aktualizáciu stavu potvrdzujúcu incident. Opätovné odoslanie

• 11:30-13:05 UTC - Tímy sa zameriavajú na to, čo sa javí ako zhoršené správanie pracovníkov KV, a vyšetrujú viaceré možné príčiny (vrátane scenárov útoku).

• 13:05 UTC - Kľúčové zmiernenie: Workers KV a Cloudflare Access sú posunuté tak, aby obchádzali jadro proxy servera; vplyv je znížený. Blog Cloudflare

• 14:30 UTC - Identifikovaná koreňová príčina; generovanie a šírenie súborov so zlými funkciami je zastavené. Ručne sa vloží známy dobrý konfiguračný súbor a jadro proxy servera sa reštartuje. Väčšina prevádzky jadra sa vracia do normálu. Blog Cloudflare

• 14:40 - 15:30 UTC - Problémy s ovládacím panelom a prihlasovaním pretrvávajú, pretože Turnstile a množstvo nevybavených pokusov o overenie vytvárajú sekundárne nárasty záťaže. Blog Cloudflare

• 17:06 UTC - Počet chýb sa vrátil na základnú úroveň; spoločnosť Cloudflare vyhlasuje, že systémy sú plne v norme. Blog Cloudflare

Z pohľadu používateľov bol výpadok najhorší v neskorých ranných až skorých popoludňajších hodinách UTC, hoci presné okná vplyvu sa líšili podľa regiónov a podľa toho, na ktorých produktoch Cloudflare boli jednotlivé služby závislé.

Prečo je tento výpadok taký dôležitý

Riziko centralizácie

Spoločnosť Cloudflare je súčasťou malého súboru centrálnych poskytovateľov internetovej infraštruktúry spolu s hlavnými cloudovými platformami (AWS, Azure, GCP) a ďalšími veľkými sieťami CDN. Keď jeden z týchto hráčov zlyhá, dopad je široký a často nie je zrejmý.

Tento výpadok:

• Nebol spôsobený nešťastnou náhodou pri smerovaní BGP ani prerušením kábla poskytovateľa internetových služieb.

• Nebol spôsobený škodlivým útokom (napriek počiatočným podozreniam).

• Príčinou bola jediná chyba v konfigurácii a obmedzeniach interného komponentu.

Je to dôležité, pretože to ukazuje, ako môžu zložité, úzko prepojené systémy katastrofálne zlyhať aj bez vonkajšieho zásahu. Keď mnoho organizácií stavia na tom istom poskytovateľovi, stáva sa tento poskytovateľ de facto systémovo dôležitým kúskom internetu.

"Mäkké" závislosti tiež škodia

Niektoré z postihnutých služieb nepoužívali Cloudflare len ako hlúpu sieť CDN. Boli to:

• Používali službu Cloudflare Access na overovanie a prístup bez dôvery.

• Používali Workers KV ako súčasť interných kontrolných rovín.

• Spoliehali sa na Turnstile na prihlasovanie odolné voči botom. BlogCloudflare+1

Keď tieto produkty zlyhali, nepadol len obsah webových stránok - zlyhali aj prihlasovacie údaje, funkcie správcu a interné rozhrania API. To komplikuje obnovu: vaša stavová stránka, nástroje na riešenie incidentov alebo používateľské rozhranie administrátora sa môžu spoliehať aj na toho istého poskytovateľa, ktorý práve zlyhal.

Čo sa podľa Cloudflare zmení

Na blogu spoločnosti Cloudflare sa uvádza niekoľko nápravných krokov, ktoré už spoločnosť podniká, aby znížila riziko, že sa niečo podobné zopakuje: Blog Cloudflare

1. Sprísnenie prijímania automaticky generovaných konfiguračných súborov
   K interne generovaným konfiguračným súborom pristupujte rovnako skepticky a overujte ich rovnako ako vstupy poskytnuté používateľom, vrátane prísnej kontroly schémy a veľkosti pred zavedením.

2. Viac globálnych vypínačov
   Uľahčite rýchle vypínanie problematických interných modulov (ako je napríklad Bot Management) v celej sieti, aby zlyhali otvorené namiesto paniky v celej ceste proxy servera.

3. Ochrana systémových zdrojov pred chybovými búrkami
   Zabezpečte, aby výpisy jadra, metadáta ladenia a nástroje na pozorovanie nemohli zahltiť procesor a pamäť, keď sa chyby začnú hromadiť.

4. Preskúmajte spôsoby zlyhania v moduloch jadra proxy servera
   Systematicky kontrolujte, ako sa každý interný modul správa pri neočakávanom vstupe alebo konfigurácii, a zabezpečte postupnú degradáciu namiesto globálneho zlyhania.

5. Zdokonaľte zavádzanie a izoláciu
   Hoci incident nie je rozpísaný do veľkých detailov, naznačuje, že spoločnosť Cloudflare bude pravdepodobne ďalej segmentovať, ako sa šíria nové konfigurácie a správanie DB, aby sa znížila šanca, že jedna zlá zmena ovplyvní celú flotilu.

Incident tiež zarámovali ako absolútne zlyhanie svojich očakávaní v oblasti odolnosti, označili ho za "neprijateľný" a výslovne uznali bolesť, ktorú spôsobil zákazníkom aj bežným používateľom internetu. Blog Cloudflare

Poučenie pre tímy infraštruktúry a SRE

Aj keď neprevádzkujete niečo také obrovské ako spoločnosť Cloudflare, z tohto výpadku vyplýva niekoľko veľmi praktických ponaučení týkajúcich sa návrhu a prevádzky:

S internou konfiguráciou zaobchádzajte ako s nedôveryhodným vstupom

Je ľahké predpokladať, že "naša" generovaná konfigurácia je vždy správna. Včerajší deň ukázal, prečo je to nebezpečné:

• Pred použitím konfiguračných súborov vždy overte ich veľkosť, tvar a obmedzenia.

• Zvážte kanársku aplikáciu konfigurácie najprv na malú podmnožinu prevádzky alebo uzlov s automatickým vrátením pri anomáliách.

• Dodržiavajte prísne horné hranice a ističe okolo počtu funkcií, predalokácie pamäte a využitia CPU.

Navrhnite systém na postupné čiastočné zlyhanie

Jedna chyba v module Bot Management by nemala spôsobiť paniku celej cesty proxy servera:

• Predvolené nastavenie fail-open vs fail-closed v niektorých vrstvách zabezpečenia, keď je alternatívou úplný výpadok.

• Zostavte jasné, otestované vypínače pre funkcie, ktoré nie sú jadrom systému.

• Zabezpečte, aby kritické subsystémy (autentifikácia, stavová stránka, nástroje na riešenie incidentov) mohli fungovať v zhoršenom režime alebo prostredníctvom alternatívnych ciest.

Pozorujte správne signály

Oscilácia medzi "dobrou konfiguráciou" a "zlou konfiguráciou" každých päť minút spôsobila, že signál vyzeral ako útočná prevádzka alebo hlučné vonkajšie správanie:

• Uistite sa, že máte vo svojom potrubí pozorovateľnosti koreláciu na verziu alebo na konfiguráciu.

• Vytvorte informačné panely, ktoré vizuálne zviditeľnia zmeny konfigurácie na grafe chýb.

• Zahrňte silné syntetické testy z vonkajšieho pohľadu, aby ste mohli rýchlo rozlíšiť interné zlyhanie od problémov so sieťou/cestou.

Nevkladajte všetky vajcia do jedného koša s infraštruktúrou

Pre organizácie používajúce službu Cloudflare:

• Zvážte nastavenia viacerých CDN pre skutočne kritické vlastnosti.

• Vyhnite sa tomu, aby vaša stavová stránka bola úplne závislá od rovnakého poskytovateľa ako váš primárny zásobník (Cloudflare to robí, ale včera sa vyskytli náhodné problémy s hostiteľom ich stavovej stránky, ktoré veci ešte viac zamotali). BlogCloudflare+1

• Dvakrát si rozmyslite, než pevne spojíte autentifikáciu, riadiace roviny API a poskytovanie frontendov s tým istým dodávateľom bez záložných ciest.

Širší obraz

Len za posledných niekoľko mesiacov sme boli svedkami veľkých výpadkov v službách Microsoft Azure, Amazon Web Services a teraz aj Cloudflare, ktoré dočasne vyradili z prevádzky veľké časti spotrebiteľských a podnikových služieb. AP News+2TheWashington Post+2

Vzorec je jasný:

• Internet je čoraz viac závislý od niekoľkých obrovských poskytovateľov infraštruktúry.

• Výpadky si často spôsobujú sami a sú skôr dôsledkom zložitých vnútorných zmien než vonkajších útokov.

• Dokonca aj poskytovatelia s prvotriednymi postupmi SRE môžu byť stále vyradení z prevádzky neočakávanými interakciami medzi konfiguráciou, správaním databáz a pevne zakódovanými limitmi.

Včerajší incident spoločnosti Cloudflare je jasnou pripomienkou toho, že "cloud" nie je magický. V podstate je to stále softvér napísaný ľuďmi, ktorý podlieha rovnakým triedam chýb ako akákoľvek iná aplikácia - len na ňom závisí rádovo viac ľudí.

Používatelia si tento incident budú väčšinou pamätať ako "to ráno, keď sa nenačítal X a ChatGPT".
Inžinieri ho budú pravdepodobne študovať ako učebnicový príklad toho, ako sa jemné konfiguračné chyby v jadre distribuovaného systému môžu rozšíriť do globálnej internetovej udalosti.