Hlavní výpadek Cloudflare 18. listopadu - shrnutí

Dne 18. listopadu 2025 spadl obrovský kus internetu.
Pokud jste otevřeli ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase nebo nespočet menších webů, přivítala vás chybová stránka s označením Cloudflare 5xx - nebo se weby prostě nenačetly vůbec. To, co zprvu vypadalo jako další velký "internet je rozbitý", se ukázalo být něčím subtilnějším a v některých ohledech znepokojivějším: chybou, kterou si společnost Cloudflare sama způsobila hluboko uvnitř své vlastní infrastruktury.

Níže najdete podrobný přehled toho, co se stalo při včerejším výpadku Cloudflare (18. listopadu 2025), proč k němu došlo, koho se týkal a jaké ponaučení by si z něj měly vzít infrastrukturní týmy.

Co se vlastně včera stalo?

V úterý 18. listopadu 2025 kolem pozdního rána UTC začala společnost Cloudflare vracet velké množství chyb serveru HTTP 5xx pro provoz, který procházel její sítí. Pro koncové uživatele to znamenalo stránky "Internal Server Error" nebo "Gateway Error" při pokusu o přístup k mnoha populárním webovým stránkám a aplikacím.

Podle vlastního blogu společnosti Cloudflare po incidentu došlo k výpadku:

• Začal ovlivňovat provoz HTTP zákazníků v 11:28 UTC.

• Zaznamenal rozsáhlé chyby 5xx napříč hlavními službami CDN a bezpečnostními službami.

• Kolem 13:05-14:30 UTC došlo k zásadním krokům ke zmírnění dopadů .

• Objem chyb 5xx se vrátil na základní úroveň v 17:06 UTC Blog Cloudflare

Samotná společnost Cloudflare tento výpadek označila za nejhorší od roku 2019, protože neovlivnil pouze jednu funkci nebo ovládací panel - narušil základní vrstvu proxy serveru, která směruje většinu provozu zákazníků přes její síť. Blog Cloudflare

Monitorování třetích stran to potvrdilo. Společnost Cisco ThousandEyes zaznamenala globální výpadek, který postihl společnost Cloudflare, s timeouty a chybami 5xx u služeb jako X, OpenAI (ChatGPT) a Anthropic, zatímco samotné síťové cesty vypadaly zdravě. To jednoznačně ukazovalo na selhání backendové služby, nikoli na problém na úrovni poskytovatele internetu nebo směrování. ThousandEyes

Kdo byl postižen?

Vzhledem k tomu, že Cloudflare stojí před obrovskou částí internetu (na Cloudflare spoléhá z hlediska výkonu a zabezpečení přibližně 20 % webových stránek ), byl okruh zasažení obrovský. AP News+1

Mezi službami, které byly hlášeny jako zasažené, jsou např:

• ChatGPT / OpenAI

• X (dříve Twitter)

• Canva, Shopify, Dropbox, Coinbase.

• League of Legends a další herní platformy

• Různé weby veřejné dopravy a státní správy, včetně digitálních systémů New Jersey Transit a francouzské železnice SNCF AP News+1

Systémy pro sledování výpadků, jako je Downdetector, zaznamenaly ve špičce tisíce souběžných hlášení o problémech. Agentura Reuters v jednu chvíli hlásila jen pro X asi 5 000 postižených uživatelů, než se počty snížily s tím, jak se zaváděly opravy. Reuters

Z pohledu uživatelů se to projevilo jako:

• weby se vůbec nenačítaly

• zasekávání nebo selhávání přihlašovacích toků (zejména pokud se jednalo o Cloudflare Access nebo Turnstile).

• Přerušovaná odezva rozhraní API nebo chyby 5xx.

• Dashboardy a panely administrátora přestaly fungovat.

Jinými slovy: obrovské části internetu se "cítily nefunkční", přestože hlavní příčina byla soustředěna v interních systémech jednoho poskytovatele.

Jak Cloudflare obvykle funguje (zjednodušeně řečeno)

Abychom pochopili, proč byl tento výpadek tak závažný, pomůže nám znát přibližnou cestu požadavku sítí Cloudflare.

Cloudflare funguje jako reverzní proxy CDN a bezpečnostní vrstva:

1. Prohlížeč nebo aplikace se připojí ke službě Cloudflare namísto přímého připojení k původnímu webu.

2. Cloudflare ukončuje protokoly TLS a HTTP na svém okraji.

3. Požadavky proudí do jádra proxy systému Cloudflare, který se nazývá FL ("Frontline ") a jeho novější generace FL2.

