18 лістапада 2025 года велізарная частка інтэрнэту абвалілася. Калі вы адкрывалі ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase або незлічоныя меншыя сайты, вас сустракала старонка памылкі 5xx з брэндам Cloudflare — або сайты проста не загружаліся зусім. Тое, што спачатку выглядала як чарговы вялікі момант «інтэрнэт зламаўся», аказалася чымсьці больш тонкім і, у некаторых адносінах, больш трывожным: памылкай, выкліканай самім карыстальнікам, глыбока ўнутры ўласнай інфраструктуры Cloudflare.
Ніжэй прыведзены падрабязны агляд таго, што адбылося падчас учорашняга збою Cloudflare (18 лістапада 2025 года), чаму гэта адбылося, каго гэта закранула і якія ўрокі павінны вынесці з гэтага каманды інфраструктуры.
Што насамрэч адбылося ўчора?
У аўторак, 18 лістапада 2025 года, каля позняй раніцы UTC, Cloudflare пачаў вяртаць вялікія аб'ёмы памылак сервера HTTP 5xx для трафіку, які праходзіў праз яго сетку. Для канчатковых карыстальнікаў гэта азначала старонкі «Унутраная памылка сервера» або «Памылка шлюза» пры спробе доступу да многіх папулярных вэб-сайтаў і праграм.
Згодна з уласным блогам Cloudflare пасля інцыдэнту, збой:
Пачаў уплываць на HTTP-трафік кліентаў а 11:28 UTC
Назіраліся шырока распаўсюджаныя памылкі 5xx у асноўных CDN і службах бяспекі
Былі прыняты значныя меры па ліквідацыі наступстваў прыкладна з 13:05 да 14:30 UTC
Вярнуўся аб'ём памылак 5xx да базавага ўзроўню да 17:06 UTC Блог Cloudflare
Сама Cloudflare апісала гэта як найгоршы збой з 2019 года, таму што ён закрануў не толькі адну функцыю або панэль кіравання — ён парушыў асноўны ўзровень проксі-сервера, які накіроўвае большую частку трафіку кліентаў праз сетку. Блог Cloudflare
Маніторынг трэціх бакоў пацвердзіў гэта. Cisco ThousandEyes зафіксавала глабальны збой, які закрануў Cloudflare, з тайм-аўтамі і памылкамі 5xx у такіх сэрвісах, як X, OpenAI (ChatGPT) і Anthropic, у той час як самі сеткавыя шляхі выглядалі спраўнымі. Гэта пераканаўча сведчыла пра збой бэкэнд-сэрвісу, а не пра праблему на ўзроўні правайдэра або маршрутызацыі. ThousandEyes
Хто пацярпеў?
Паколькі Cloudflare знаходзіцца перад значнай часткай Інтэрнэту (каля 20% вэб-сайтаў залежаць ад Cloudflare для прадукцыйнасці і бяспекі), радыус выбуху быў велізарны. AP News+1
Сярод сэрвісаў, якія пацярпелі:
ChatGPT / OpenAI
X (раней Twitter)
Canva, Shopify, Dropbox, Coinbase
League of Legends і іншыя гульнявыя платформы
Розныя сайты грамадскага транспарту і ўрадавыя сайты, у тым ліку New Jersey Transit і лічбавыя сістэмы чыгункі SNCF Францыі AP News+1
Трэкеры збояў, такія як Downdetector, зафіксавалі тысячы адначасовых паведамленняў пра праблемы ў пік. Агенцтва Reuters паведамляла пра каля 5000 пацярпелых карыстальнікаў толькі для X у адзін момант, перш чым колькасць зменшылася па меры выпуску выпраўленняў. Reuters
З пункту гледжання карыстальніка гэта праяўлялася наступным чынам:
Сайты зусім не загружаліся
Патокі ўваходу ў сістэму завісалі або збоі (асабліва там, дзе былі задзейнічаны Cloudflare Access або Turnstile)
API рэагавалі перыядычна або з памылкамі 5xx
Панэлі кіравання і адміністрацыйныя панэлі перавысілі час чакання
Іншымі словамі: велізарная частка Інтэрнэту «выйшла з ладу», хоць першапрычына была сканцэнтравана ва ўнутраных сістэмах аднаго пастаўшчыка.
Як звычайна працуе Cloudflare (простымі словамі)
Каб зразумець, чаму гэты збой быў настолькі сур'ёзным, карысна ведаць прыблізны шлях запыту праз сетку Cloudflare.
Cloudflare дзейнічае як зваротны проксі-сервер CDN і ўзровень бяспекі:
Ваш браўзер або праграма падключаецца да Cloudflare, а не непасрэдна да сайта-арыгіналу.
Cloudflare спыняе TLS і HTTP на сваім краі.
Запыты паступаюць у асноўную сістэму проксі-сервера Cloudflare пад назвай FL («Frontline») і яе новае пакаленне FL2.
Гэты асноўны проксі-сервер:
Прымяняе правілы WAF (брандмаўэр вэб-праграм)
Запускае мадэлі кіравання ботамі
Апрацоўвае абарону ад DDoS, кэшаванне, выхад да крыніцы
Накіроўвае трафік на іншыя ўнутраныя прадукты, такія як Workers, R2, Access і г.д. Блог Cloudflare
У звычайным рэжыме працы гэтая архітэктура вельмі ўстойлівая: калі ў адным цэнтры апрацоўкі дадзеных узнікае праблема, трафік накіроўваецца праз іншыя; змены канфігурацыі ўносяцца асцярожна; асобныя функцыі павінны выходзіць з ладу кантраляваным чынам.
Учорашні збой быў менавіта такім дрэнным, таму што збой адбыўся ўнутры самога агульнага шляху проксі-сервера і быў цесна звязаны з файлам канфігурацыі, які часта і аўтаматычна распаўсюджваецца па ўсім свеце.
Карэнная прычына: файл функцыі кіравання ботамі выйшаў з ладу
Афіцыйнае тлумачэнне Cloudflare паказвае на аднаго ключавога вінаватага: файл канфігурацыі функцыі, які выкарыстоўваецца іх сістэмай кіравання ботамі. Блог Cloudflare
Вось ланцужок падзей простай мовай:
Кіраванне ботамі выкарыстоўвае «файл функцый»
Мадэль выяўлення ботаў Cloudflare абапіраецца на набор «функцый» — сігналаў аб кожным запыце, якія выкарыстоўваюцца для вызначэння таго, ці з'яўляецца ён чалавекам, ці ботам.
Гэтыя функцыі аб'яднаны ў файл канфігурацыі, які перабудоўваецца кожныя некалькі хвілін і разгортваецца глабальна, каб Cloudflare мог хутка адаптавацца да новых шаблонаў атак. Блог Cloudflare
Змена ў паводзінах запытаў ClickHouse
Файл функцый генеруецца запытамі да базы дадзеных ClickHouse.
Cloudflare зрабіў змены каля 11:05 UTC, каб палепшыць бяспеку і дазволы для размеркаваных запытаў – allo
карыстальнікі wing бачылі метададзеныя не толькі са схемы па змаўчанні, але і з базавых табліц r0. Блог Cloudflare
Запыт, які стварае спіс функцый, не фільтраваўся па назве базы дадзеных; раптам ён пачаў атрымліваць дублікаты слупкоў як з default, так і з r0, што эфектыўна падвоіла колькасць радкоў функцый.
Памер файла функцый рэзка павялічыўся.
Модуль кіравання ботамі мае жорсткае абмежаванне на колькасць функцый, якія ён можа прыняць (устаноўлена на 200, што значна больш за звычайна выкарыстоўваныя ~60).
Калі нядаўна згенераваны файл перавысіў гэтае абмежаванне, модуль дасягнуў ліміту і запанікаваў з-за неапрацаванай памылкі ў кодзе Rust, якая выкарыстоўвала Result::unwrap() для значэння памылкі. Блог Cloudflare
Асноўныя проксі-сэрвісы пачалі вяртаць памылкі 5xx
Паколькі кіраванне ботамі інтэгравана ў асноўны шлях проксі-сервера, паніка праяўлялася ў выглядзе адказаў HTTP 5xx для любога трафіку, які залежаў ад гэтага модуля.
На новым рухавіку FL2 кліенты бачылі відавочныя памылкі 5xx.
На старым рухавіку FL ацэнкі ботаў ціха апускаліся да нуля, што магло прывесці да ілжывых спрацоўванняў у правілах блакавання ботаў. Блог Cloudflare
Сапраўды непрыемная частка: файл пастаянна пераключаўся паміж «добрым» і «дрэнным»
Кластар ClickHouse паступова абнаўляўся, і файл функцый перагенераваўся кожныя пяць хвілін.
Часам запыт выконваўся на абноўленых вузлах (ствараючы дрэнны файл), часам на неабноўленых вузлах (ствараючы добры файл).
Гэта азначала, што на працягу некаторага часу сетка Cloudflare вагалася паміж нармальнай працай і збоем, паколькі распаўсюджваліся розныя версіі файла. Блог Cloudflare
Гэта ваганне зрабіла сітуацыю надзвычай заблытанай унутры. Спачатку каманды Cloudflare западозрылі масіраваную DDoS-атаку, таму што схема памылак не выглядала як просты збой праграмнага забеспячэння. Нават старонка стану Cloudflare, якая размяшчаецца па-за іх уласнай інфраструктурай, коратка паказала памылкі - супадзенне, якое яшчэ больш падсілкоўвала падазрэнні на знешнюю атаку. Блог Cloudflare+1
Толькі калі яны зразумелі, што агульным фактарам быў файл функцый бота, карціна стала зразумелай.
Храналогія інцыдэнту
На падставе аналізу Cloudflare і справаздач трэціх асоб мы можам скласці прыблізны графік на 18 лістапада 2025 года: Блог Cloudflare+2ThousandEyes+2
11:05 UTC – У ClickHouse разгорнута змяненне кантролю доступу да базы дадзеных.
11:20–11:30 UTC – Пачынаюць генеравацца і распаўсюджвацца няправільныя версіі файла функцыі кіравання ботамі.
11:28 UTC – Першы ўплыў на кліента: павышаная колькасць памылак HTTP 5xx, заўважаных у трафіку кліентаў.
11:30–11:32 UTC – Знешнія інструменты маніторынгу і аўтаматызаваныя тэсты пачынаюць выяўляць перыядычныя збоі.
11:35 UTC – Cloudflare запускае ўнутраны выклік аб інцыдэнце; пачынаецца расследаванне.
~11:48 UTC – Cloudflare публікуе абнаўленне статусу, якое пацвярджае інцыдэнт. Адправіць паўторна
11:30–13:05 UTC – Каманды засяроджваюцца на тым, што выглядае як пагаршэнне паводзін Workers KV, і даследуюць некалькі магчымых прычын (у тым ліку сцэнарыяў атакі).
13:05 UTC – Ключавыя меры па змякчэнні наступстваў: Workers KV і доступ да Cloudflare пераключаюцца ў абыход асноўнага проксі-сервера; уплыў зніжаецца. Блог Cloudflare
14:30 UTC – Выяўлена першапрычына; спынена стварэнне і распаўсюджванне няправільных файлаў функцый. Заведама спраўны файл канфігурацыі ўстаўляецца ўручную, і асноўны проксі-сервер перазапускаецца. Большая частка асноўнага трафіку вяртаецца ў нармальны стан. Блог Cloudflare
14:40–15:30 UTC – Праблемы з панэллю кіравання і ўваходам у сістэму застаюцца, бо турнікет і адставанне спроб аўтэнтыфікацыі ствараюць другасныя скокі нагрузкі. Блог Cloudflare
17:06 UTC – Частата памылак вяртаецца да базавага ўзроўню; Cloudflare аб'яўляе сістэмы цалкам нармальнымі. Блог Cloudflare
З пункту гледжання карыстальніка, найбольшы збой адбыўся ў канцы раніцы да пачатку дня UTC, хоць дакладныя перыяды ўздзеяння адрозніваліся ў залежнасці ад рэгіёна і ад таго, ад якіх прадуктаў Cloudflare залежала кожная паслуга.
Чаму гэты збой настолькі важны
Рызыка цэнтралізацыі
Cloudflare з'яўляецца часткай невялікай групы пастаўшчыкоў цэнтральнай інтэрнэт-інфраструктуры, разам з асноўнымі хмарнымі платформамі (AWS, Azure, GCP) і іншымі буйнымі CDN. Калі адзін з гэтых гульцоў выходзіць з ладу, уплыў шырокі і часта невідавочны.
Гэты збой:
Не адбыўся з-за няспраўнасці маршрутызацыі BGP або абрыву кабеля інтэрнэт-правайдэра.
Не адбыўся з-за шкоднаснай атакі (нягледзячы на першапачатковыя падазрэнні).
Адбыўся з-за памылкі ў адной канфігурацыі і абмежаваннях ва ўнутраным кампаненце.
Гэта важна, таму што паказвае, як складаныя, цесна звязаныя сістэмы могуць катастрафічна выйсці з ладу нават без знешняга ўмяшання. Калі многія арганізацыі будуюць на адным і тым жа пастаўшчыку, гэты пастаўшчык фактычна становіцца сістэмна важнай часткай Інтэрнэту.
«Мяккія» залежнасці таксама пашкодзілі
Некаторыя з пацярпелых сэрвісаў выкарыстоўвалі Cloudflare не толькі як «дурную» CDN. Яны:
Выкарыстоўвалі Cloudflare Access для аўтэнтыфікацыі і доступу з нулявым даверам.
Выкарыстоўвалі Workers KV як частку ўнутраных плоскасцяў кіравання.
Спадзяваліся на Turnstile для ўваходу, устойлівага да ботаў. Блог Cloudflare+1
Калі гэтыя прадукты выйшлі з ладу, выйшаў з ладу не толькі кантэнт вэб-сайта — зламаліся таксама ўваходы, функцыі адміністравання і ўнутраныя API. Гэта робіць аднаўленне больш складаным: ваша старонка стану,
Інструменты для інцыдэнтаў або інтэрфейс адміністратара таксама могуць залежаць ад таго самага пастаўшчыка, які толькі што выйшаў з ладу.
Што Cloudflare кажа пра змены
У блогу Cloudflare апісаны некалькі крокаў па выпраўленні, якія кампанія ўжо робіць, каб знізіць рызыку паўтарэння падобнага: Блог Cloudflare
Узмацніць прыём аўтаматычна згенераваных файлаў канфігурацыі
Ставіцца да ўнутрана згенераваных канфігурацый з такім жа скептыцызмам і праверкай, як і да ўведзеных карыстальнікам дадзеных, уключаючы строгую праверку схемы і памеру перад разгортваннем.
Больш глабальных перамыкачоў адключэння
Спрасціць хуткае адключэнне праблемных унутраных модуляў (напрыклад, кіравання ботамі) па ўсёй сетцы, каб яны не адкрываліся, а не панікавалі на ўсім шляху проксі-сервера.
Абараніць сістэмныя рэсурсы ад штормаў памылак
Пераканацца, што асноўныя дампы, метаданыя адладкі і інструменты назіральнасці не могуць перагрузіць працэсар і памяць, калі памылкі пачынаюць рэзка ўзрастаць.
Праглядаць рэжымы збояў у асноўных проксі-модулях
Сістэматычна праводзіць аўдыт таго, як кожны ўнутраны модуль паводзіць сябе пры нечаканым уводзе або канфігурацыі, і забяспечваць карэктную дэградацыю замест глабальнага збою.
Удасканаленне разгортвання і ізаляцыі
Хоць інцыдэнт і не апісваецца падрабязна, ён сведчыць аб тым, што Cloudflare, верагодна, далей сегментуе тое, як распаўсюджваюцца новыя канфігурацыі і паводзіны баз дадзеных, каб паменшыць верагоднасць таго, што адно дрэннае змяненне паўплывае на ўвесь парк.
Яны таксама ахарактарызавалі інцыдэнт як абсалютны правал сваіх чаканняў адносна ўстойлівасці, назваўшы яго «непрымальным» і відавочна прызнаўшы боль, які ён прычыніў як кліентам, так і звычайным карыстальнікам Інтэрнэту. Блог Cloudflare
Урокі для каманд па інфраструктуры і SRE
Нават калі вы не кіруеце чымсьці такім маштабным, як Cloudflare, у гэтым збоі ёсць некалькі вельмі практычных урокаў па праектаванні і эксплуатацыі:
Стаўцеся да ўнутранай канфігурацыі як да ненадзейнага ўводу
Лёгка выказаць здагадку, што «наша ўласная» згенераваная канфігурацыя заўсёды правільная. Учорашні дзень паказвае, чаму гэта небяспечна:
Заўсёды правярайце памер, форму і абмежаванні файлаў канфігурацыі перад іх ужываннем.
Спачатку разгледзьце магчымасць некантралюемага прымянення канфігурацыі да невялікай колькасці трафіку або вузлоў з аўтаматычным адкатам пры анамаліях.
Строгія верхнія межы і аўтаматычныя выключальнікі для колькасці функцый, папярэдняга размеркавання памяці і выкарыстання працэсара.
Праектаванне для вытанчанага частковага збою
Адна памылка ў модулі кіравання ботамі не павінна выклікаць паніку на ўсім шляху проксі-сервера:
Па змаўчанні ўсталюйце адкрыццё пры збоі супраць закрыцця пры збоі на некаторых узроўнях бяспекі, калі альтэрнатывай з'яўляецца поўны адключэнне.
Стварыце зразумелыя, правераныя выключальнікі для неасноўных функцый.
Забяспечце, каб крытычныя падсістэмы (аўтэнтыфікацыя, старонка стану, інструменты інцыдэнтаў) маглі працаваць у пагаршаным рэжыме або па альтэрнатыўных маршрутах.
Назірайце за правільнымі сігналамі
Ваганні паміж «добрай канфігурацыяй» і «дрэннай канфігурацыяй» кожныя пяць хвілін рабілі сігнал падобным на атакуючы трафік або шумную знешнюю паводзіны:
Пераканайцеся, што ў вашым канвееры назірання ёсць карэляцыя для кожнай версіі або кожнай канфігурацыі.
Стварыце панэлі кіравання, якія робяць змены канфігурацыі візуальна відавочнымі на графіках памылак.
Уключыце моцныя сінтэтычныя тэсты з знешняга пункту гледжання, каб вы маглі хутка адрозніць унутраны збой ад праблем з сеткай/шляхам.
Не кладзіце ўсе яйкі ў адзін кошык для інфраструктуры
Для арганізацый, якія выкарыстоўваюць Cloudflare:
Разгледзьце налады некалькіх CDN для сапраўды крытычна важных уласцівасцей.
Пазбягайце рабіць вашу старонку стану цалкам залежнай ад таго ж пастаўшчыка, што і ваш асноўны стэк (Cloudflare робіць гэта, але ўчора ўзніклі выпадковыя праблемы з іх хостам старонкі стану, якія яшчэ больш заблыталі сітуацыю). Блог Cloudflare+1
Падумайце двойчы, перш чым цесна звязваць аўтэнтыфікацыю, плоскасці кіравання API і дастаўку інтэрфейсу з адным і тым жа пастаўшчыком без рэзервовых шляхоў.
Шырокая карціна
Толькі за апошнія некалькі месяцаў мы назіралі сур'ёзныя збоі ў Microsoft Azure, Amazon Web Services, а цяпер і Cloudflare, якія часова адключылі вялікія часткі спажывецкіх і карпаратыўных паслуг. AP News+2The Washington Post+2
Заканамернасць зразумелая:
Інтэрнэт усё больш залежыць ад некалькіх гіганцкіх пастаўшчыкоў інфраструктуры.
Збоі часта выклікаюцца самі сабой, з'яўляюцца вынікам складаных унутраных змен, а не знешніх нападаў.
Нават пастаўшчыкі з практыкай SRE сусветнага класа могуць сутыкнуцца з нечаканымі ўзаемадзеяннямі паміж канфігурацыяй, паводзінамі базы дадзеных і жорстка зададзенымі абмежаваннямі.
Учорашні інцыдэнт з Cloudflare — гэта рэзкае напамін пра тое, што «воблака» — гэта не магія. Па сутнасці, гэта ўсё яшчэ праграмнае забеспячэнне, напісанае людзьмі, схільнае да тых жа класаў памылак, што і любое іншае прыкладанне, проста ад яго залежыць на парадкі больш людзей.
Карыстальнікі ў асноўным запомняць гэты інцыдэнт як «той раніцу, калі X і ChatGPT не загружаліся».
Інжынеры, верагодна, будуць вывучаць яго як хрэстаматыйны прыклад таго, як тонкія памылкі канфігурацыі ў асноўнай размеркаванай сістэме могуць ператварыцца ў глабальную інтэрнэт-падзею.
10650 
IT Pro 
