Основний збій у роботі Cloudflare 18 листопада - підсумок

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

Нижче наведено детальний огляд того, що сталося під час вчорашнього збою в роботі Cloudflare (18 листопада 2025 року), чому це сталося, кого це торкнулося і які уроки інфраструктурні команди повинні винести з цього.

Що насправді сталося вчора?

У вівторок, 18 листопада 2025 року, близько пізнього ранку за UTC, Cloudflare почав повертати велику кількість серверних помилок HTTP 5xx для трафіку, що проходив через його мережу. Для кінцевих користувачів це означало сторінки "Внутрішня помилка сервера" або "Помилка шлюзу" при спробі отримати доступ до багатьох популярних веб-сайтів та додатків.

Згідно з власним блогом 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 , зафіксували тисячі одночасних повідомлень про збої на піку. Агентство Reuters повідомило про 5 000 постраждалих користувачів тільки для X в один момент, перш ніж кількість користувачів зменшилася в міру того, як були впроваджені виправлення. Reuters

З точки зору користувачів, це виглядало наступним чином:

• Сайти взагалі не завантажувалися

• Потоки входів зависали або не працювали (особливо там, де були задіяні 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 використовує "файл конфігурації"

   • Модель виявлення ботів у Cloudflare базується на наборі "ознак" - сигналів про кожен запит, які використовуються для визначення того, чи це людина, чи бот.

   • Ці ознаки об'єднані в конфігураційний файл, який оновлюється кожні кілька хвилин і розгортається по всьому світу, тому Cloudflare може швидко адаптуватися до нових шаблонів атак. Блог Cloudflare

2. Зміна в поведінці запитів ClickHouse

   • Файл функцій генерується за допомогою запитів до бази даних ClickHouse.

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

   • Запит, який створює список функцій, не фільтрував за назвою бази даних; раптом він почав отримувати дублікати стовпців як зі схеми за замовчуванням, так і з r0, фактично подвоївши кількість рядків функцій.

3. Файл функцій збільшився в розмірі

   • Модуль керування ботами має жорстке обмеження на кількість елементів, які він може прийняти (встановлено на 200, що значно перевищує ~60, які зазвичай використовуються).

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

4. Основні проксі-сервіси почали повертати помилки 5xx

   • Оскільки управління ботами інтегровано в основний проксі-шлях, паніка з'явилася у вигляді відповідей HTTP 5xx для будь-якого трафіку, який залежав від цього модуля.

   • На новому движку FL2 клієнти бачили явні помилки 5xx.

   • На старому движку FL оцінка ботів непомітно обнулялася, що могло призвести до помилкових спрацьовувань правил блокування ботів. Блог Cloudflare

5. Найнеприємніша частина: файл постійно перемикався між "хорошим" і "поганим"

   • Кластер ClickHouse поступово оновлювався, і файл функцій регенерувався кожні п'ять хвилин.

   • Іноді запит виконувався на оновлених вузлах (створюючи поганий файл), іноді на неоновлених (створюючи хороший файл).

   • Це означало, що деякий час мережа Cloudflare коливалася між нормальною роботою і відмовою, оскільки поширювалися різні версії файлу. Блог Cloudflare

Це коливання зробило ситуацію надзвичайно заплутаною зсередини. Спочатку команда Cloudflare запідозрила масовану DDoS-атаку, оскільки характер помилок не був схожий на простий збій програмного забезпечення. Навіть на сторінці статусу Cloudflare, яка розміщена за межами їхньої власної інфраструктури, ненадовго з'явилися помилки - збіг, який ще більше підживлював підозру про зовнішню атаку. Блог Cloudflare Blog+1

Лише після того, як вони зрозуміли, що спільним фактором був функціональний файл бота, картина прояснилася.

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

На основі посмертних звітів Cloudflare та звітів третіх сторін ми можемо скласти приблизну хронологію подій до 18 листопада 2025 року: Блог Cloudflare+2ThousandEyes+2

• 11:05 UTC - У ClickHouse розгорнуто зміну контролю доступу до бази даних.

• 11:20-11:30 UTC - Починають генеруватися та розповсюджуватися погані версії файлу функції управління ботами.

• 11:28 UTC - Перший вплив на клієнтів: підвищена кількість помилок HTTP 5xx у трафіку клієнтів.

• 11:30-11:32 UTC - Зовнішні інструменти моніторингу та автоматизовані тести починають виявляти періодичні збої.

• 11:35 UTC - Cloudflare відкриває внутрішній дзвінок про інцидент; починається розслідування.

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

• 11:30-13:05 UTC - Команди зосереджуються на тому, що здається погіршеною поведінкою Workers KV, і досліджують кілька можливих причин (включаючи сценарії атак).

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

• 14:30 UTC - Визначено першопричину; зупинено генерацію та розповсюдження поганих функціональних файлів. Вручну вставлено конфігураційний файл з відомими параметрами та перезапущено основний проксі-сервер. Більшість основного трафіку повертається до нормального стану. Блог Cloudflare

• 14:40-15:30 UTC - Проблеми з інформаційною панеллю та входом в систему тривають, оскільки турнікет і відставання спроб автентифікації створюють вторинні сплески навантаження. Блог Cloudflare

• 17:06 UTC - Рівень помилок повернувся до базової лінії; Cloudflare заявляє, що системи повністю нормалізувалися. Блог Cloudflare

З точки зору користувачів, збій був найсильнішим у період з пізнього ранку до раннього дня за UTC, хоча точний час впливу залежав від регіону та продуктів Cloudflare, від яких залежала кожна послуга.

Чому це відключення має таке велике значення

Ризик централізації

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

Цей збій:

• Не стався через збій у маршрутизації BGP або обрив кабелю провайдера.

• Не є наслідком зловмисної атаки (незважаючи на початкові підозри).

• Виникла через помилку в одній конфігурації та обмежень у внутрішньому компоненті.

Це важливо, тому що це показує, як складні, тісно пов'язані системи можуть катастрофічно вийти з ладу навіть без зовнішнього втручання. Коли багато організацій покладаються на одного провайдера, цей провайдер де-факто стає системно важливою частиною інтернету.

"М'які" залежності теж постраждали

Деякі з постраждалих сервісів не просто використовували Cloudflare як німий CDN. Вони використовували його:

• Використання Cloudflare Access для аутентифікації та доступу з нульовою довірою.

• Використання Workers KV як частини внутрішнього контролю.

• Використання Turnstile для ботостійких входів. Блог Cloudflare Blog+1

Коли ці продукти вийшли з ладу, постраждав не лише вміст веб-сайту - логіни, функції адміністрування та внутрішні API також зламалися. Це ускладнює відновлення: ваша сторінка статусу, інструменти для інцидентів або інтерфейс адміністратора також можуть залежати від того самого провайдера, який щойно вийшов з ладу.

Що змінить Cloudflare

У блозі Cloudflare описано кілька кроків з виправлення ситуації, які компанія вже робить, щоб зменшити ризик повторення подібних інцидентів: Блог Cloudflare

1. Посилити захист від потрапляння в організм автоматично згенерованих файлів конфігурації
   Ставтеся до внутрішньо згенерованих конфігурацій з таким же скептицизмом і перевіркою, як і до наданих користувачем, включаючи сувору перевірку схеми і розміру перед розгортанням.

2. Більше глобальних перемикачів вимкнення
   Спростіть швидке вимкнення проблемних внутрішніх модулів (наприклад, керування ботами) у мережі, щоб вони виходили з ладу у відкритому вигляді, а не викликали паніку у всьому проксі-шляху.

3. Захистіть системні ресурси від шторму помилок
   Переконайтеся, що дампи ядра, налагоджувальні метадані та інструменти спостереження не перевантажують процесор і пам'ять, коли кількість помилок починає зростати.

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

5. Вдосконалюйте розгортання та ізоляцію
   Хоча інцидент не описаний в деталях, він свідчить про те, що Cloudflare, ймовірно, ще більше сегментує способи поширення нових конфігурацій і поведінки БД, щоб зменшити ймовірність того, що одна погана зміна вплине на весь флот.

Вони також розцінили інцидент як абсолютний провал їхніх очікувань щодо відмовостійкості, назвавши його "неприйнятним" і чітко визнавши біль, який він завдав як клієнтам, так і звичайним користувачам Інтернету. Блог Cloudflare

Уроки для команд інфраструктури та SRE

Навіть якщо ви не використовуєте щось настільки величезне, як Cloudflare, з цього збою можна винести кілька дуже практичних уроків з проектування та експлуатації:

Ставтеся до внутрішніх конфігурацій як до ненадійних даних

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

• Завжди перевіряйте розмір, форму і обмеження конфігураційних файлів перед їх застосуванням.

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

• Дотримуйтесь суворих верхніх меж і вимикачів щодо кількості функцій, попереднього розподілу пам'яті та використання процесора.

Розробка для м'якого часткового збою

Одна помилка в модулі керування ботами не повинна викликати паніку у всьому проксі-шляху:

• За замовчуванням в деяких рівнях безпеки встановіть режим fail-open проти fail-closed, коли альтернативою є повне відключення.

• Створіть чіткі, протестовані перемикачі вимкнення для непрофільних функцій.

• Переконайтеся, що критичні підсистеми (авторизація, сторінка стану, інструменти для інцидентів) можуть працювати в погіршеному режимі або через альтернативні маршрути.

Дотримуйтесь правильних сигналів

Коливання між "хорошою конфігурацією" і "поганою конфігурацією" кожні п'ять хвилин робить сигнал схожим на трафік атаки або шумну зовнішню поведінку:

• Переконайтеся, що у вашому конвеєрі спостережень є кореляція для кожної версії або конфігурації.

• Створіть інформаційні панелі, які роблять зміни конфігурації візуально очевидними на графіках помилок.

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

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

Для організацій, що використовують Cloudflare:

• Розгляньте можливість використання декількох CDN для справді критично важливих властивостей.

• Уникайте того, щоб ваша сторінка статусу повністю залежала від того ж провайдера, що і ваш основний стек (Cloudflare робить це, але вчора виникла випадкова проблема з їх хостом сторінки статусу, що ще більше заплутало ситуацію). БлогCloudflare + 1

• Подумайте двічі, перш ніж тісно пов'язувати свою автентифікацію, площини управління API і доставку фронтенду з одним і тим же постачальником без запасних шляхів.

Загальна картина

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

Закономірність очевидна:

• Інтернет все більше залежить від жменьки гігантських провайдерів інфраструктури.

• Перебої в роботі часто виникають через складні внутрішні зміни, а не через зовнішні атаки.

• Навіть провайдери з практиками SRE світового класу все ще можуть зіткнутися з несподіваною взаємодією між конфігурацією, поведінкою баз даних і жорстко закодованими обмеженнями.

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

Для користувачів цей інцидент здебільшого запам'ятається як "той ранок, коли X і ChatGPT не завантажилися".
Для інженерів він, швидше за все, буде вивчатися як хрестоматійний приклад того, як ледь помітні помилки конфігурації в ядрі розподіленої системи можуть вилитися в глобальну подію в Інтернеті.