Сбой Cloudflare: Как одна правка в базе данных обрушила сервисы по всему миру

Утро 18 ноября 2025 года для миллионов людей по всему миру выглядело одинаково странно.

Лента X (бывший Twitter) не загружается, ChatGPT и другие ИИ-сервисы отваливаются с ошибками, Spotify молчит, Canva не открывается, сайты транспортных компаний и госорганов ведут себя так, будто интернета нет вовсе. На многих страницах — типичная оранжевая заглушка Cloudflare с ошибкой 5xx.

Под ударом, по оценкам СМИ и самих компаний, оказались:

• X, ChatGPT, Claude, Perplexity;
• Spotify, Canva, Dropbox, Shopify;
• онлайн-игры вроде League of Legends;
• Coinbase и другие финтех-сервисы;
• общественный транспорт и госструктуры — от NJ Transit в США до французской SNCF и британских регуляторов FCA и MI5.

В первые часы соцсети и часть медиа заговорили о гигантской кибератаке. Но уже в тот же день Cloudflare опубликовала технический разбор (post-mortem) и честно признала: никаких хакеров, мы сами сломали себе сеть одной неудачной правкой в базе данных. Давайте разберемся, что произошло, почему это случилось и как избежать таких ситуаций в будущем.

Чтобы понять масштаб, нужно разобраться, чем вообще занимается Cloudflare.

Cloudflare — крупный интернет-инфраструктурный провайдер. Его часто описывают как «CDN и щит для веба», но по сути это целая «облачная сеть связности».

Основные функции Cloudflare

CDN (Content Delivery Network, сеть доставки контента)
Распределенные по миру серверы, которые отдают пользователям копии статического содержимого (картинки, скрипты, стили) с ближайшей точки. Результат — сайты грузятся быстрее.

DNS-хостинг
Обслуживание записей «домен → IP-адрес» с высокой отказоустойчивостью и низкой задержкой. DNS (Domain Name System) — это, по сути, «телефонная книга интернета», которая переводит понятные человеку адреса вроде example.com в числовые IP-адреса серверов.

Обратный прокси (reverse proxy)
Запрос пользователя идет сначала на узел Cloudflare, и только потом — на исходный сервер сайта. По дороге можно:

• отфильтровать вредный трафик;
• закешировать ответы для ускорения;
• спрятать реальный IP исходного сервера сайта.

Защита и фильтрация трафика
DDoS-защита (защита от массовых атак переполнением запросами), веб-файрвол (WAF — Web Application Firewall), Bot Management (управление ботами — борьба с вредоносными автоматическими запросами), защита API, системы аутентификации (Cloudflare Access, Turnstile) и т.д.

По оценкам Cloudflare и независимых аналитиков, через инфраструктуру компании проходит трафик примерно пятой части всех сайтов в интернете.
Поэтому когда Cloudflare «падает», это выглядит как частичный «блэкаут» интернета: тысячи независимых сайтов оказываются завязаны на одну точку отказа.

По шагам разберемся, что именно пошло не так.

Кто за что отвечает внутри Cloudflare

Каждый HTTP (S)-запрос к сайту за Cloudflare проходит примерно такой путь:

TLS/HTTP-слой — устанавливается защищенное соединение (HTTPS), разбираются заголовки и путь запроса.

Core proxy (основной прокси, FL / FL2) — главный «конвейер», написанный на Rust, где по очереди отрабатывают модули:

• кеш;
• система защиты от DDoS;
• WAF (веб-файрвол);
• Bot Management (управление ботами);
• переадресация трафика на Workers, R2 и т. п.

Обращение к origin-серверу — если ответа нет в кеше, FL/FL2 устанавливает соединение с исходным сервером. Для этого Cloudflare использует отдельную подсистему/proxy-инфраструктуру, построенную на Pingora (Rust-фреймворк и HTTP-прокси, который сейчас заменил NGINX и обслуживает значительную часть трафика).

