Ошибка мирового масштаба. Как интернет «лег» из-за сбоя в США и почему он до сих пор такой уязвимый

Изнутри самой Cloudflare ситуация была не менее напряженной. Инженеры сначала заметили симптомы во внутреннем сервисе Workers KV и восприняли это как локальную проблему с производительностью. Однако уже в 11:31 автоматические системы забили тревогу, а в 11:35 был создан отчет об инциденте.

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

Впрочем, уже к 17 часам большинство сервисов ожили, а дашборды Cloudflare вернулись к норме. Пользователи после нескольких часов мемов о «конце интернета» вернулись к привычному скроллингу соцсетей.

«Сегодня произошел худший сбой в работе Cloudflare с 2019 года, — в тот же день написал генеральный директор сети Мэтью Принс, — За последние 6+ лет у нас не было ни одного другого сбоя, который бы вызывал остановку большей части основного трафика через нашу сеть». От имени всей команды Cloudflare Принс извинился «за боль, которую мы сегодня нанесли Интернету».

В то же время в компании отметили, что это не была кибератака. Глобальный коллапс спровоцировало рутинное изменение прав доступа к базе данных, которое инженеры провели еще в 11:05. Это испортило файл конфигурации для системы борьбы с ботами, что привело к краху программного обеспечения, которое управляет трафиком во всей сети.

Но как один файл смог «положить» мировой интернет?

Анатомия сбоя

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

За отсеивание нежелательных гостей отвечает модуль Bot Management, который оценивает каждый запрос с помощью машинного обучения и набора признаков, таких как репутация IP-адреса или поведение браузера. Список этих правил хранится в специальном файле, который автоматически генерируется и рассылается на все серверы сети.

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

Но эти изменения имели неожиданный побочный эффект. Запрос, который формировал файл для бот-менеджера, запрашивал у ClickHouse перечень колонок определенной таблицы, однако не уточнял название самой базы данных. После изменения прав доступа одна и та же логическая таблица стала доступной в двух базах. Система восприняла это буквально и начала возвращать дублированные списки колонок из обоих источников.

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

Настоящий прорыв в расследовании произошел уже после обеда. В 13:05 по Гринвичу (15:05 по киевскому времени) инженеры откатили свой основной прокси-сервер до предыдущей версии, что позволило им восстановить координацию. К 13:37 они удостоверились в том, что причиной инцидента стал файл конфигурации Bot Management. А в 14:24 специалисты окончательно установили причину неприятности.

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

В тот же момент команда остановила автоматическое обновление настроек и принудительно разослала на серверы старую, проверенную версию файла. Эффект был мгновенным: к 14:30 основная волна ошибок спала, а в 17:06 все операции были полностью восстановлены, и проблемы не стало.

Впрочем, сбой 18 ноября наглядно показал, как один-единственный баг в системе фильтрации ботов одной компании может одновременно ударить по поездам во Франции, банкам в США и ИИ-лабораториям по всему миру.

Наступила облачная монополия?

Мы уже писали о похожем случае глобального сбоя в интернете в прошлом месяце. Возник он в глобальной облачной платформе Amazon Web Services 20 октября 2025 года. Тогда регион AWS US-EAST-1 в Северной Вирджинии «лег» более чем на полсуток. Сбой длился более 15 часов, а его причиной, по словам Amazon, стала ошибка в системе управления DNS для базы данных DynamoDB.

В Downdetector подсчитали, что тот инцидент спровоцировал более 17 миллионов отчетов о сбоях в более чем 60 странах мира. Как и Cloudflare месяцем позже, Amazon тогда четко заявила, что это не была кибератака. То есть в обоих случаях глобальный коллапс начинался не со злонамеренного трафика извне, а с внутренней автоматизации и настроек, которые пошли наперекосяк. И это проблема для нас всех.

По оценке W3Techs, в ноябре 2025 года услугами Cloudflare пользовались 81,5% сайтов, которые полагаются на службу обратного прокси-сервера — это 20,4% от всех веб-сайтов мира в целом.

Amazon Web Services, по данным Statista, контролирует около 30% мировой облачной инфраструктуры. Вместе с Microsoft Azure (20%) и Google Cloud (13%) эта «большая тройка» держит в своих руках более 60% глобального рынка. И если в дата-центре кого-то из них произойдет сбой, он мгновенно перекинется на львиную долю приложений и потребительских сервисов по всей планете.

