Сбой Cloudflare: разоблачение псевдодецентрализации в криптоиндустрии

4 крупных сбоя за 18 месяцев: почему централизованный тупик так трудно преодолеть?

Источник: rekt news

Перевод: Saoirse, Foresight News

18 ноября 2025 года, 6:20 утра по восточному времени США. Многие из нас столкнулись с перебоями в работе сети.

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

Twitter внезапно завис во время публикации твита, ChatGPT перестал отвечать на полуслове, Claude просто завис.

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

20% глобального интернета исчезли в одночасье, потому что Cloudflare, который должен был защищать интернет от атак, случайно «атаковал» сам себя.

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

В октябре, когда Amazon Web Services (AWS) вызвал отключение Coinbase, криптосообщество в Twitter вовсю высмеивало недостатки «централизации».

Но когда в ноябре произошёл сбой Cloudflare? По крайней мере в первые часы криптосообщество молчало.

Ведь когда инфраструктура, на которой работает Twitter, лежит, вы не можете обсуждать «уязвимость инфраструктуры» в самом Twitter.

Множество ключевых сервисов остановились (системы транспортных узлов вышли из строя), у некоторых компаний появились сбои в веб-интерфейсах, такие блокчейн-эксплореры, как Arbiscan и DeFiLlama, выдавали ошибку 500 — но сама блокчейн-сеть не демонстрировала признаков нарушения консенсуса.

Если ваша провозглашённая «децентрализованная» революция может быть остановлена из-за слишком большого файла конфигурации одной компании, кто же на самом деле контролирует всё?

Хронология сбоя: от «изменения конфигурации» до «паралича всей сети»

11:05 UTC: завершено развертывание изменений в контроле доступа к базе данных.

Через 23 минуты, в 11:28 UTC, изменения распространились на пользовательские среды, и в HTTP-трафике пользователей впервые были зафиксированы ошибки.

Другими словами: сбой уже произошёл, но никто не знал, в чём проблема.

К 11:48 UTC официальный статус Cloudflare наконец признал «сбой внутренних сервисов» — что на языке корпораций означает: «Всё пошло наперекосяк, и все это видят».

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

Далее посыпались сбои в других системах: Workers KV (сервис хранения ключ-значение) и Access (сервис контроля доступа) не смогли подключиться к прокси; уровень ошибок по всей сети взлетел, а с ростом нагрузки на инструменты мониторинга использование CPU достигло пика.

Трафик продолжал поступать на edge-узлы Cloudflare — но прокси-сервис уже не мог отвечать.

Сначала в Cloudflare решили, что подверглись атаке, причём масштабной распределённой атаке отказа в обслуживании (DDoS).

Более того, даже официальный статусный сайт, полностью размещённый вне инфраструктуры Cloudflare, тоже лег, и инженеры заподозрили: это скоординированная атака на их основные системы и мониторинг.

Но это было не так. Внешней атаки не было, проблема была внутри.

Вскоре после восстановления сервисов технический директор Cloudflare (CTO) Dane Knecht опубликовал публичное извинение, назвав инцидент «совершенно недопустимым» и объяснив, что причиной сбоя стало обычное изменение конфигурации — именно оно вызвало крах слоя защиты от ботов.

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

В пиковый момент сбоя на платформу Downdetector поступило 11183 отчёта о неисправностях.

Этот «цифровой блэкаут» длился более 5 с половиной часов, и только к 17:06 UTC сервисы были полностью восстановлены; однако уже к 14:30, после глобального развертывания правильного файла конфигурации защиты от ботов, самые серьёзные последствия были устранены.

Влияние сбоя: от Web2 до криптоиндустрии — никто не остался в стороне

Web2-платформы пострадали первыми

Платформа X получила 9706 отчётов о сбоях.

Вместо привычной ленты пользователи видели сообщение об ошибке: «Ой, что-то пошло не так».

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

Spotify перестал работать, Canva не пускала дизайнеров, Uber и Door Dash (сервис доставки) также столкнулись с неполадками.