Bot Management — один из этих модулей. Это система, которая с помощью машинного обучения пытается определить, кто перед нами: живой человек, «хороший» бот (например, поисковый робот Google) или вредный бот (скрейпер, программа для взлома паролей и т. п.).

Модель принимает на вход набор признаков (features): технические характеристики запроса — заголовки, поведение соединения, параметры клиента, IP-метаданные и т. д. Эти признаки описываются в специальном конфигурационном feature-файле, который пересобирается каждые несколько минут и рассылается на все узлы сети.

Описание признаков хранится в базе ClickHouse — популярной аналитической СУБД, хорошо подходящей для больших объемов логов и телеметрии.

Шаг 1. Изменение прав доступа в ClickHouse

18 ноября около 11:05 UTC инженеры Cloudflare внесли изменение в схему прав доступа в одном из ClickHouse-кластеров. Цель была правильная: сделать работу распределенных запросов безопаснее, чтобы вместо общего сервисного аккаунта они выполнялись от конкретных пользователей — с более точными лимитами.

До изменения пользователи фактически видели только таблицы в базе default. После — стали «видеть» метаданные таблиц в служебной базе r0, где хранятся реальные данные по шардам (частям распределенной базы).

Шаг 2. Старый запрос — новые последствия

Проблема в том, что код, который собирал список признаков для Bot Management, ходил не в саму таблицу с данными, а в системную таблицу метаданных system. columns:

В system. columns для каждой колонки есть и имя базы (database), и имя таблицы (table). Запрос фильтрует только по имени таблицы; никакого условия по database здесь нет — ни WHERE database = 'default', ни другого ограничения.

Пока у пользователя были права только на базу default, это было «безопасным» допущением: из system. columns возвращались только колонки этой базы, и запрос работал как задумано.

После изменения прав стали видны и служебные таблицы в базе r0. Для них тоже есть таблица http_requests_features, поэтому запрос начал возвращать дубликаты колонок — сразу из default и из r0.

В результате количество признаков, попадающих в feature-файл, выросло больше чем вдвое. Этот файл по-прежнему пересобирался каждые несколько минут и рассылался по всей сети Cloudflare — только теперь уже с раздутым списком признаков.

Шаг 3. Жесткий лимит и «паника» в прокси

Модуль Bot Management внутри прокси рассчитывал, что признаков не будет слишком много. Для оптимизации памяти там стоял лимит: не больше 200 признаков — с приличным запасом относительно фактических ~60.

Когда «раздутый» конфиг с превышением лимита попал на узлы, сработал защитный код на Rust, на котором написан прокси. Проверка выглядела примерно так: если признаков больше 200 — возвращается ошибка. Но дальше поверх нее использовался небезопасный прием unwrap () —команда «мне обещали, что ошибки не будет, можно не проверять».

В Rust это приводит к panic — аварийному завершению потока, аналог жесткого assert в других языках программирования. Паника внутри рабочего потока core proxy означает: поток, обслуживающий запросы, просто падает. А пользователь видит HTTP 5xx — ошибку сервера.

Часть клиентов уже была мигрирована на новый движок FL2 — там падал сам прокси и пользователи получали ошибки. На старом FL (где код вел себя иначе) запросы не падали, но бот-оценки становились некорректными (все получало «0»), ломая антибот-правила.

Шаг 4. Почему система то падала, то вставала

Ситуацию сильно усложнило то, что кластер ClickHouse обновлялся постепенно, а не «разом».

Запрос, генерирующий feature-файл, то попадал на уже обновленную ноду (узел сети, давая «плохой» конфиг), то на старую (давая «хороший»). В итоге:

• каждые несколько минут по сети рассылался то нормальный, то ошибочный конфиг;
• прокси то «оживал», то снова уходил в 5xx.

Снаружи это выглядело очень похоже на масштабную DDoS-атаку: всплески ошибок, нестабильность, плюс в это же время по совпадению перестала работать статус-страница Cloudflare (она вообще размещена у стороннего провайдера), что только усилило ощущение, что «нас атакуют со всех сторон».