4. Toto jádro proxy serveru:

   • aplikuje pravidla WAF (web application firewall).

   • spouští modely správy botů

   • Zajišťuje ochranu proti DDoS, ukládání do mezipaměti a výstup k původci

   • Směruje provoz na další interní produkty, jako jsou Workers, R2, Access atd. Blog Cloudflare

V běžném provozu je tato architektura vysoce odolná: pokud má jedno datové centrum problém, provoz je směrován přes jiná; změny konfigurace jsou zaváděny opatrně; jednotlivé funkce by měly selhávat obsaženými způsoby.

Včerejší výpadek byl špatný právě proto, že selhání bylo uvnitř samotné společné cesty proxy serveru a bylo úzce spojeno s konfiguračním souborem, který se často a automaticky posouvá po celém světě.

Hlavní příčina: soubor s funkcí pro správu botů, který se dostal do rozporu s pravidly.

Oficiální vysvětlení společnosti Cloudflare ukazuje na jednoho klíčového viníka:
konfigurační soubor funkce používaný jejich systémem pro správu botů. Blog Cloudflare

Zde je řetězec událostí v jednoduchém jazyce:

1. Správa botů používá "soubor funkcí".

   • Model detekce botů společnosti Cloudflare se spoléhá na soubor "funkcí" - signálů o každém požadavku, podle kterých se rozhoduje, zda jde o člověka, nebo o bota.

   • Tyto funkce jsou sdruženy do konfiguračního souboru, který se každých několik minut obnovuje a zavádí globálně, takže se společnost Cloudflare může rychle přizpůsobit novým vzorům útoků. Blog společnosti Cloudflare

2. Změna v chování dotazů ClickHouse

   • Soubor funkcí je generován dotazy vůči databázi ClickHouse.

   • Společnost Cloudflare provedla kolem 11:05 UTC změnu, která zlepšuje zabezpečení a oprávnění distribuovaných dotazů - umožňuje uživatelům zobrazit metadata nejen z výchozího schématu, ale také z podkladových tabulek r0. Blog společnosti Cloudflare

   • Dotaz, který sestavuje seznam funkcí, nefiltroval podle názvu databáze; najednou začal získávat duplicitní sloupce z výchozího schématu i ze schématu r0, což efektivně zdvojnásobilo počet řádků funkcí.

3. Velikost souboru funkcí se zvětšila

   • Modul Bot Management má pevný limit na počet funkcí, které přijme (nastavený na 200, což je mnohem více než běžně používaných ~60).

   • Když nově vygenerovaný soubor tento limit překročil, modul narazil na limit a zpanikařil kvůli neošetřené chybě v kódu Rust, který použil Result::unwrap() na chybovou hodnotu. Blog Cloudflare

4. Základní služby proxy serveru začaly vracet chyby 5xx

   • Protože je služba Bot Management integrována do cesty jádra proxy serveru, panika se objevila jako odpovědi HTTP 5xx pro veškerý provoz, který závisel na tomto modulu.

   • Na novém enginu FL2 se zákazníkům zobrazovaly explicitní chyby 5xx.

   • Na starším enginu FL se skóre botů v tichosti snížilo na nulu, což mohlo způsobit falešně pozitivní výsledky v pravidlech pro blokování botů. Blog společnosti Cloudflare

5. Opravdu nepříjemná část: soubor se neustále přepínal mezi "dobrým" a "špatným".

   • Cluster ClickHouse byl postupně aktualizován a soubor s funkcemi se regeneroval každých pět minut.

   • Někdy dotaz běžel na aktualizovaných uzlech (a vytvářel špatný soubor), jindy na neaktualizovaných uzlech (a vytvářel dobrý soubor).

   • To znamenalo, že síť Cloudflare chvíli oscilovala mezi normálním provozem a poruchou, protože se šířily různé verze souboru. Blog Cloudflare

Tato oscilace způsobila, že situace byla interně velmi nepřehledná. Týmy společnosti Cloudflare nejprve pojaly podezření na masivní útok DDoS, protože vzorec chyb nevypadal jako prostá softwarová havárie. Dokonce i stavová stránka Cloudflare, která je umístěna mimo jejich vlastní infrastrukturu, krátce vykazovala chyby - tato shoda okolností ještě více podpořila podezření na vnější útok. Blog společnosti Cloudflare+1

Teprve když si uvědomili, že společným faktorem je soubor s funkcí bota, obrázek se vyjasnil.

Časová osa incidentu

Na základě postmortem společnosti Cloudflare a zpráv třetích stran můžeme dát dohromady přibližnou časovou osu 18. listopadu 2025: Blog Cloudflare+2ThousandEyes+2

• 11:05 UTC - V systému ClickHouse je nasazena změna řízení přístupu k databázi.

