Голямото прекъсване на Cloudflare от 18 ноември - обобщение

На 18 ноември 2025 г. огромно парче от интернет се срина.
Ако отворехте ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase или безброй по-малки сайтове, ви посрещаше страница с грешка 5xx с марката Cloudflare - или сайтовете просто не се зареждаха изобщо. Това, което на пръв поглед изглеждаше като поредния голям "интернет е счупен" момент, се оказа нещо по-незабележимо и в някои отношения по-притеснително: грешка, която Cloudflare сама си е причинила дълбоко в собствената си инфраструктура.

По-долу е представен подробен преглед на случилото се при вчерашния срив на Cloudflare (18 ноември 2025 г.), причините за него, засегнатите и поуките, които инфраструктурните екипи трябва да си вземат от него.

Какво всъщност се случи вчера?

Във вторник, 18 ноември 2025 г., около късната сутрин по UTC, Cloudflare започна да връща големи количества грешки на сървъра HTTP 5xx за трафика, който преминаваше през мрежата ѝ. За крайните потребители това означаваше страници "Internal Server Error" (Вътрешна грешка на сървъра) или "Gateway Error" (Грешка на портала) при опит за достъп до много популярни уебсайтове и приложения.

Според собствения блог на Cloudflare след инцидента прекъсването е:

• е започнал да влияе на HTTP трафика на клиентите в 11:28 UTC

• Наблюдавани са широко разпространени грешки 5xx в основните услуги на CDN и сигурността

• Около 13:05-14:30 UTC са предприети важни стъпки за намаляване на въздействието

• Обемът на грешките 5xx се върна към базовото ниво към 17:06 UTC Блогът на Cloudflare

Самата Cloudflare го определи като най-тежкия си прекъсване от 2019 г. насам, защото то не е засегнало само една функция или табло за управление - нарушило е работата на основния прокси слой, който маршрутизира по-голямата част от трафика на клиентите през мрежата ѝ. Блогът на Cloudflare

Мониторингът на трети страни потвърди това. Cisco ThousandEyes видя глобален срив, засягащ Cloudflare, с таймаути и грешки 5xx на услуги като X, OpenAI (ChatGPT) и Anthropic, докато самите мрежови пътища изглеждаха здрави. Това категорично показваше, че става дума за отказ на услугата отзад, а не за проблем на ниво доставчик на интернет или маршрутизация. ThousandEyes

Кой е бил засегнат?

Тъй като Cloudflare се намира пред огромна част от интернет (около 20% от сайтовете в мрежата разчитат на Cloudflare за производителност и сигурност), радиусът на взрива беше огромен. AP News+1

Сред услугите, за които се съобщава, че са засегнати:

• ChatGPT / OpenAI

