18-й выпуск Cloudflare - резюме

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

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

Что на самом деле произошло вчера?

Во вторник, 18 ноября 2025 года, около позднего утра по Гринвичу, 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

   • Поскольку 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 - Начинают генерироваться и распространяться плохие версии файла функций управления ботами.

• 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

С точки зрения пользователей, перебои были наиболее ощутимы в конце утра - начале дня по Гринвичу, хотя точные окна воздействия зависят от региона и от того, от каких продуктов 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 и доставку фронтенда с одним и тем же поставщиком без запасных путей.

Общая картина

Только за последние несколько месяцев мы стали свидетелями крупных сбоев в работе Microsoft Azure, Amazon Web Services, а теперь и Cloudflare. Все они привели к временному отключению больших кусков потребительских и корпоративных сервисов. AP News+2TheWashington Post+2

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

• Интернет все больше зависит от горстки гигантских поставщиков инфраструктуры.

• Отключения часто происходят сами собой, в результате сложных внутренних изменений, а не внешних атак.

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

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

Для пользователей этот инцидент запомнится в основном как "то утро, когда X и ChatGPT не загрузились".
Инженеры же, скорее всего, будут изучать его как учебный пример того, как тонкие ошибки конфигурации в основной распределенной системе могут вылиться в глобальное интернет-событие.