Шаг 5. Как удалось остановить аварию

По официальному таймлайну Cloudflare:

• 11:05 UTC — выкатывается изменение прав в ClickHouse.
• 11:20−11:28 — начинаются массовые 5xx-ошибки, пользователи видят страницы с ошибкой Cloudflare.
• 11:32−13:05 — команда ищет причину, сначала подозревая проблемы в Workers KV и аномальный трафик (версии про DDoS).
• 13:05 — для Workers KV и Cloudflare Access включают обходной путь, чтобы снизить влияние.
• 14:24−14:30 — останавливают генерацию и распространение нового feature-файла Bot Management, в очередь вручную кладут последнюю «правильную» версию и перезапускают core proxy; основной трафик приходит в норму.
• 17:06 — добивают «длинный хвост», перезапуская застрявшие сервисы; Cloudflare заявляет, что все системы работают нормально.

В своем посте CEO Мэттью Принс называет это «худшим нашим сбоем с 2019 года» и отдельно подчеркивает, что никакой атаки не было — только внутренняя конфигурационная ошибка.

Несмотря на первые заголовки и догадки, Cloudflare в официальном разборе говорит довольно однозначно:
«Проблема не была вызвана ни прямой, ни косвенной кибератакой или злонамеренной активностью. Все началось с изменения прав в нашей базе данных».

Крупные медиа (Financial Times, AP и др.) со ссылкой на Cloudflare подтверждают: речь о внутренней ошибке конфигурации и бага в модуле Bot Management, который не выдержал необычно большого конфигурационного файла.

Разные источники оценивают масштаб так: десятки тысяч сайтов и сервисов по всему миру испытывали от серьезной деградации до полной недоступности. Среди ключевых пострадавших:

• X, ChatGPT, Claude, Perplexity;
• Spotify, Canva, Dropbox, Shopify;
• League of Legends и другие онлайн-игры;
• Coinbase, Moody’s и другие финансовые сервисы;
• транспортные системы (NJ Transit, SNCF) и регуляторы (FCA, MI5).

Как это выглядело для пользователей

Последствия для бизнеса

• задержки онлайн-продаж и неработающие платежи;
• сорванные мероприятия (пример — сорванный вебкаст квартальной отчетности Home Depot);
• репутационный удар по Cloudflare и по компаниям, которые завязаны на одного инфраструктурного провайдера (акции Cloudflare в день инцидента просели).

На уровне индустрии инцидент стал еще одним напоминанием о хрупкости централизованной инфраструктуры — после недавних сбоев, связанных, например, с AWS, Microsoft Azure или громким провалом обновления у CrowdStrike.

В России Cloudflare сейчас используется ограниченно, в том числе из-за решений регулятора. Напомним коротко, как развивались отношения между российскими властями и сервисом — по официальным заявлениям и профильным материалам.

TLS ECH и претензии РКН

Осенью 2024 года Cloudflare включила по умолчанию поддержку TLS ECH (Encrypted Client Hello) для клиентов CDN.

Что такое TLS ECH?

• При установке HTTPS-соединения клиент сначала отправляет сообщение Client Hello — начальное «рукопожатие» с сервером.
• В нем, среди прочего, содержится поле SNI (Server Name Indication) — имя домена, к которому идет запрос (например, blocked-site.com).
• ECH шифрует эту часть, и провайдеру становится сложнее понять, к какому именно домену обращается пользователь — он видит только, что идет подключение к Cloudflare.

Для пользователя это плюс к приватности. Для российской системы блокировок доменов — серьезная проблема: блокировать «по имени сайта» на уровне оператора связи становится существенно сложнее.

2 апреля 2025 года Роскомнадзор через свои структуры рекомендовал владельцам российских сайтов отказаться от использования TLS ECH в Cloudflare или вообще от сервиса, мотивируя это тем, что ECH «может использоваться для обхода ограничений доступа к запрещенному контенту и нарушает российское законодательство».