Даже геймеры не избежали проблем: игроки в League of Legends были выброшены из игры.

Появились сообщения, что даже терминалы самообслуживания McDonald's выдавали ошибку — совпав с обеденным пиком и сбоем инфраструктуры.

Криптовалютная индустрия также не осталась в стороне.

Массовые сбои на криптоплатформах

Фронтенд Coinbase полностью рухнул, пользователи видели только не загружающуюся страницу входа.

Веб-версия и мобильное приложение Kraken также «пали» — это был прямой результат глобального сбоя Cloudflare.

BitMEX опубликовал на своей статусной странице: «Ведётся расследование причин сбоя, производительность платформы снижена, но средства пользователей в безопасности». — Тот же сценарий, только другая биржа.

Etherscan не загружался, Arbiscan полностью лег.

Аналитическая панель DeFiLlama периодически выдавала внутренние ошибки сервера.

Даже Ledger сообщил, что из-за сбоя Cloudflare доступность некоторых сервисов снизилась.

Единственное «исключение»: сами блокчейн-протоколы

Но следующие системы не пострадали:

По сообщениям, такие крупные биржи, как Binance, OKX, Bybit, Crypto.com, KuCoin не столкнулись с проблемами на фронтенде, on-chain-транзакции проходили нормально — при этом сами блокчейны работали полностью штатно, без признаков нарушения консенсуса.

Блокчейн-протоколы всегда функционируют независимо — проблема не в самой цепочке, а в Web2-инфраструктуре, через которую люди получают к ней доступ.

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

Глубокий разбор: как один запрос к базе данных парализовал 20% интернета?

Cloudflare не размещает сайты и не предоставляет облачные серверы, как AWS.

Его роль — «посредник» между пользователем и интернетом, обслуживающий 24 миллиона сайтов через сеть из 330 узлов в 120 странах, обрабатывая 20% мирового интернет-трафика.

Рекламный слоган Cloudflare таков: компания позиционирует себя как «щит и ускоритель интернета», предоставляя круглосуточную защиту от DDoS, защиту от ботов, маршрутизацию трафика, глобальный Web Application Firewall (WAF), TLS-терминацию, edge-вычисления на базе Workers и DNS-сервисы — всё это работает на единой «безопасной и производительной» сети.

Фактически, Cloudflare занимает 82% рынка DDoS-защиты, общая пропускная способность edge-узлов достигает 449 Тбит/с, компания связана с множеством ведущих мировых интернет-провайдеров и облачных сервисов.

Суть проблемы: когда посредник выходит из строя, все сервисы за ним становятся «недоступными» одновременно.

Технический директор Cloudflare Dane Knecht прямо заявил на платформе X:

«Скажу прямо: сегодня утром из-за проблем в сети Cloudflare пострадал огромный объём трафика, зависящий от нас, мы подвели клиентов и всех пользователей интернета».

Генеральный директор Matthew Prince выразился ещё прямее:

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

Технические корни сбоя

Всё началось с обычного обновления прав доступа к базе данных. В 11:05 UTC Cloudflare внесла изменения в кластер базы данных ClickHouse, чтобы повысить безопасность и надёжность — пользователи с «неявным доступом» получили «явный» просмотр метаданных таблиц.

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

Запрос, управляющий трафиком угроз, начал возвращать дублирующиеся записи — одну из базы по умолчанию, другую из нижележащей базы r0. Это удвоило размер файла функций: с примерно 60 до более чем 200 признаков.

Cloudflare установила жёсткий лимит на 200 признаков для предварительного выделения памяти, считая, что «это намного больше, чем наши текущие 60 признаков». Типичное инженерное мышление: задать «достаточно большой» запас, пока не случится неожиданность.

Файл, превысивший лимит, вызвал сбой: код на Rust аварийно завершился с ошибкой: «thread fl2_worker_thread panicked: called Result::unwrap () on an Err value» (поток fl2_worker_thread аварийно завершён: вызван Result::unwrap () на ошибочном значении).

