Збій 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, також вийшла з ладу, і інженери запідозрили: це скоординована атака на їхню основну систему та моніторинг.

Але це було не так. Вони не зазнали зовнішньої атаки, проблема була всередині.

Невдовзі після відновлення сервісу CTO Cloudflare Dane Knecht опублікував публічне вибачення, назвавши інцидент "абсолютно неприйнятним" і поклавши провину на звичайну зміну конфігурації — саме вона спричинила крах захисту від ботів.

"Ми підвели клієнтів і ширших користувачів інтернету", — написав Knecht у заяві. — "У сервісі, що підтримує нашу функцію захисту від ботів, була прихована вразливість, яка після звичайної зміни конфігурації раптово призвела до краху і масового збою нашої мережі та інших сервісів. Це не була зовнішня атака".

Під час піку збою Downdetector отримав 11183 повідомлення про проблеми.

Ця "цифрова темрява" тривала понад 5,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 та інші основні біржі не зазнали проблем із фронтендом, транзакції на блокчейні відбувалися нормально — водночас сам блокчейн працював бездоганно, без жодних ознак порушення консенсусу.

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

Якщо блокчейн працює, але ніхто не може до нього дістатися, чи справді криптовалюта ще "онлайн"?

Глибокий аналіз: як один запит до бази даних паралізував 20% мережі?

Cloudflare не хостить сайти і не надає хмарні сервери як AWS.

Її роль — "посередник" між користувачем та інтернетом, обслуговує 24 мільйони сайтів, через 330 вузлів у 120 країнах обробляє 20% світового трафіку.

Cloudflare позиціонує себе як "щит і прискорювач інтернету", пропонуючи цілодобовий DDoS-захист, захист від ботів, маршрутизацію трафіку, глобальний Web Application Firewall (WAF), TLS-термінацію, edge-обчислення на базі Workers і DNS-сервіси — все це працює на єдиній "мережі безпеки та продуктивності".

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

Суть проблеми: коли посередник виходить з ладу, всі сервіси за ним стають "недосяжними".

CTO Cloudflare Dane Knecht прямо заявив на платформі X:

"Говорю прямо: сьогодні зранку через проблеми в мережі Cloudflare постраждала велика частина трафіку, що залежить від нас. Ми підвели клієнтів і ширших користувачів інтернету."

CEO Matthew Prince висловився ще пряміше:

"Сьогоднішній збій — найсерйозніший для Cloudflare з 2019 року... За понад 6 років у нас не було збоїв, які б призвели до того, що більшість основного трафіку не проходить через нашу мережу."

Технічна причина збою

Все почалося зі звичайного оновлення прав доступу до бази даних. О 11:05 UTC Cloudflare внесла зміни до кластера бази даних ClickHouse, щоб підвищити безпеку та надійність — дозволити користувачам з "неявним доступом" явно бачити метадані таблиць.

У чому була проблема? Запит до бази даних, який генерує конфігураційний файл захисту від ботів Cloudflare, не фільтрував "назву бази даних".

Запит, що керує трафіком загроз, почав повертати дублікати — один з дефолтної бази, інший з підлеглої r0 storage database. Це подвоїло розмір функціонального файлу — з приблизно 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 база даних DynamoDB не змогла розпізнати DNS, що призвело до заморожування 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.

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

Ці слова, можливо, багатьом здадуться неприємними…

COO 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 місяців не показали, якою дорогою може бути ця "простота".

CEO 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, Johnny Popov, 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, Roaring Computers, Jameson Lopp, Ben Schiller, Article 19, CoinTelegraph