В формулировках РКН ECH прямо называют «средством обхода блокировок».

Внесение Cloudflare в реестр ОРИ

В феврале 2025 года Роскомнадзор принудительно внес Cloudflare в реестр организаторов распространения информации (ОРИ).

ОРИ — статус для интернет-компаний, который накладывает на них дополнительные обязательства по российскому законодательству.
Это значит, что на сервис возложены обязанности:

• хранить данные российских пользователей в течение установленного срока;
• по запросу уполномоченных органов предоставлять информацию, включая переписку и трафик (в рамках российского законодательства об ОРИ).

До этого, по данным Интерфакса и Forbes, Cloudflare дважды штрафовали за неисполнение требований уведомить РКН о начале работы в статусе ОРИ.

Ограничение трафика: позиция Cloudflare и реакция РКН

С июня 2025 года начинается новый этап конфликта. По данным самой Cloudflare, с 9 июня 2025 года российские операторы связи начали систематически ограничивать доступ к сайтам и сервисам, защищенным Cloudflare.

Что такое ограничение трафика (throttling)?
Это когда интернет-провайдер искусственно замедляет или обрезает передачу данных для определенных сайтов или сервисов, делая их работу крайне медленной или невозможной.

В официальном блоге компания пишет, что:

• соединения из России до ресурсов за Cloudflare ограничиваются на уровне местных интернет-провайдеров (ISP);
• анализ внутренних данных и внешние отчеты показывают, что во многих случаях передается только первые ~16 КБ данных, после чего соединение обрывается;
• такая тактика делает современные сайты «практически непригодными к использованию» — страница может начать загружаться, но не успевает подтянуть стили, скрипты и динамический контент.

Для сравнения: обычная веб-страница весит от нескольких сотен килобайт до нескольких мегабайт, так что ограничение в 16 КБ фактически делает нормальную работу невозможной.

Эту картину подтверждают разборы в профильных медиа (BleepingComputer, SecurityBoulevard, Cybernews и др.), опирающиеся на те же технические детали: ограничение объема данных примерно до 16 КБ, рост числа разрывов TCP-соединений и ошибок HTTP/3.

Роскомнадзор, в свою очередь, через прессу отрицает причастность к перебоям и выдвигает версию о «технических проблемах самого Cloudflare», параллельно рекомендуя компаниям использовать инфраструктуру российских хостинг-провайдеров.

Как бы там ни было, факт, который обе стороны по сути признают косвенно: доступ к сайтам за Cloudflare из России серьезно деградировал с июня 2025 года, и это не похоже на случайный сбой.

Что это значит для российского бизнеса

Профильные российские издания и эксперты отмечают, что Cloudflare долгое время широко использовали в России — и как CDN, и как защиту от DDoS.

Отказ от него обычно приводит к ряду изменений:

• переход на отечественные или альтернативные CDN и DNS-провайдеров;
• дополнительные расходы и время на перестройку инфраструктуры;
• заметное снижение защиты и производительности, особенно для зарубежной аудитории.

Все это накладывается на глобальные технические риски, вроде недавней аварии, и создает для российских проектов двойную уязвимость — регуляторную и инфраструктурную.

Если смотреть на инцидент без оценок, причины сбоя складываются в такую цепочку.

1. Человеческая ошибка в конфигурации

Изменение прав доступа в ClickHouse было по замыслу полезным, но не были пересмотрены старые запросы, которые при новых правах начинают вести себя иначе. В частности, запрос к system. columns внезапно стал возвращать больше строк.

Это классический пример технического долга — когда код написан с упрощающими предположениями, которые когда-нибудь обязательно нарушатся.

2. Неявные допущения в коде

Конфигурация опиралась на запрос:

Код предполагал, что в системе только одна база (default). Фильтров по database не было, и это работало до изменения прав доступа. Такая логика — классический хрупкий контракт: он держится, пока среда остается прежней.