Эксперты годами предупреждали об опасности того, что слишком уж большая часть критической инфраструктуры оказалась в руках мизерного количества компаний. Еще в 2018 году исследователи из университета Карнеги-Меллон опубликовали труд О, какую хрупкую паутину мы плетем. Проанализировав 100 тысяч самых популярных сервисов, они обнаружили, что более 73% из них станут уязвимыми, если упадет небольшое количество сторонних провайдеров. Авторы подсчитали, что проблемы в топ-10 CDN или DNS-провайдеров могут «выключить» от четверти до половины популярных веб-сервисов. И это данные семилетней давности: сегодня, вероятно, уровень зависимости еще выше.

«Интернет был разработан как устойчивая система, — объясняет изданию The Guadian Сьюлетт Дрейфус, преподавательница вычислительной техники и информационных систем в Мельбурнском университете, — существовало много других каналов для обхода проблем или атак, но мы потеряли часть этой устойчивости, став настолько зависимыми от нескольких гигантских технологических компаний, которые предоставляют не только услуги хранения данных, но и услуги по обработке данных».

Главный аналитик Forrester Research Брент Эллис оценивает общие убытки от сбоя Cloudflare в более 250 млн долларов для всех пострадавших предприятий (в перечне есть ChatGPT, X, Spotify и другие). В частности платформа для создания онлайн-магазинов Shopify потеряла более 4 млн долларов США. Самой же Cloudflare инцидент обошелся в почти 1,8 млрд долларов США рыночной стоимости.

Как решить проблему

Гендиректор Cloudflare Мэттью Принс заявил, что отныне компания будет относиться к автоматически сгенерированным внутренним файлам с таким же подозрением, как и к опасным данным извне. Кроме того, инженеры добавляют глобальные «аварийные выключатели», чтобы в случае проблем можно было мгновенно отключить только один модуль (как тот же Bot Management), не кладя при этом всю сеть.

«Такой сбой, как сегодня, неприемлем», — подчеркнул Принс.

Однако бизнесу советуют не возлагать все надежды только на работу над ошибками техногигантов. Например, латформа для мониторинга цифровых сервисов Catchpoint рекомендует разделять риски: мол, компании, которые используют стратегию multi-CDN (одновременное использование нескольких провайдеров доставки контента), в случае чего способны переключить трафик за считанные секунды, в отличие от клиентов с одним провайдером, чья работа парализуется.

Важно и то, как производителям организовать работу своих гаджетов, когда падают серверы. Как писал The Guardian, в день сбоя AWS владельцы «умных кроватей» Eight Sleep обнаружили, что не могут настроить температуру или положение матраса — а все потому, что приложение зависело от дата-центра US-EAST-1. И когда там произошел сбой, пользователи потеряли возможность регулировать базовые функции.

Впоследствии Eight Sleep выпустила обновление с «режимом сбоя», которое позволяет управлять кроватью через Bluetooth, даже если интернет исчез. Однако техностартап Ditto, предоставляющий базу данных для приложений в режиме реального времени, назвал это типичным примером того, как делать не следует. Вместо этого он продвигает архитектуру offline-first: согласно ей, устройства должны работать локально по умолчанию, а с облаком соединяться, только «когда это полезно».

Тем временем на «облачных гигантов» уже обратили внимание регуляторы. 18 ноября Еврокомиссия начала три расследования в рамках Закона о цифровых рынках (DMA). Брюссель хочет выяснить, стоит ли считать Amazon и Microsoft «гейткиперами», которые контролируют доступ к цифровой экономике. Если да — компаниям дадут полгода на то, чтобы «обеспечить полное соответствие своих определенных услуг облачных вычислений обязательствам DMA».

«Мы также рассмотрим, нужно ли обновлять действующие правила DMA, чтобы Европа могла идти в ногу с быстро развивающимися практиками в облачном секторе», — добавляет Тереза Рибера, исполнительный вице-президент по вопросам чистого, справедливого и конкурентного перехода.

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

Иначе следующая неисправность (а это лишь вопрос времени) в очередной раз выключит все и сразу, отрезав население от интернета на неопределенный срок.