Система защиты от ботов — ключевой компонент управляющего слоя Cloudflare. Как только она падает, система health-check, сообщающая балансировщику нагрузки о «здоровых» серверах, тоже выходит из строя.

Хуже того: этот файл конфигурации пересоздаётся каждые 5 минут.

Только если запрос выполняется на «обновлённых узлах кластера», генерируются ошибочные данные. Поэтому каждые 5 минут сеть Cloudflare переключалась между «нормой» и «сбоем» — то загружая правильный файл, то ошибочный.

Эти «скачки» ввели инженеров в заблуждение: они решили, что подвергаются DDoS-атаке — внутренние ошибки редко вызывают циклы «восстановление — сбой».

В итоге все узлы ClickHouse были обновлены, и каждый раз генерировался ошибочный файл. «Скачки» прекратились, наступил «полный, стабильный сбой».

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

Edge-узлы Cloudflare принимали запросы пользователей — но не могли их обработать.

«Это не была внешняя атака», — Knecht неоднократно подчёркивал, — «не было злонамеренных действий, это не DDoS. Просто в запросе к базе данных забыли фильтр, и это совпало с обновлением прав, вызвав сбой».

Cloudflare обещала «99,99% доступности» — но на этот раз обещание не сдержано.

Так оно и есть.

История повторяется: 4 крупных сбоя за 18 месяцев — почему централизованный тупик не преодолён?

20 октября 2025 года — сбой AWS длился 15 часов. В зоне США Восток 1 отказал DNS базы данных DynamoDB, что привело к заморозке Coinbase, сбоям Robinhood, остановке сервиса Infura (и, как следствие, MetaMask), отключению сетей Base, Polygon, Optimism, Arbitrum, Linea, Scroll и других. Хотя средства пользователей на блокчейне были в безопасности, многие видели на счету «ноль».

29 октября 2025 года — сбой Microsoft Azure. Проблемы с синхронизацией конфигурации Azure Front Door привели к отключению Microsoft 365, сбоям Xbox Live и корпоративных сервисов.

Июль 2024 года — у обновления Windows от CrowdStrike (компания по безопасности) обнаружена уязвимость. Сбой привёл к отмене рейсов, задержкам в больницах, заморозке финансовых сервисов, на полное восстановление ушли дни.

Июнь 2022 года — предыдущий крупный сбой Cloudflare. Несколько криптобирж были вынуждены приостановить работу — тот же сценарий, только год другой.

Июль 2019 года — ещё более ранний сбой Cloudflare. Coinbase легла, CoinMarketCap стал недоступен — это был первый «тревожный звонок», который все проигнорировали.

За 18 месяцев произошло 4 крупных сбоя инфраструктуры.

Четыре сбоя — один урок: централизованная инфраструктура неизбежно ведёт к «централизованным сбоям».

Четыре сбоя могли бы ускорить переход криптоиндустрии к децентрализации — но она до сих пор зависит от инфраструктуры трёх компаний.

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

Ложь о децентрализации: децентрализация протокола ≠ децентрализация доступа

Вам рисовали такую картину:

«Децентрализованные финансы, цензура-устойчивая валюта, системы без доверия, отсутствие единой точки отказа, «не твой приватный ключ — не твои монеты», код — это закон».

Но 18 ноября реальность нанесла удар: утренний сбой Cloudflare парализовал часть сервисов криптоиндустрии на несколько часов.

Техническая правда:

Не было сообщений о сбоях ни одного блокчейн-протокола. Сеть Bitcoin работала нормально, сеть Ethereum тоже — с самой цепочкой всё было в порядке.

Реальность использования:

Интерфейсы бирж рухнули, блокчейн-эксплореры легли, интерфейсы кошельков не работали, аналитические платформы упали, торговые интерфейсы выдавали ошибку 500.

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

Следующие высказывания могут показаться многим неприятными…