• X (бивш Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends и други платформи за игри

• Различни сайтове за обществен транспорт и правителствени сайтове, включително New Jersey Transit и цифровите системи на френската железница SNCF AP News+1

Програми за проследяване на прекъсвания като Downdetector регистрираха хиляди едновременни съобщения за проблеми в пиковия момент. Ройтерс съобщи за около 5000 засегнати потребители само за X в един момент, след което броят им намаля с разпространението на поправките. Ройтерс

От гледна точка на потребителите това се изразява в:

• Сайтове не се зареждат изобщо

• блокиране или провал на потоците за влизане в системата (особено когато са били включени Cloudflare Access или Turnstile)

• API отговарят с прекъсвания или с грешки 5xx

• табла за управление и административни панели, които не работят

С други думи: огромни части от интернет "се чувстваха неработещи", въпреки че основната причина беше съсредоточена във вътрешните системи на един доставчик.

Как обикновено работи Cloudflare (с прости думи)

За да разберем защо това прекъсване е било толкова тежко, е полезно да знаем приблизителния път на една заявка през мрежата на Cloudflare.

Cloudflare действа като CDN с обратен прокси сървър и слой за сигурност:

1. Вашият браузър или приложение се свързва с Cloudflare, вместо директно с първоначалния сайт.

2. Cloudflare терминира TLS и HTTP на своя край.

3. Заявките постъпват в основната прокси система на Cloudflare, наречена FL ("Frontline" ) и нейното по-ново поколение FL2.

4. Това основно прокси:

   • прилага правилата на WAF (защитна стена за уеб приложения)

   • Изпълнява модели за управление на ботове

   • обработва DDoS защита, кеширане, изходящи данни към произхода

   • Маршрутизира трафика към други вътрешни продукти като Workers, R2, Access и др. Блогът на Cloudflare

При нормална работа тази архитектура е изключително устойчива: ако един център за данни има проблем, трафикът се пренасочва през други; промените в конфигурацията се въвеждат внимателно; отделните функции трябва да се провалят по ограничени начини.

Вчерашният срив беше именно лош, защото повредата беше вътре в самия общ прокси път и беше тясно свързана с конфигурационен файл, който се разпространява по целия свят често и автоматично.

Основна причина: файл за управление на ботове, който е излязъл от строя

Официалното обяснение на Cloudflare посочва един основен виновник:
файл за конфигурация на функцията, използван от тяхната система за управление на ботове. Блогът на Cloudflare

Ето веригата от събития на разбираем език:

1. Bot Management използва "feature file".

   • Моделът за откриване на ботове на Cloudflare разчита на набор от "характеристики" - сигнали за всяка заявка, които се използват, за да се реши дали тя е човешка или е бот.

   • Тези характеристики са обединени в конфигурационен файл, който се обновява на всеки няколко минути и се разпространява глобално, така че Cloudflare може бързо да се адаптира към нови модели на атаки. Блогът на Cloudflare

2. Промяна в поведението на заявките на ClickHouse

   • Файлът с функции се генерира от заявки към базата данни на ClickHouse.

   • Cloudflare направи промяна около 11:05 UTC, за да подобри сигурността и разрешенията за разпределените заявки - позволявайки на потребителите да виждат метаданни не само от схемата по подразбиране, но и от основните таблици r0. Блогът на Cloudflare

   • Запитването, което изгражда списъка с функции, не филтрираше по името на базата данни; изведнъж то започна да получава дублирани колони както от таблиците по подразбиране, така и от r0, което на практика удвои броя на редовете с функции.

3. Размерът на файла с характеристиките нарасна

   • Модулът за управление на ботове има твърд лимит за броя на функциите, които ще приеме (зададен на 200, което е доста над обичайно използваните ~60).

   • Когато новогенерираният файл надхвърли това ограничение, модулът удари горната граница и изпадна в паника поради необработена грешка в кода на Rust, който използва Result::unwrap() върху стойност за грешка. Блогът на Cloudflare

4. Основните прокси услуги започнаха да връщат грешки 5xx

   • Тъй като Bot Management е интегриран в основния прокси път, паниката изплува като HTTP 5xx отговори за всеки трафик, който зависеше от този модул.

   • При новия двигател FL2 клиентите видяха изрични грешки 5xx.

   • При по-стария двигател FL резултатите за ботове мълчаливо се свеждаха до нула, което можеше да доведе до фалшиви положителни резултати в правилата за блокиране на ботове. Блогът на Cloudflare

5. Наистина неприятната част: файлът продължаваше да се променя между "добър" и "лош"

   • Клъстерът ClickHouse се обновяваше постепенно и файлът с характеристиките се регенерираше на всеки пет минути.

   • Понякога заявката се изпълняваше на актуализирани възли (създавайки лош файл), а понякога на неактуализирани възли (създавайки добър файл).

   • Това означаваше, че за известно време мрежата на Cloudflare се колебаеше между нормална работа и отказ, тъй като се разпространяваха различни версии на файла. Блогът на Cloudflare

Това колебание направи ситуацията изключително объркваща във вътрешен план. Първоначално екипите на Cloudflare заподозряха масирана DDoS атака, тъй като моделът на грешките не приличаше на обикновен софтуерен срив. Дори страницата за състоянието на Cloudflare, която се хоства извън собствената им инфраструктура, за кратко показваше грешки - съвпадение, което допълнително подхрани подозренията за външна атака. Блогътна Cloudflare+1

Едва след като разбрали, че общият фактор е файлът с функциите на бота, картината станала ясна.

Хронология на инцидента

Въз основа на следствието на Cloudflare и докладите на трети страни можем да съставим приблизителна времева линия за 18 ноември 2025 г: Блогът на Cloudflare+2ThousandEyes+2

• 11:05 UTC - В ClickHouse е внедрена промяна в контрола на достъпа до базата данни.

• 11:20-11:30 UTC - започват да се генерират и разпространяват лоши версии на функционалния файл Bot Management.

• 11:28 UTC - Първо въздействие върху клиентите: наблюдават се повишени грешки HTTP 5xx при трафика на клиентите.

• 11:30-11:32 UTC - Външните инструменти за наблюдение и автоматизираните тестове започват да откриват периодични грешки.

• 11:35 UTC - Cloudflare открива вътрешен сигнал за инцидент; започва разследване.

• ~11:48 UTC - Cloudflare публикува актуализация на състоянието, потвърждаваща инцидента. Повторно изпращане на

• 11:30-13:05 UTC - Екипите се съсредоточават върху това, което изглежда като влошено поведение на KV на работниците, и разследват множество възможни причини (включително сценарии за атака).

• 13:05 UTC - Ключово смекчаване: Workers KV и Cloudflare Access са изместени, за да заобиколят основния прокси сървър; въздействието е намалено. Блогът на Cloudflare

• 14:30 UTC - Идентифицирана е първопричината; генерирането и разпространението на файлове с лоши характеристики е спряно. Ръчно се вмъква известен добър конфигурационен файл и се рестартира основното прокси. По-голямата част от трафика на ядрото се връща към нормалното си състояние. Блогът на Cloudflare

• 14:40-15:30 UTC - Проблемите с таблото за управление и влизането в системата остават, тъй като Turnstile и натрупаните опити за удостоверяване създават вторични скокове в натоварването. Блогът на Cloudflare

• 17:06 UTC - Нивото на грешките се връща към изходното ниво; Cloudflare обявява системите за напълно нормални. Блогът на Cloudflare

От гледна точка на потребителите прекъсването се усещаше най-силно в късната сутрин до ранния следобед UTC, въпреки че точните прозорци на въздействие варираха в зависимост от региона и от това от кои продукти на Cloudflare зависи всяка услуга.

Защо това прекъсване е толкова важно

Риск от централизация

Cloudflare е част от малък набор от централни доставчици на интернет инфраструктура, наред с големите облачни платформи (AWS, Azure, GCP) и други големи CDN. Когато някой от тези играчи се провали, въздействието е широкообхватно и често не е очевидно.

Това прекъсване:

• Не е причинен от грешка в маршрутизацията на BGP или от прекъсване на кабел на интернет доставчик.

• Не е причинен от злонамерена атака (въпреки първоначалните подозрения).

• Беше причинен от грешка в конфигурацията и ограниченията на един вътрешен компонент.

Това е важно, защото показва как сложни, тясно свързани системи могат да се провалят катастрофално дори без външна намеса. Когато много организации се основават на един и същ доставчик, този доставчик де факто се превръща в системно важна част от интернет.

"Меките" зависимости също вредят

Някои от засегнатите услуги не са използвали Cloudflare само като "глух" CDN. Те бяха:

• Използваха Cloudflare Access за удостоверяване и достъп с нулево доверие.

• Използвали са Workers KV като част от вътрешните планове за контрол.

• Разчитали са на Turnstile за входни данни, защитени от ботове. Блогътна Cloudflare+1

Когато тези продукти се повредиха, не само съдържанието на уебсайта се срина - сринаха се и влизанията, функциите на администратора и вътрешните API. Това прави възстановяването по-сложно: страницата ви за състоянието, инструментите за инциденти или потребителският интерфейс на администратора може да разчитат и на същия доставчик, който току-що се е провалил.

Какво според Cloudflare ще се промени

В блога на Cloudflare са описани няколко стъпки за отстраняване на нередности, които компанията вече предприема, за да намали риска от повторение на нещо подобно: Блогът на Cloudflare

1. Засилване на поглъщането на автоматично генерирани конфигурационни файлове
   Отнасяйте се към вътрешно генерираните конфигурационни файлове със същия скептицизъм и валидиране, както към предоставените от потребителя входни данни, включително строга проверка на схемите и размерите преди пускането им.

2. Повече глобални изключватели
   Улеснете бързото деактивиране на проблемни вътрешни модули (като Bot Management) в цялата мрежа, така че те да се провалят отворени, вместо да паникьосват целия прокси път.

3. Защита на системните ресурси от бури от грешки
   Уверете се, че изхвърлянията на ядрото, метаданните за отстраняване на грешки и инструментите за наблюдение не могат да претоварят процесора и паметта, когато грешките започнат да се увеличават.

4. Преглед на режимите на отказ в основните прокси модули
   Системно проверявайте как се държи всеки вътрешен модул при неочаквани входни данни или конфигурация и осигурете грациозно влошаване вместо глобален отказ.

5. Усъвършенстване на разгръщането и изолирането
   Макар и да не е разписано в огромни подробности, инцидентът подсказва, че Cloudflare вероятно ще продължи да сегментира начина, по който се разпространяват новите конфигурации и поведението на БД, за да намали шанса една лоша промяна да засегне целия флот.

Те също така оформиха инцидента като абсолютен провал на очакванията си за устойчивост, като го нарекоха "неприемлив" и изрично признаха болката, която е причинил както на клиентите, така и на обикновените интернет потребители. Блогът на Cloudflare

Уроци за екипите по инфраструктура и SRE

Дори и да не управлявате нещо огромно като Cloudflare, в това прекъсване има някои много практични уроци за проектиране и експлоатация:

Третирайте вътрешната конфигурация като ненадежден вход

Лесно е да приемем, че "нашата собствена" генерирана конфигурация е винаги правилна. Вчерашният ден показа защо това е опасно:

• Винаги проверявайте размера, формата и ограниченията на конфигурационните файлове, преди да ги приложите.

• Помислете за "канарско" прилагане на конфигурацията първо към малка подгрупа трафик или възли, с автоматизирано връщане назад при аномалии.

• Поддържайте строги горни граници и прекъсвачи на веригата около броя на функциите, предварителното разпределение на паметта и използването на процесора.

Проектиране на грациозен частичен отказ

Една грешка в модула за управление на ботове не трябва да може да доведе до паника на целия прокси път:

• В някои слоеве на сигурността по подразбиране използвайте fail-open срещу fail-closed, когато алтернативата е пълен срив.

• Изградете ясни, тествани превключватели за спиране на работата за функции, които не са от основно значение.

• Уверете се, че критичните подсистеми (автентификация, страница за състоянието, инструменти за инциденти) могат да работят в режим на влошаване или по алтернативни пътища.

Наблюдавайте правилните сигнали

Колебанието между "добра конфигурация" и "лоша конфигурация" на всеки пет минути направи сигнала да изглежда като трафик от атаки или шумно външно поведение:

• Уверете се, че в конвейера за наблюдение имате корелация по версии или по конфигурации.

• Изградете информационни табла, които правят промените в конфигурацията визуално очевидни върху графиките за грешки.

• Включете силни синтетични тестове от външна гледна точка, за да можете бързо да разграничите вътрешните грешки от проблеми с мрежата/пътя.

Не слагайте всичките си яйца в една инфрачервена кошница

За организации, които използват Cloudflare:

• Обмислете конфигурации с няколко CDN за наистина критични за мисията свойства.

• Избягвайте да правите страницата си за състоянието изцяло зависима от същия доставчик като основния ви стек (Cloudflare прави това, но вчера имаше случайни проблеми с хоста на страницата им за състоянието, което обърка допълнително нещата). Блогътна Cloudflare+1

• Помислете два пъти, преди да обвържете плътно удостоверяването, контролните равнини на API и доставката на frontend с един и същ доставчик без резервни пътища.

По-голямата картина

Само през последните няколко месеца станахме свидетели на големи прекъсвания в Microsoft Azure, Amazon Web Services, а сега и в Cloudflare, които временно извадиха от строя големи части от потребителските и корпоративните услуги. AP News+2TheWashington Post+2

Моделът е ясен:

• Интернет е все по-зависим от няколко гигантски доставчици на инфраструктура.

• Често прекъсванията се причиняват от самите тях, по-скоро от сложни вътрешни промени, отколкото от външни атаки.

• Дори доставчиците с първокласни практики в областта на SRE могат да бъдат спънати от неочаквани взаимодействия между конфигурацията, поведението на базата данни и твърдо кодираните ограничения.

Вчерашният инцидент с Cloudflare е ярко напомняне, че "облакът" не е магия. В основата си това все още е софтуер, написан от хора, който е подложен на същите класове грешки като всяко друго приложение - само че от него зависят с порядък повече хора.

За потребителите инцидентът ще бъде запомнен най-вече като "онази сутрин, когато X и ChatGPT не искаха да се заредят".
За инженерите той вероятно ще бъде изучаван като учебникарски пример за това как фини грешки в конфигурацията на основна разпределена система могат да се превърнат в глобално интернет събитие.