3. Отсутствие жесткой валидации внутренних конфигов

Feature-файл генерировался внутренним сервисом на основе данных ClickHouse, и считалось, что он заведомо корректен. Никаких строгих проверок на:

• максимальное количество признаков;
• максимальный размер файла;
• аномальные значения.

На пути от генерации до раскатки по сети не было — или они были недостаточными. Валидация пользовательского ввода традиционно делается тщательно, а вот внутренние конфиги часто воспринимаются как «доверенные». Здесь это сыграло злую шутку.

4. Некорректное поведение модуля при ошибке

Лимит в 200 признаков — разумная защита от чрезмерного потребления памяти. Но при его превышении модуль не перешел в режим graceful degradation (изящная деградация — мягкий отказ с сохранением основного функционала), а ушел в panic:

• panic в Rust — намеренное аварийное завершение, сигнал «что-то пошло настолько не по плану, что продолжать нельзя»;
• из-за unwrap () на ошибочном результате рабочий поток прокси падал, и пользователи видели 5xx.

В идеале модуль бот-фильтрации в такой ситуации должен был:

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

Это как если бы при поломке стеклоочистителя на машине двигатель полностью заглох, вместо того чтобы продолжить ехать просто без «дворников».

5. Ограниченный контроль зоны поражения

Feature-файл пересобирался и раскатывался по сети часто и быстро, без достаточных канареечных этапов и автоматического отката по аномалиям.

Канареечное развертывание (canary deployment) — практика, когда обновление сначала выкатывается на небольшую часть серверов (1−5%), и если там все работает нормально, только тогда распространяется дальше. Название пошло от шахтерских канареек: птиц брали в шахты для раннего обнаружения ядовитых газов.

В результате ошибка в одном кластере ClickHouse достаточно быстро превратилась в проблему глобального масштаба, а не локальный инцидент в паре дата-центров.

Что обещает Cloudflare

Cloudflare уже публично пообещала:

• «ужесточить обработку конфигурационных файлов, даже если они генерируются самим Cloudflare»;
• добавить больше глобальных аварийных выключателей (kill-switches) для функциональных модулей;
• пересмотреть все сценарии отказа в core proxy;
• исключить ситуации, когда дампы памяти для отладки и отладочная телеметрия сами создают дополнительную нагрузку и усугубляют аварию.

Для владельцев сайтов и продуктов

Не кладите все яйца в корзину одного провайдера
Если бизнес критично зависит от онлайна, стоит рассмотреть:

• multi-CDN (Cloudflare + еще один CDN — например, Fastly, Akamai);
• резервного DNS-провайдера;
• возможность аварийного вывода домена из-под Cloudflare (прямой DNS на origin, второй фронт и т. п.).

Пропишите план на случай падения инфраструктурного провайдера
Не только Cloudflare, но и любого другого. В плане должно быть указано:

• кто принимает решение о переключении;
• какие записи DNS меняются и с какими TTL (время жизни DNS-записей — чем меньше TTL, тем быстрее изменения распространятся по интернету);
• какие сервисы спасаем в первую очередь (платежи, логин, API).

Следите не только за своими метриками, но и за статусом провайдеров
Подпишитесь на:

• статус-страницу Cloudflare;
• независимые мониторинги (Downdetector и аналоги);
• профессиональные чаты и сообщества DevOps/SRE.
• Это позволит быстрее понять, что проблема глобальная, а не только «у нас все упало» — и не тратить время на поиск несуществующих багов в своем коде.

Имейте план коммуникаций с пользователями
Людям обычно все равно, кто виноват — DDoS, Cloudflare или «космические лучи». Им важно:

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

Для инженеров и SRE

Относитесь к внутренним конфигурациям как к недоверенным данным
Любой конфиг, который меняет поведение ядра системы, должен:

• проходить строгую валидацию по схеме (JSON Schema, Protobuf и т. п.);
• иметь лимиты по размеру и количеству элементов;
• тестироваться на канареечных развертываниях с автоматическим откатом по аномалиям.

Принцип «доверяй, но проверяй» работает и в коде — даже если данные приходят из «своего» сервиса.

Проектируйте fail-soft, а не fail-hard
Если модули вроде Bot Management или экспериментальные аналитические инструменты дают сбой, они должны отключаться «без шума» — не затрагивая основную работу системы по обработке запросов.

Fail-soft (мягкий отказ) — это когда система продолжает работать с ограниченным функционалом при частичном отказе компонентов, вместо полного падения.

Перепроверьте скрытые допущения в запросах к базам и сервисам
Все, что полагается на «по умолчанию у нас всегда одна база / один тип записей / одна конфигурация», следует рассматривать как потенциальную мину замедленного действия — особенно если вокруг ведутся работы по изменению прав и архитектуры.

Проверьте старый код на предмет «что будет, если окружение изменится?»

Проводите регулярные учения
Отыграйте всей командой аварийные сценарии:

• «упал CDN»;
• «сломался DNS-провайдер»;
• «отрубился Bot Management»;
• «главная база данных недоступна».

Все эти сценарии должны быть не сюрпризом, а отрепетированной рутиной. Только так команда научится действовать быстро и слаженно в реальном инциденте.

Для российских проектов

Оценивайте не только технический, но и регуляторный риск Cloudflare
На одной чаше весов:

• претензии РКН к TLS ECH и рекомендации отказаться от Cloudflare;
• включение в реестр ОРИ и связанные с этим обязательства;
• фактическое ограничение трафика с июня 2025 года.
• Это не баг, а политико-техническая реальность, которая вряд ли изменится в обозримом будущем.

Если ваша основная аудитория в России, то много-CDN и/или отдельный стек под российский трафик становится необходимостью.
Один из рабочих подходов:

• держать инфраструктуру для российской аудитории на локальных CDN и хостингах (например, облачные провайдеры с инфраструктурой в РФ);
• а для остального мира использовать Cloudflare и другие глобальные решения;
• использовать geo-routing (географическую маршрутизацию): российские пользователи идут через российский CDN, остальные — через Cloudflare.

Считайте стоимость миграции заранее
Переезд с Cloudflare «в пожарном режиме" — когда он одновременно испытывает глобальные сбои и попадает под локальные ограничения — будет дороже и больнее, чем планомерный переход по собственному графику.

Заложите в бюджет:

• время инженеров на миграцию;
• возможное увеличение затрат на CDN;
• временное снижение производительности;
• дополнительные инструменты мониторинга и защиты.

Авария 18 ноября — отличный учебный кейс для инженеров и управленцев.

• Технически — это история про ClickHouse, один запрос к system. columns, конфигурационный файл для Bot Management и Rust-код с unwrap (), который превратил превышение лимита в массовые 5xx по всему миру.
• Системно — напоминание, насколько интернет завязан на нескольких инфраструктурных игроков, и как ошибка в одном месте может повлиять на десятки тысяч независимых сервисов.
• Для России — дополнительный маркер того, что технические риски здесь накладываются на регуляторные: Cloudflare одновременно и критически важен для быстрой и безопасной работы сайтов, и находится под серьезным давлением со стороны государства.

Для бизнеса вывод максимально приземленный: если вы завязаны на интернет, вы уже завязаны на чужую инфраструктуру. Значит, план «что мы делаем, когда она падает или ограничивается» — обязательная часть архитектуры, наравне с бэкапами и мониторингом.

Никакая компания не застрахована от ошибок. Cloudflare — один из самых надежных и профессиональных игроков на рынке, но даже у них случаются такие сбои. Это не повод отказываться от использования CDN и защитных сервисов, но отличный повод задуматься о резервировании критической инфраструктуры и планах на случай ее отказа.

Для тех, кто хочет лучше разобраться в технических деталях:

CDN (Content Delivery Network) — сеть серверов, распределенных географически, которые кешируют и доставляют контент пользователям с ближайшего узла.

DDoS (Distributed Denial of Service) — атака, при которой множество компьютеров одновременно отправляют запросы на сервер, перегружая его и делая недоступным для нормальных пользователей.

TTL (Time To Live) — время жизни DNS-записи; определяет, как долго информация хранится в кеше до следующего обновления.
Origin — исходный сервер, на котором физически хранится сайт, в отличие от CDN-узлов.

WAF (Web Application Firewall) — межсетевой экран для веб-приложений, защищающий от типичных атак (SQL-инъекции, XSS и др.).

Прокси-сервер (Proxy) — промежуточный сервер, через который проходят запросы между клиентом и целевым сервером.

Постмортем (Post-mortem) — детальный разбор инцидента после его устранения; документ, описывающий что пошло не так, почему и как это исправить.

SRE (Site Reliability Engineering) — инженерная дисциплина, применяющая принципы разработки ПО к задачам эксплуатации инфраструктуры.

Panic — в языке программирования Rust это аварийное завершение программы при критической ошибке, когда продолжение работы невозможно.

ClickHouse — колоночная СУБД для аналитики больших данных с открытым исходным кодом.

Feature (признак) — характеристика, используемая в машинном обучении для принятия решений.

Graceful degradation (изящная деградация) — способность системы продолжать работать с ограниченным функционалом при частичном отказе компонентов.

Canary deployment (канареечное развертывание) — метод развертывания, при котором обновление сначала выкатывается на небольшую часть инфраструктуры для проверки.

Throttling (ограничение трафика) — искусственное замедление или обрезание передачи данных.

Edge (граничные узлы) — серверы сети, расположенные близко к конечным пользователям.

Geo-routing (географическая маршрутизация) — направление трафика на разные серверы в зависимости от географического положения пользователя.

Для тех, кто хочет глубже понять темы, затронутые в статье:

Об инцидентах и их разборе

• Google SRE Book — бесплатная книга от Google о том, как строить надежные системы
• Incident Review and Postmortem Best Practices — как правильно проводить постмортемы

О централизации интернета

• «The Internet Is Rotting» — статья The Atlantic о хрупкости современной интернет-инфраструктуры
• Отчеты о предыдущих крупных сбоях: AWS (2017), Fastly (2021), CrowdStrike (2024)

О технологиях защиты приватности

• TLS Encrypted Client Hello (ECH) — подробное объяснение технологии от Cloudflare
• eSNI/ECH and Internet Censorship — статья Electronic Frontier Foundation

О российском интернет-регулировании

• Официальные сообщения Роскомнадзора и ведомственные издания
• Аналитические материалы профильных IT-изданий о развитии регулирования в РФ

Financial Times: ChatGPT and X hit by outage at online security group Cloudflare

The Cloudflare Blog: Cloudflare outage on November 18, 2025

Wikipedia: Cloudflare

AP News: Cloudflare resolves outage that impacted thousands, ChatGPT, X and more

Пикабу: Роскомнадзор против TLS ECH: как технология Cloudflare стала камнем преткновения в Рунете

Habr: РКН рекомендовал владельцам российских интернет-ресурсов отказаться от использования Cloudflare

Ведомости: Роскомнадзор внес Cloudflare в реестр организаторов распространения информации

Interfax: Cloudflare принудительно включена в реестр организаторов распространения информации

The Cloudflare Blog: Russian Internet users are unable to access the open Internet

BleepingComputer: Russia’s throttling of Cloudflare makes sites inaccessible

Рамблер/новости: Россияне жалуются на недоступность многих сайтов: Роскомнадзор отрицает блокировку сервиса Cloudflare

ICT-Online: Эксперты оценили последствия рекомендации РКН отказаться от Cloudflare

Statusfield: Is Cloudflare Down? Current Cloudflare Status & Outages