Операционный директор SovereignAI David Schwed не стесняется в выражениях:

«Сбои Cloudflare сейчас, сбои AWS несколько недель назад — всё это доказывает: нельзя просто делегировать «отказоустойчивость» инфраструктуры одному поставщику. Если вашей организации нужно работать 24/7, стройте инфраструктуру так, будто сбой неизбежен. Если ваш план непрерывности бизнеса — просто «ждать, пока поставщик всё починит», это чистая халатность».

«Чистая халатность» — не случайность, не упущение, а именно халатность.

Jameson Lopp метко подытожил:

«У нас есть отличная децентрализованная технология, но мы сделали её крайне уязвимой, сосредоточив большинство сервисов у нескольких поставщиков».

Ben Schiller сказал о сбое AWS то, что актуально и сейчас:

«Если ваш блокчейн падает из-за сбоя AWS, он недостаточно децентрализован».

Поменяйте «AWS» на «Cloudflare» — суть не меняется: отрасль не учится на ошибках.

Почему выбирают «удобство», а не «принципы»?

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

С Cloudflare достаточно: нажать кнопку, ввести данные карты, развернуть сервис за несколько минут.

DDoS-защиту обеспечивает кто-то другой, доступность — кто-то другой, масштабирование — тоже.

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

Пока «удобство» не перестаёт быть удобным.

Сбой AWS в октябре вызвал в Twitter бесконечные обсуждения «децентрализации».

А сбой Cloudflare в ноябре? Молчание.

Не из-за «философской тишины» и не из-за «глубокого осмысления».

А потому, что хотели пожаловаться — но привычная платформа для жалоб (Twitter) тоже лежала из-за сбоя инфраструктуры.

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

Когда уровень доступа зависит от инфраструктуры трёх компаний, две из которых за месяц уже дали сбой, «децентрализация на уровне протокола» теряет смысл.

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

Монополия: три компании контролируют 60% облачного рынка — куда идти криптоиндустрии?

AWS контролирует около 30% мирового рынка облачной инфраструктуры, Microsoft Azure — 20%, Google Cloud — 13%.

Три компании контролируют более 60% облачной инфраструктуры, на которой держится современный интернет.

Криптоиндустрия должна была быть решением проблемы «централизации», но теперь зависит от самой централизованной инфраструктуры в мире.

«Список централизованных зависимостей» криптоиндустрии

• Coinbase — зависит от AWS;
• Binance, BitMEX, Huobi, Crypto.com — все зависят от AWS;
• Kraken построил инфраструктуру на AWS, но всё равно пострадал из-за сбоя CDN Cloudflare.

Многие биржи, заявляющие о «децентрализации», на деле работают на централизованной инфраструктуре.

Есть и ещё одно важное отличие между сбоями в октябре и ноябре:

Во время сбоя AWS платформа X (бывший Twitter) работала, и криптосообщество могло высмеивать «уязвимость инфраструктуры».

А при сбое Cloudflare платформа X тоже легла.

Когда платформа для «насмешек над единой точкой отказа» сама становится её частью — уже не до смеха.

Этот парадокс с самого начала парализовал отраслевую дискуссию.

Три крупных сбоя за 30 дней — и регуляторы уже обратили на это пристальное внимание.

Ключевые вопросы для регуляторов

• Являются ли эти компании «системно значимыми институтами»?
• Должны ли магистральные интернет-сервисы регулироваться как коммунальные услуги?
• Какие риски возникают, когда «слишком большие, чтобы упасть» сочетается с технологической инфраструктурой?
• Если Cloudflare контролирует 20% мирового трафика, не является ли это монополией?

Corinne Cath-Speth из организации Article 19 прямо заявила после прошлого сбоя AWS: «Когда один поставщик падает, ключевые сервисы тоже отключаются — СМИ становятся недоступны, защищённые мессенджеры вроде Signal перестают работать, инфраструктура цифрового общества рушится. Нам срочно нужна диверсификация облачных вычислений».

