11 листопада 18-го — попередження про збої: хто платить за інфраструктуру, коли Cloudflare виходить з ладу?
О 6:20 за східним часом США близько 20% світового інтернет-трафіку раптово припинилося. Звичайне налаштування доступу до бази даних спричинило ланцюг збоїв, що призвели до масштабної зупинки ключових сервісів, які підтримують сучасний інтернет.
Це не хакерська атака і не зовнішня загроза. Причина полягала у тому, що один конфігураційний файл, подвоївшись за обсягом, перевищив встановлений системою ліміт.
Катастрофа, що почалася з однієї запиту до бази даних
Хронологія подій чітка і жорстока:
UTC 11:05 — Cloudflare оновлює права доступу до кластеру баз даних ClickHouse з метою підвищення безпеки та надійності.
UTC 11:28 — зміни поширюються на середовище користувачів, вперше з’являються помилки у логах.
UTC 11:48 — офіційна сторінка стану системи визнає збої.
UTC 17:06 — сервіс повністю відновлено, тривалість понад 5 годин.
Технічна правда
Головна причина збою — у простій помилці: запит до бази даних, що генерує конфігураційний файл для захисту від ботів Cloudflare, не містив фільтру за «назвою бази даних».
Це спричинило повернення дублюючих записів — один з дефолтної бази даних, інший — з нижчого рівня, сховища r0. Обсяг файлу зріс удвічі — з приблизно 60 до понад 200 характеристик.
Cloudflare раніше встановила жорсткий ліміт у 200 характеристик для попереднього розподілу пам’яті, і інженери вважали, що «це значно перевищує наші реальні потреби». Але коли сталася несподіванка, цей, здавалося б, запас безпеки миттєво зруйнувався.
Обсяг файлу перевищив ліміт, і код на Rust видав помилку: “thread fl2_worker_thread panicked: called Result::unwrap() on an Err value”
Система захисту ботів — ядро мережі Cloudflare. Вона, зламавшись, призводить до того, що системи здоров’я серверів, які керують балансуванням навантаження, також виходять з ладу.
Найіронічніше — цей конфігураційний файл оновлюється кожні 5 хвилин. Якщо запити виконуються на оновлених вузлах кластеру, виникають помилки. В результаті мережа Cloudflare починає «переключатися» між станами «нормально» і «збої». Іноді вона може завантажити правильний файл, іноді — неправильний.
Це «перебої у циклі» змусили інженерів думати, що вони піддаються масштабній DDoS-атакі. Адже внутрішні помилки зазвичай не викликають циклічних відновлень і збоїв.
Зрештою, після оновлення всіх вузлів ClickHouse кожен згенерований файл був неправильним. Без точних системних сигналів система безпеки автоматично перейшла у «обережний режим», вважаючи більшість серверів «нездатними». Інтернет-трафік безперервно надходить до краєвих вузлів Cloudflare, але не може бути коректно маршрутизований.
Тихий час у глобальній мережі
Web2 платформи повністю зупинилися
X платформа отримала 9,706 повідомлень про збої
ChatGPT припинив відповідати під час розмови
Spotify перервала стрімінг
Uber та служби доставки — збої функцій
Гравці ігрових сервісів — вимушене роз’єднання
Навіть автоматичні каси McDonald’s видавали помилки
У криптосфері також немає винятків
Основні біржі зазнали краху веб-інтерфейсів, користувачі не можуть увійти або торгувати.
Блокчейн-оглядачі (Etherscan, Arbiscan) — повністю зупинилися.
Платформи аналітики (DeFiLlama) — періодичні помилки серверів.
Постачальники апаратних гаманців — оприлюднили повідомлення про зниження доступності сервісів.
Єдине «виняток» — сама блокчейн-мережа
За повідомленнями, основні біржі не мали фронтенд-збоїв, транзакції на ланцюгу йшли безперебійно. Сам блокчейн працював цілком нормально, без ознак розбиття консенсусу.
Це виявляє гострий парадокс: якщо блокчейн продовжує створювати блоки, але ніхто не може до нього дістатися, чи справді криптовалюта ще «онлайн»?
Роль Cloudflare у глобальному інтернет-трафіку
Cloudflare не хостить сайти і не надає хмарних серверів. Його роль — «посередник» — між користувачами і мережею.
Ключові дані:
Обслуговує 24 мільйони сайтів
Має краєві вузли у 120 країнах і 330 містах
Обробля близько 20% світового інтернет-трафіку
Займає 82% ринку DDoS-захисту
Загальна пропускна здатність краєвих вузлів — 449 Тбіт/с
Коли цей «посередник» виходить з ладу, всі залежні сервіси стають недосяжними.
Голова Cloudflare, Метью Прінс, у офіційній заяві прямо сказав: «Це найсерйозніший збої з 2019 року… За понад 6 років ми ще не стикалися з таким, що робить більшу частину ключового інтернет-трафіку недоступною через наші мережі.»
4 великі збої за 18 місяців: чому індустрія досі не змінилася?
Липень 2024 — вразливість у оновленнях безпеки CrowdStrike спричинила глобальний колапс ІТ-систем (затримки рейсів, лікарні, фінансові сервіси)
20 жовтня 2025 — збій AWS тривав 15 годин, у регіоні США східного узбережжя зупинилися DynamoDB і кілька блокчейнів
29 жовтня 2025 — проблеми синхронізації налаштувань Azure, зупинка Microsoft 365 і Xbox Live
18 листопада 2025 — збої Cloudflare, що вплинули на близько 20% інтернет-трафіку
Ризики моделі одного підрядника
AWS контролює близько 30% світового ринку хмарних сервісів, Microsoft Azure — 20%, Google Cloud — 13%. Три компанії забезпечують понад 60% інфраструктури сучасного інтернету.
Індустрія криптовалют мала б бути «децентралізованим» рішенням, але зараз вона залежить від цих найцентралізованіших провайдерів.
При збої єдина стратегія — чекати. Чекати, поки Cloudflare виправить, AWS відновить, Azure випустить патчі.
Фальш «децентралізації»: рівень протоколу не означає рівень доступу
Обіцянки криптоіндустрії — це:
Децентралізовані фінанси, цензурастійкі валюти, системи без довіри, без єдиного вразливого пункту, код — закон
Реальність 18 листопада: збої вранці зупинили більшість сервісів на кілька годин.
Технічно: жоден протокол блокчейну не повідомляв про збої.
Практично: збої інтерфейсів, браузерів, платформ даних, помилки 500.
Користувачі не можуть отримати доступ до «децентралізованих» блокчейнів, які «належать» їм. Сам протокол працює — якщо ви можете до нього дістатися.
Чому індустрія обирає «зручність», а не «принципи»?
Самостійне створення децентралізованої інфраструктури — це купівля дорогого обладнання, забезпечення стабільного живлення, підтримка власної пропускної здатності, найм безпеки, георезервування, створення аварійних систем, цілодобовий моніторинг.
Використання Cloudflare — це натискання однієї кнопки, введення даних кредитної картки і кілька хвилин — і все готово.
Нові компанії прагнуть швидко вийти на ринок, інвестори — до ефективності капіталу. Всі обирають «зручність», а не «стійкість до збоїв».
Поки «зручність» не стане «незручністю».
Чому альтернативи «децентралізації» «не приживаються»?
Існують рішення децентралізованого зберігання (Arweave), розподіленої передачі файлів (IPFS), децентралізованих обчислень (Akash), децентралізованого хостингу (Filecoin).
Але вони мають проблеми:
Відставання у продуктивності від централізованих рішень, затримки відчувають користувачі
Низька популярність, складність у використанні
Вартість часто вища, ніж оренда інфраструктури у трьох гігантів
Створити справді децентралізовану інфраструктуру — надзвичайно складно, це набагато важче, ніж здається.
Більшість проектів лише декларують «децентралізацію», але мало хто реально її реалізує. Вибір централізованих рішень — простий і дешевий, поки не трапляється збій.
Нові виклики регулювання
За 30 днів три великі збої привернули увагу регуляторів:
Чи належать ці компанії до «системно важливих»?
Чи слід регулювати мережеву інфраструктуру як «комунальні послуги»?
Які ризики виникають, коли «надто великі, щоб збанкрутувати» поєднуються з технологічною інфраструктурою?
Чи становить Cloudflare монополію, контролюючи 20% світового інтернет-трафіку?
Міністерство фінансів США просуває ідею вбудовування ідентифікаційних даних у смарт-контракти, вимагаючи проходження KYC для кожної DeFi-операції. При наступному збої інфраструктури користувачі втратять не лише можливість торгівлі — а й здатність «довести свою особу» у фінансовій системі.
Збої тривалістю 3 години перетворяться на «неможливість пройти людсько-машинну перевірку» — через те, що сервіс верифікації працює на зламаній інфраструктурі.
Від «зручності» до «необхідності»: коли настане перелом?
18 листопада криптоіндустрія не «зазнала поразки» — сама блокчейн-мережа працювала бездоганно.
Справжня «поразка» — у колективному самозамилюванні:
Вірити, що можна побудувати «незупинний» додаток на «зламній» інфраструктурі
Вірити, що контроль трьох компаній над «доступом» має сенс для «антицензури»
Вірити, що один конфіг Cloudflare може визначати, чи зможуть мільйони торгувати — ще має значення «децентралізація»
Захист інфраструктури від збоїв — не додатковий бонус, а основна вимога. Без нього всі інші функції — ніщо.
Наступний злам уже готується — можливо, від AWS, можливо, від Azure, можливо, від Google Cloud або повторний збій Cloudflare. Можливо, вже наступного місяця, можливо — наступного тижня.
Вибір централізованих рішень залишається дешевим, швидким і зручним — доки не стане інакше.
Коли Cloudflare знову змінить конфігурацію і відкриє нову вразливість у ключовій службі, ми знову побачимо знайомі сцени: безліч помилок 500, зупинка торгів, робота блокчейну — але без доступу, обіцянки компаній «зробимо краще наступного разу», які так і залишаться нереалізованими.
Ось у чому проблема сучасної індустрії: все не змінюється, бо «зручність» завжди перемагає «ризик-менеджмент» — аж поки «зручність» не стане надто дорогою, щоб її ігнорувати.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Як оновлення бази даних може паралізувати 20% глобального Інтернету
11 листопада 18-го — попередження про збої: хто платить за інфраструктуру, коли Cloudflare виходить з ладу?
О 6:20 за східним часом США близько 20% світового інтернет-трафіку раптово припинилося. Звичайне налаштування доступу до бази даних спричинило ланцюг збоїв, що призвели до масштабної зупинки ключових сервісів, які підтримують сучасний інтернет.
Це не хакерська атака і не зовнішня загроза. Причина полягала у тому, що один конфігураційний файл, подвоївшись за обсягом, перевищив встановлений системою ліміт.
Катастрофа, що почалася з однієї запиту до бази даних
Хронологія подій чітка і жорстока:
UTC 11:05 — Cloudflare оновлює права доступу до кластеру баз даних ClickHouse з метою підвищення безпеки та надійності.
UTC 11:28 — зміни поширюються на середовище користувачів, вперше з’являються помилки у логах.
UTC 11:48 — офіційна сторінка стану системи визнає збої.
UTC 17:06 — сервіс повністю відновлено, тривалість понад 5 годин.
Технічна правда
Головна причина збою — у простій помилці: запит до бази даних, що генерує конфігураційний файл для захисту від ботів Cloudflare, не містив фільтру за «назвою бази даних».
Це спричинило повернення дублюючих записів — один з дефолтної бази даних, інший — з нижчого рівня, сховища r0. Обсяг файлу зріс удвічі — з приблизно 60 до понад 200 характеристик.
Cloudflare раніше встановила жорсткий ліміт у 200 характеристик для попереднього розподілу пам’яті, і інженери вважали, що «це значно перевищує наші реальні потреби». Але коли сталася несподіванка, цей, здавалося б, запас безпеки миттєво зруйнувався.
Обсяг файлу перевищив ліміт, і код на Rust видав помилку: “thread fl2_worker_thread panicked: called Result::unwrap() on an Err value”
Система захисту ботів — ядро мережі Cloudflare. Вона, зламавшись, призводить до того, що системи здоров’я серверів, які керують балансуванням навантаження, також виходять з ладу.
Найіронічніше — цей конфігураційний файл оновлюється кожні 5 хвилин. Якщо запити виконуються на оновлених вузлах кластеру, виникають помилки. В результаті мережа Cloudflare починає «переключатися» між станами «нормально» і «збої». Іноді вона може завантажити правильний файл, іноді — неправильний.
Це «перебої у циклі» змусили інженерів думати, що вони піддаються масштабній DDoS-атакі. Адже внутрішні помилки зазвичай не викликають циклічних відновлень і збоїв.
Зрештою, після оновлення всіх вузлів ClickHouse кожен згенерований файл був неправильним. Без точних системних сигналів система безпеки автоматично перейшла у «обережний режим», вважаючи більшість серверів «нездатними». Інтернет-трафік безперервно надходить до краєвих вузлів Cloudflare, але не може бути коректно маршрутизований.
Тихий час у глобальній мережі
Web2 платформи повністю зупинилися
У криптосфері також немає винятків
Основні біржі зазнали краху веб-інтерфейсів, користувачі не можуть увійти або торгувати.
Блокчейн-оглядачі (Etherscan, Arbiscan) — повністю зупинилися.
Платформи аналітики (DeFiLlama) — періодичні помилки серверів.
Постачальники апаратних гаманців — оприлюднили повідомлення про зниження доступності сервісів.
Єдине «виняток» — сама блокчейн-мережа
За повідомленнями, основні біржі не мали фронтенд-збоїв, транзакції на ланцюгу йшли безперебійно. Сам блокчейн працював цілком нормально, без ознак розбиття консенсусу.
Це виявляє гострий парадокс: якщо блокчейн продовжує створювати блоки, але ніхто не може до нього дістатися, чи справді криптовалюта ще «онлайн»?
Роль Cloudflare у глобальному інтернет-трафіку
Cloudflare не хостить сайти і не надає хмарних серверів. Його роль — «посередник» — між користувачами і мережею.
Ключові дані:
Коли цей «посередник» виходить з ладу, всі залежні сервіси стають недосяжними.
Голова Cloudflare, Метью Прінс, у офіційній заяві прямо сказав: «Це найсерйозніший збої з 2019 року… За понад 6 років ми ще не стикалися з таким, що робить більшу частину ключового інтернет-трафіку недоступною через наші мережі.»
4 великі збої за 18 місяців: чому індустрія досі не змінилася?
Липень 2024 — вразливість у оновленнях безпеки CrowdStrike спричинила глобальний колапс ІТ-систем (затримки рейсів, лікарні, фінансові сервіси)
20 жовтня 2025 — збій AWS тривав 15 годин, у регіоні США східного узбережжя зупинилися DynamoDB і кілька блокчейнів
29 жовтня 2025 — проблеми синхронізації налаштувань Azure, зупинка Microsoft 365 і Xbox Live
18 листопада 2025 — збої Cloudflare, що вплинули на близько 20% інтернет-трафіку
Ризики моделі одного підрядника
AWS контролює близько 30% світового ринку хмарних сервісів, Microsoft Azure — 20%, Google Cloud — 13%. Три компанії забезпечують понад 60% інфраструктури сучасного інтернету.
Індустрія криптовалют мала б бути «децентралізованим» рішенням, але зараз вона залежить від цих найцентралізованіших провайдерів.
При збої єдина стратегія — чекати. Чекати, поки Cloudflare виправить, AWS відновить, Azure випустить патчі.
Фальш «децентралізації»: рівень протоколу не означає рівень доступу
Обіцянки криптоіндустрії — це:
Реальність 18 листопада: збої вранці зупинили більшість сервісів на кілька годин.
Технічно: жоден протокол блокчейну не повідомляв про збої.
Практично: збої інтерфейсів, браузерів, платформ даних, помилки 500.
Користувачі не можуть отримати доступ до «децентралізованих» блокчейнів, які «належать» їм. Сам протокол працює — якщо ви можете до нього дістатися.
Чому індустрія обирає «зручність», а не «принципи»?
Самостійне створення децентралізованої інфраструктури — це купівля дорогого обладнання, забезпечення стабільного живлення, підтримка власної пропускної здатності, найм безпеки, георезервування, створення аварійних систем, цілодобовий моніторинг.
Використання Cloudflare — це натискання однієї кнопки, введення даних кредитної картки і кілька хвилин — і все готово.
Нові компанії прагнуть швидко вийти на ринок, інвестори — до ефективності капіталу. Всі обирають «зручність», а не «стійкість до збоїв».
Поки «зручність» не стане «незручністю».
Чому альтернативи «децентралізації» «не приживаються»?
Існують рішення децентралізованого зберігання (Arweave), розподіленої передачі файлів (IPFS), децентралізованих обчислень (Akash), децентралізованого хостингу (Filecoin).
Але вони мають проблеми:
Створити справді децентралізовану інфраструктуру — надзвичайно складно, це набагато важче, ніж здається.
Більшість проектів лише декларують «децентралізацію», але мало хто реально її реалізує. Вибір централізованих рішень — простий і дешевий, поки не трапляється збій.
Нові виклики регулювання
За 30 днів три великі збої привернули увагу регуляторів:
Міністерство фінансів США просуває ідею вбудовування ідентифікаційних даних у смарт-контракти, вимагаючи проходження KYC для кожної DeFi-операції. При наступному збої інфраструктури користувачі втратять не лише можливість торгівлі — а й здатність «довести свою особу» у фінансовій системі.
Збої тривалістю 3 години перетворяться на «неможливість пройти людсько-машинну перевірку» — через те, що сервіс верифікації працює на зламаній інфраструктурі.
Від «зручності» до «необхідності»: коли настане перелом?
18 листопада криптоіндустрія не «зазнала поразки» — сама блокчейн-мережа працювала бездоганно.
Справжня «поразка» — у колективному самозамилюванні:
Захист інфраструктури від збоїв — не додатковий бонус, а основна вимога. Без нього всі інші функції — ніщо.
Наступний злам уже готується — можливо, від AWS, можливо, від Azure, можливо, від Google Cloud або повторний збій Cloudflare. Можливо, вже наступного місяця, можливо — наступного тижня.
Вибір централізованих рішень залишається дешевим, швидким і зручним — доки не стане інакше.
Коли Cloudflare знову змінить конфігурацію і відкриє нову вразливість у ключовій службі, ми знову побачимо знайомі сцени: безліч помилок 500, зупинка торгів, робота блокчейну — але без доступу, обіцянки компаній «зробимо краще наступного разу», які так і залишаться нереалізованими.
Ось у чому проблема сучасної індустрії: все не змінюється, бо «зручність» завжди перемагає «ризик-менеджмент» — аж поки «зручність» не стане надто дорогою, щоб її ігнорувати.