• 11:20-11:30 UTC - Začínají se generovat a šířit špatné verze souboru funkce Bot Management.

• 11:28 UTC - První dopad na zákazníky: v provozu zákazníků jsou pozorovány zvýšené chyby HTTP 5xx.

• 11:30-11:32 UTC - Externí monitorovací nástroje a automatizované testy začínají zjišťovat občasná selhání.

• 11:35 UTC - Společnost Cloudflare otevírá interní hovor o incidentu; začíná vyšetřování.

• ~11:48 UTC - Společnost Cloudflare zveřejňuje aktualizaci stavu potvrzující incident. Opětovné odeslání

• 11:30-13:05 UTC - Týmy se zaměřují na to, co se jeví jako zhoršené chování KV pracovníků, a zkoumají více možných příčin (včetně scénářů útoku).

• 13:05 UTC - Klíčové zmírnění: Workers KV a Cloudflare Access jsou přesunuty tak, aby obcházely hlavní proxy server; dopad je omezen. Blog Cloudflare

• 14:30 UTC - Identifikována hlavní příčina; generování a šíření špatných souborů funkcí je zastaveno. Ručně je vložen známý dobrý konfigurační soubor a je restartováno jádro proxy serveru. Většina provozu jádra se vrací do normálu. Blog Cloudflare

• 14:40-15:30 UTC - Problémy s ovládacím panelem a přihlašováním přetrvávají, protože Turnstile a množství nevyřízených pokusů o ověření vytvářejí sekundární nárůsty zátěže. Blog Cloudflare

• 17:06 UTC - Míra chybovosti se vrací na základní úroveň; společnost Cloudflare prohlašuje, že systémy jsou plně v normálu. Blog Cloudflare

Z pohledu uživatelů byl výpadek nejhorší v pozdních ranních až časných odpoledních hodinách UTC, ačkoli přesná okna dopadu se lišila podle regionu a podle toho, na kterých produktech Cloudflare byly jednotlivé služby závislé.

Proč je tento výpadek tak důležitý

Riziko centralizace

Cloudflare je součástí malé skupiny centrálních poskytovatelů internetové infrastruktury, vedle hlavních cloudových platforem (AWS, Azure, GCP) a dalších velkých CDN. Když jeden z těchto hráčů selže, dopad je široký a často nezjevný.

Tento výpadek:

• Nebyl způsoben chybou při směrování BGP ani přerušením kabelu poskytovatele internetu.

• Nebyl způsoben zákeřným útokem (navzdory původnímu podezření).

• Byl způsoben jedinou chybou v konfiguraci a omezeních interní komponenty.

To je důležité, protože to ukazuje, jak složité, úzce propojené systémy mohou katastrofálně selhat i bez vnějšího zásahu. Když mnoho organizací staví na stejném poskytovateli, stává se tento poskytovatel de facto systémově důležitou součástí internetu.

"Měkké" závislosti také škodí

Některé z postižených služeb nepoužívaly Cloudflare jen jako hloupou síť CDN. Byly to tyto služby:

• Používaly službu Cloudflare Access pro ověřování a přístup s nulovou důvěrou.

• Používaly Workers KV jako součást interních řídicích rovin.

• Spoléhaly na Turnstile pro přihlašování odolné proti botům. BlogCloudflare+1

Když tyto produkty selhaly, nešlo jen o výpadek obsahu webových stránek - selhaly i přihlašovací údaje, funkce správce a interní rozhraní API. To činí obnovu složitější: vaše stavová stránka, nástroje pro řešení incidentů nebo uživatelské rozhraní správce mohou také spoléhat na stejného poskytovatele, který právě selhal.

Co se podle Cloudflare změní

Na blogu společnosti Cloudflare je uvedeno několik nápravných kroků, které společnost již podniká, aby snížila riziko, že se něco podobného bude opakovat: Blog Cloudflare

1. Zpřísnění přijímání automaticky generovaných konfiguračních souborů
   K interně generovaným konfiguračním souborům přistupujte stejně skepticky a ověřujte je stejně jako vstupní údaje zadané uživatelem, včetně přísné kontroly schématu a velikosti před zavedením.

2. Více globálních vypínačů
   Usnadněte rychlé vypnutí problematických interních modulů (jako je například Správa botů) v celé síti, aby selhaly při otevření, místo aby vyvolaly paniku v celé cestě proxy serveru.

3. Ochrana systémových prostředků před chybovými bouřemi
   Zajistěte, aby výpisy jádra, metadata ladění a nástroje pro pozorování nemohly zahltit procesor a paměť, když se začnou hromadit chyby.