Иными словами: правительства начинают понимать, что несколько компаний могут парализовать интернет.

На самом деле децентрализованные альтернативы существуют давно, но никто не хочет их использовать.

Например, Arweave для хранения, IPFS для распределённой передачи файлов, Akash для вычислений, Filecoin для децентрализованного хостинга.

Почему децентрализованные решения не популярны?

Они уступают централизованным по производительности, а задержки пользователи ощущают напрямую.

Их распространённость крайне низка, а по удобству они не сравнятся с «развернуть на AWS» в один клик.

Часто они дороже аренды инфраструктуры у «большой тройки» (AWS, Azure, Google Cloud).

Реальность такова:

Построить по-настоящему децентрализованную инфраструктуру невероятно сложно.

Большинство проектов только говорят о «децентрализации», но редко реализуют её на практике. Централизованные решения всегда проще и дешевле — пока 4 сбоя за 18 месяцев не заставят задуматься о цене «простоты».

Генеральный директор OORT доктор Max Li в недавней колонке для CoinDesk прямо назвал отрасль лицемерной:

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

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

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

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

Очевидно, сбой 18 ноября оказался недостаточно тяжёлым, как и сбой AWS 20 октября, и сбой CrowdStrike в июле 2024 года.

До какого предела «децентрализованная инфраструктура» останется темой для разговоров, а не обязательным требованием?

18 ноября криптоиндустрия не «провалилась» — блокчейн работал идеально.

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

Если блокчейн продолжает создавать блоки, но никто не может отправить транзакцию — действительно ли он «онлайн»?

У отрасли нет плана действий на случай ЧП.

Сбой — ждём, пока Cloudflare починит, AWS восстановит сервис, Azure выпустит патч.

Вот и вся «стратегия восстановления после катастрофы» отрасли.

А что если цифровая идентичность будет тесно связана с блокчейном?

Минфин США продвигает идею встраивания удостоверений личности в смарт-контракты, требуя KYC для каждого DeFi-взаимодействия.

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

Трёхчасовой сбой превратится в три часа «невозможности загрузить капчу» — просто потому, что сервис верификации работает на упавшей инфраструктуре.

«Защитные барьеры», которые хотят построить регуляторы, предполагают, что «инфраструктура всегда онлайн». Но сбой 18 ноября доказал, что это не так.

Когда проблема «чрезмерного надзора» станет очевидной, технологи обратятся к «защите приватности».

Возможно, пора включить «отказоустойчивость инфраструктуры» в этот список.

Это не «приятный бонус», а «базовое требование» — без него остальные функции бессмысленны.

Следующий сбой уже назревает — возможно, от AWS, возможно, от Azure, Google Cloud или очередной сбой Cloudflare.

Это может случиться в следующем месяце, а может — на следующей неделе. Инфраструктура не изменилась, зависимости не изменились, стимулы отрасли тоже.

Централизованные решения по-прежнему дешевле, быстрее и удобнее — пока не перестанут быть таковыми.

Когда очередное обычное изменение конфигурации Cloudflare вызовет скрытую уязвимость в критичном сервисе, мы снова увидим знакомый сценарий: повсеместные ошибки 500, остановка торгов, блокчейн работает, но никто не может подключиться, попытки обсудить «децентрализацию» в Twitter, который лежит, обещания компаний «в следующий раз всё исправить», которые так и не выполняются.

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

На этот раз «страж» был парализован на 3,5 часа.

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

Когда инфраструктура, от которой зависит ваша жизнь, выходит из строя в самый неподходящий момент — чья это вина?

Источники данных: The Guardian, Джонни Попов, PC Magazine, IT Professional, CNBC, Cloudflare, TechCrunch, Associated Press, CoinDesk, Tom's Hardware, Dane Knecht, Tom's Guide, Surya, Sheep Esports, TheBlock, Kraken, BitMEX, Ledger, Blockchain News, Statista, Scream Computer, Jameson Lopp, Ben Schiller, Article 19, CoinTelegraph