4. Zkontrolujte způsoby selhání v modulech proxy serveru jádra
   Systematicky kontrolujte, jak se jednotlivé interní moduly chovají při neočekávaném vstupu nebo konfiguraci, a zajistěte ladnou degradaci namísto globálního selhání.

5. Zpřesněte zavádění a izolaci
   Ačkoli incident není rozepsán do velkých podrobností, naznačuje, že společnost Cloudflare bude pravděpodobně dále segmentovat, jak se šíří nové konfigurace a chování DB, aby se snížila pravděpodobnost, že jediná špatná změna ovlivní celou flotilu.

Incident také zarámovali jako absolutní selhání svých očekávání ohledně odolnosti, označili ho za "nepřijatelný" a výslovně uznali bolest, kterou způsobil zákazníkům i běžným uživatelům internetu. Blog společnosti Cloudflare

Poučení pro týmy infrastruktury a SRE

I když neprovozujete něco tak obrovského jako společnost Cloudflare, z tohoto výpadku vyplývá několik velmi praktických ponaučení pro návrh a provoz:

S interní konfigurací zacházejte jako s nedůvěryhodným vstupem.

Je snadné předpokládat, že "naše" generovaná konfigurace je vždy správná. Včerejší den ukázal, proč je to nebezpečné:

• Před použitím konfiguračních souborů vždy ověřte jejich velikost, tvar a omezení.

• Zvažte nejprve kanárkovou aplikaci konfigurace na malou podmnožinu provozu nebo uzlů s automatickým vrácením při anomáliích.

• Udržujte přísné horní hranice a omezovače počtu funkcí, předalokování paměti a využití procesoru.

Navrhněte systém pro postupné částečné selhání

Jedna chyba v modulu Bot Management by neměla být schopna způsobit paniku celé cesty proxy serveru:

• Výchozí nastavení fail-open vs. fail-closed v některých vrstvách zabezpečení, pokud je alternativou úplný výpadek.

• Vytvořte jasné, otestované kill switches pro funkce, které nejsou jádrem systému.

• Zajistěte, aby kritické subsystémy (autentizace, stavová stránka, nástroje pro incidenty) mohly fungovat v degradovaném režimu nebo prostřednictvím alternativních cest.

Dodržujte správné signály

Oscilace mezi "dobrou konfigurací" a "špatnou konfigurací" každých pět minut způsobila, že signál vypadal jako útočný provoz nebo hlučné vnější chování:

• Ujistěte se, že máte ve svém potrubí pozorovatelnosti korelaci na verzi nebo na konfiguraci.

• Vytvořte ovládací panely, které vizuálně zviditelní změny konfigurace na grafech chyb.

• Zahrňte silné syntetické testy z vnějšího pohledu, abyste mohli rychle rozlišit interní selhání od problémů se sítí/cestou.

Nevkládejte všechna vajíčka do jednoho infračerveného košíku

Pro organizace používající službu Cloudflare:

• Pro skutečně kritické vlastnosti zvažte nastavení více sítí CDN.

• Vyhněte se tomu, aby vaše stavová stránka byla zcela závislá na stejném poskytovateli jako váš primární zásobník (Cloudflare to dělá, ale včera se shodou okolností vyskytly potíže s hostitelem jejich stavové stránky, což věci ještě více zamotalo). BlogCloudflare+1

• Dvakrát si rozmyslete, než pevně spojíte autentizaci, řídicí roviny API a doručování frontendů se stejným dodavatelem bez záložních cest.

Širší pohled

Jen za posledních několik měsíců jsme byli svědky velkých výpadků v Microsoft Azure, Amazon Web Services a nyní i Cloudflare, které dočasně vyřadily z provozu velké části spotřebitelských i podnikových služeb. AP News+2TheWashington Post+2

Vzorec je jasný:

• Internet je stále více závislý na několika obřích poskytovatelích infrastruktury.

• Výpadky si často způsobují sami, a to spíše v důsledku složitých interních změn než v důsledku vnějších útoků.

• Dokonce i poskytovatelé s prvotřídními postupy SRE mohou být stále vyvedeni z míry neočekávanými interakcemi mezi konfigurací, chováním databází a pevně zakódovanými limity.

Včerejší incident společnosti Cloudflare je jasnou připomínkou toho, že "cloud" není magie. Ve své podstatě je to stále software napsaný lidmi, který podléhá stejným třídám chyb jako jakákoli jiná aplikace - jen na něm závisí řádově více lidí.

Uživatelé si tento incident budou většinou pamatovat jako "to ráno, kdy se nenačetl X a ChatGPT".
Pro inženýry bude pravděpodobně studován jako učebnicový příklad toho, jak se jemné konfigurační chyby v jádru distribuovaného systému mohou rozšířit do globální internetové události.