Major Cloudflare 18 listopada - Podsumowanie

18 listopada 2025 r. ogromna część Internetu upadła.
Jeśli otworzyłeś ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase lub niezliczone mniejsze witryny, zostałeś powitany przez stronę błędu 5xx marki Cloudflare - lub witryny po prostu w ogóle się nie ładowały. To, co początkowo wyglądało jak kolejny wielki moment "internet jest zepsuty", okazało się czymś bardziej subtelnym i pod pewnymi względami bardziej niepokojącym: błędem spowodowanym przez samego siebie głęboko w infrastrukturze Cloudflare.

Poniżej znajduje się szczegółowy opis tego, co wydarzyło się podczas wczorajszej awarii Cloudflare (18 listopada 2025 r.), dlaczego do niej doszło, kogo dotknęła i jakie wnioski powinny z niej wyciągnąć zespoły ds. infrastruktury.

Co właściwie wydarzyło się wczoraj?

We wtorek, 18 listopada 2025 r., około późnego ranka czasu UTC, Cloudflare zaczął zwracać duże ilości błędów serwera HTTP 5xx dla ruchu, który przechodził przez jego sieć. Dla użytkowników końcowych oznaczało to strony "Internal Server Error" lub "Gateway Error" podczas próby uzyskania dostępu do wielu popularnych witryn i aplikacji.

Według bloga Cloudflare po incydencie, awaria:

• Zaczęła wpływać na ruch HTTP klientów o 11:28 UTC

• Zaobserwowano powszechne błędy 5xx w podstawowych usługach CDN i bezpieczeństwa.

• Główne kroki łagodzące około 13:05-14:30 UTC

• Przywrócono wolumen błędów 5xx do poziomu wyjściowego o 17:06 UTC Blog Cloudflare

Samo Cloudflare określiło to jako swoją najgorszą awarię od 2019 roku, ponieważ nie wpłynęło to tylko na jedną funkcję lub pulpit nawigacyjny - zakłóciło podstawową warstwę proxy, która kieruje większość ruchu klientów przez sieć. Blog Cloudflare

Potwierdza to monitorowanie przez strony trzecie. Cisco ThousandEyes zaobserwowało globalną awarię wpływającą na Cloudflare, z limitami czasu i błędami 5xx w usługach takich jak X, OpenAI (ChatGPT) i Anthropic, podczas gdy same ścieżki sieciowe wyglądały na zdrowe. Wskazywało to zdecydowanie na awarię usługi zaplecza, a nie problem na poziomie dostawcy usług internetowych lub routingu. ThousandEyes

Kto ucierpiał?

Ponieważ Cloudflare znajduje się przed ogromną częścią Internetu (około 20% witryn internetowych polega na Cloudflare w zakresie wydajności i bezpieczeństwa), promień wybuchu był ogromny. AP News+1

Wśród usług zgłoszonych jako dotknięte:

• ChatGPT / OpenAI

• X (dawniej Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends i inne platformy do gier

• Różne witryny transportu publicznego i rządowe, w tym New Jersey Transit i francuskie systemy cyfrowe kolei SNCF AP News+1

Narzędzia do śledzenia awarii, takie jak Downdetector, odnotowały w szczytowym momencie tysiące jednoczesnych zgłoszeń. Reuters donosił o około 5000 użytkowników dotkniętych awarią w samym X w pewnym momencie, zanim liczba ta spadła wraz z wprowadzaniem poprawek. Reuters

Z perspektywy użytkownika objawiło się to następująco:

• Strony w ogóle się nie ładowały

• zawieszanie się lub awarie przepływów logowania (zwłaszcza w przypadku korzystania z Cloudflare Access lub Turnstile)

• Interfejsy API reagujące sporadycznie lub z błędami 5xx

• pulpity nawigacyjne i panele administracyjne nie działające w określonym czasie

Innymi słowy: ogromna część Internetu "nie działała", mimo że główna przyczyna była skoncentrowana w wewnętrznych systemach jednego dostawcy.

Jak normalnie działa Cloudflare (w uproszczeniu)

Aby zrozumieć, dlaczego ta awaria była tak poważna, warto poznać przybliżoną ścieżkę żądania przez sieć Cloudflare.

Cloudflare działa jako reverse proxy CDN i warstwa bezpieczeństwa:

1. Przeglądarka lub aplikacja łączy się z Cloudflare zamiast bezpośrednio z witryną źródłową.

2. Cloudflare kończy TLS i HTTP na swojej krawędzi.

3. Żądania przepływają do głównego systemu proxy Cloudflare, zwanego FL ("Frontline") i jego nowszej generacji FL2.

4. Ten główny serwer proxy

   • stosuje reguły WAF (zapory aplikacji internetowych)

   • Uruchamia modele zarządzania botami

   • Obsługuje ochronę DDoS, buforowanie, wyjście do źródła

   • Kieruje ruch do innych produktów wewnętrznych, takich jak Workers, R2, Access itp. Blog Cloudflare

Podczas normalnej pracy architektura ta jest wysoce odporna: jeśli jedno centrum danych ma problem, ruch jest kierowany przez inne; zmiany konfiguracji są wprowadzane ostrożnie; poszczególne funkcje powinny zawodzić w ograniczony sposób.

Wczorajsza awaria była bardzo poważna, ponieważ wystąpiła wewnątrz wspólnej ścieżki proxy i była ściśle powiązana z plikiem konfiguracyjnym, który jest często i automatycznie przesyłany na cały świat.

Główna przyczyna: nieuczciwy plik funkcji zarządzania botami

Oficjalne wyjaśnienie Cloudflare wskazuje na jednego kluczowego winowajcę:
plik konfiguracyjny funkcji używany przez ich system zarządzania botami. Blog Cloudflare

Oto łańcuch wydarzeń w prostym języku:

1. Bot Management używa "pliku funkcji"

   • Model wykrywania botów Cloudflare opiera się na zestawie "funkcji" - sygnałów o każdym żądaniu używanym do decydowania, czy jest to człowiek, czy bot.

   • Funkcje te są zawarte w pliku konfiguracyjnym, który jest regenerowany co kilka minut i wdrażany globalnie, dzięki czemu Cloudflare może szybko dostosować się do nowych wzorców ataków. Blog Cloudflare

2. Zmiana w zachowaniu zapytań ClickHouse

   • Plik funkcji jest generowany przez zapytania do bazy danych ClickHouse.

   • Cloudflare wprowadził zmianę około 11:05 UTC, aby poprawić bezpieczeństwo i uprawnienia dla zapytań rozproszonych - umożliwiając użytkownikom przeglądanie metadanych nie tylko z domyślnego schematu, ale także z podstawowych tabel r0. Blog Cloudflare

   • Zapytanie budujące listę funkcji nie filtrowało według nazwy bazy danych; nagle zaczęło otrzymywać zduplikowane kolumny zarówno z domyślnego, jak i r0, skutecznie podwajając liczbę wierszy funkcji.

3. Rozmiar pliku funkcji eksplodował

   • Moduł Bot Management ma twardy limit liczby akceptowanych funkcji (ustawiony na 200, znacznie powyżej ~60 normalnie używanych).

   • Gdy nowo wygenerowany plik przekroczył ten limit, moduł wpadł w panikę z powodu nieobsługiwanego błędu w kodzie Rust, który używał Result::unwrap() na wartości błędu. Blog Cloudflare

4. Podstawowe usługi proxy zaczęły zwracać błędy 5xx

   • Ponieważ Bot Management jest zintegrowany z podstawową ścieżką proxy, panika pojawiła się jako odpowiedzi HTTP 5xx dla każdego ruchu, który zależał od tego modułu.

   • W nowym silniku FL2 klienci widzieli wyraźne błędy 5xx.

   • W starszym silniku FL wyniki botów po cichu spadały do zera, co mogło powodować fałszywe alarmy w regułach blokowania botów. Blog Cloudflare

5. Naprawdę nieprzyjemna część: plik ciągle zmieniał się z "dobrego" na "zły"

   • Klaster ClickHouse był stopniowo aktualizowany, a plik funkcji był regenerowany co pięć minut.

   • Czasami zapytanie było uruchamiane na zaktualizowanych węzłach (tworząc zły plik), a czasami na niezaktualizowanych węzłach (tworząc dobry plik).

   • Oznaczało to, że przez pewien czas sieć Cloudflare oscylowała między normalną pracą a awarią, ponieważ propagowane były różne wersje pliku. Blog Cloudflare

Ta oscylacja sprawiła, że sytuacja stała się niezwykle zagmatwana wewnętrznie. Początkowo zespoły Cloudflare podejrzewały zmasowany atak DDoS, ponieważ wzorzec błędu nie wyglądał na zwykłą awarię oprogramowania. Nawet strona statusu Cloudflare, która jest hostowana poza ich własną infrastrukturą, na krótko pokazała błędy - zbieg okoliczności, który dodatkowo podsycił podejrzenia o zewnętrzny atak. Blog Cloudflare+1

Dopiero gdy zdano sobie sprawę, że wspólnym czynnikiem był plik funkcji bota, obraz stał się jasny.

Oś czasu incydentu

Na podstawie sekcji zwłok Cloudflare i raportów stron trzecich możemy stworzyć przybliżoną oś czasu dla 18 listopada 2025 r: The Cloudflare Blog+2ThousandEyes+2

• 11:05 UTC - Zmiana kontroli dostępu do bazy danych zostaje wdrożona w ClickHouse.

• 11:20-11:30 UTC - Rozpoczyna się generowanie i propagowanie błędnych wersji pliku funkcji Bot Management.

• 11:28 UTC - Pierwszy wpływ na klientów: podwyższone błędy HTTP 5xx widoczne w ruchu klientów.

• 11:30-11:32 UTC - Zewnętrzne narzędzia monitorujące i zautomatyzowane testy zaczynają wykrywać sporadyczne awarie.

• 11:35 UTC - Cloudflare otwiera wewnętrzne zgłoszenie incydentu; rozpoczyna się dochodzenie.

• ~11:48 UTC - Cloudflare publikuje aktualizację statusu potwierdzającą incydent. Resend

• 11:30-13:05 UTC - Zespoły koncentrują się na tym, co wydaje się być zdegradowanym zachowaniem Workers KV i badają wiele możliwych przyczyn (w tym scenariusze ataków).

• 13:05 UTC - Kluczowe środki zaradcze: Workers KV i Cloudflare Access są przesunięte, aby ominąć główny serwer proxy; wpływ jest zmniejszony. Blog Cloudflare

• 14:30 UTC - Zidentyfikowano główną przyczynę; generowanie i propagacja złych plików funkcji zostały zatrzymane. Znany dobry plik konfiguracyjny jest wstawiany ręcznie, a główny serwer proxy jest ponownie uruchamiany. Większość ruchu rdzeniowego wraca do normy. Blog Cloudflare

• 14:40-15:30 UTC - Problemy z pulpitem nawigacyjnym i logowaniem utrzymują się, ponieważ Turnstile i zaległości w próbach uwierzytelnienia powodują wtórne skoki obciążenia. Blog Cloudflare

• 17:06 UTC - Wskaźniki błędów powracają do poziomu wyjściowego; Cloudflare deklaruje, że systemy są w pełni normalne. Blog Cloudflare

Z punktu widzenia użytkownika awaria była najbardziej odczuwalna od późnego ranka do wczesnego popołudnia czasu UTC, choć dokładne okna wpływu różniły się w zależności od regionu i produktów Cloudflare, od których zależała każda usługa.

Dlaczego ta awaria ma tak duże znaczenie

Ryzyko centralizacji

Cloudflare jest częścią niewielkiego zestawu centralnych dostawców infrastruktury internetowej, obok głównych platform chmurowych (AWS, Azure, GCP) i innych dużych sieci CDN. Kiedy jeden z tych graczy zawodzi, wpływ jest szeroki i często nieoczywisty.

Ta awaria:

• Nie wynika z błędu routingu BGP lub przecięcia kabla ISP.

• Nie była wynikiem złośliwego ataku (pomimo początkowych podejrzeń).

• Wynikał z pojedynczej konfiguracji i ograniczeń błędu w wewnętrznym komponencie.

To ważne, ponieważ pokazuje, jak złożone, ściśle powiązane systemy mogą ulec katastrofalnej awarii nawet bez ingerencji z zewnątrz. Kiedy wiele organizacji opiera się na tym samym dostawcy, staje się on de facto systemowo ważnym elementem Internetu.

"Miękkie" zależności również ucierpiały

Niektóre z dotkniętych usług nie tylko wykorzystywały Cloudflare jako głupi CDN. Były:

• Używały Cloudflare Access do uwierzytelniania i dostępu o zerowym zaufaniu.

• Używanie Workers KV jako części wewnętrznych płaszczyzn kontroli.

• Poleganie na Turnstile do logowania odpornego na boty. The Cloudflare Blog+1

Gdy te produkty zawiodły, awarii uległa nie tylko zawartość witryny - loginy, funkcje administracyjne i wewnętrzne interfejsy API również uległy awarii. To sprawia, że odzyskiwanie danych jest bardziej złożone: strona stanu, narzędzia do obsługi incydentów lub interfejs administratora mogą również opierać się na tym samym dostawcy, który właśnie zawiódł.

Co Cloudflare twierdzi, że zmieni

Blog Cloudflare przedstawia kilka kroków naprawczych, które firma już podejmuje, aby zmniejszyć ryzyko powtórzenia się podobnych sytuacji: Blog Cloudflare

1. Wzmocnienie pozyskiwania automatycznie generowanych plików konfiguracyjnych
   Traktuj wewnętrznie generowane konfiguracje z takim samym sceptycyzmem i walidacją, jak dane wejściowe dostarczane przez użytkownika, w tym ścisłe sprawdzanie schematu i rozmiaru przed wdrożeniem.

2. Więcej globalnych wyłączników awaryjnych
   Ułatwienie szybkiego wyłączania problematycznych modułów wewnętrznych (takich jak Bot Management) w całej sieci, dzięki czemu nie będą one działać zamiast wywoływać panikę na całej ścieżce proxy.

3. Ochrona zasobów systemowych przed burzami błędów
   Upewnij się, że zrzuty rdzenia, metadane debugowania i narzędzia obserwowalności nie mogą przeciążać procesora i pamięci, gdy błędy zaczynają gwałtownie rosnąć.

4. Przegląd trybów awarii w podstawowych modułach proxy
   Systematycznie sprawdzaj, jak zachowuje się każdy moduł wewnętrzny w przypadku nieoczekiwanych danych wejściowych lub konfiguracji, i zapewnij łagodną degradację zamiast globalnej awarii.

5. Dopracowanie wdrożeń i izolacji
   Chociaż incydent nie został szczegółowo opisany, sugeruje, że Cloudflare prawdopodobnie będzie dalej segmentować sposób propagacji nowych konfiguracji i zachowań DB, aby zmniejszyć ryzyko, że pojedyncza zła zmiana wpłynie na całą flotę.

Firma określiła również incydent jako absolutną porażkę swoich oczekiwań w zakresie odporności, nazywając go "niedopuszczalnym" i wyraźnie przyznając, że spowodował on ból zarówno dla klientów, jak i zwykłych użytkowników Internetu. Blog Cloudflare

Lekcje dla zespołów ds. infrastruktury i SRE

Nawet jeśli nie prowadzisz czegoś tak ogromnego jak Cloudflare, z tej awarii można wyciągnąć kilka bardzo praktycznych wniosków projektowych i operacyjnych:

Traktuj wewnętrzną konfigurację jak niezaufane dane wejściowe

Łatwo jest założyć, że "nasza własna" wygenerowana konfiguracja jest zawsze poprawna. Wczorajszy dzień pokazuje, dlaczego jest to niebezpieczne:

• Zawsze sprawdzaj rozmiar, kształt i ograniczenia plików konfiguracyjnych przed ich zastosowaniem.

• Rozważmy najpierw kanarkowe zastosowanie konfiguracji do małego podzbioru ruchu lub węzłów, z automatycznym wycofywaniem w przypadku anomalii.

• Utrzymuj ścisłe górne granice i wyłączniki wokół liczby funkcji, wstępnej alokacji pamięci i użycia procesora.

Projekt uwzględniający częściowe awarie

Jeden błąd w module Bot Management nie powinien być w stanie wywołać paniki na całej ścieżce proxy:

• Domyślne ustawienie fail-open vs fail-closed w niektórych warstwach zabezpieczeń, gdy alternatywą jest całkowita awaria.

• Zbudowanie jasnych, przetestowanych wyłączników awaryjnych dla funkcji innych niż podstawowe.

• Upewnij się, że krytyczne podsystemy (autoryzacja, strona stanu, narzędzia do obsługi incydentów) mogą działać w trybie awaryjnym lub za pośrednictwem alternatywnych tras.

Obserwuj właściwe sygnały

Oscylacja między "dobrą konfiguracją" a "złą konfiguracją" co pięć minut sprawiała, że sygnał wyglądał jak ruch związany z atakiem lub hałaśliwe zachowanie zewnętrzne:

• Upewnij się, że masz korelację per-wersja lub per-konfiguracja w swoim potoku obserwowalności.

• Twórz pulpity nawigacyjne, które sprawiają, że zmiany konfiguracji są wizualnie widoczne na wykresach błędów.

• Uwzględnij silne testy syntetyczne z zewnętrznego punktu widzenia, aby móc szybko odróżnić awarię wewnętrzną od problemów z siecią/ścieżką.

Nie wkładaj wszystkich jajek do jednego koszyka infra

Dla organizacji korzystających z Cloudflare:

• Rozważ konfiguracje multi-CDN dla prawdziwie krytycznych właściwości.

• Unikaj całkowitego uzależnienia strony statusu od tego samego dostawcy, co główny stos (Cloudflare tak robi, ale wczoraj wystąpiły przypadkowe problemy z ich hostem strony statusu, co jeszcze bardziej zagmatwało sytuację). Blog Cloudflare+1

• Zastanów się dwa razy, zanim ściśle połączysz swoje uwierzytelnianie, płaszczyzny kontroli API i dostarczanie frontendu z tym samym dostawcą bez ścieżek awaryjnych.

Szerszy obraz

Tylko w ciągu ostatnich kilku miesięcy byliśmy świadkami poważnych awarii w Microsoft Azure, Amazon Web Services, a teraz Cloudflare, z których wszystkie tymczasowo wyłączyły duże fragmenty usług konsumenckich i korporacyjnych. AP News+2TheWashington Post+2

Wzorzec jest jasny:

• Internet jest coraz bardziej zależny od garstki gigantycznych dostawców infrastruktury.

• Awarie są często spowodowane przez nich samych, wynikają raczej ze złożonych zmian wewnętrznych niż ataków zewnętrznych.

• Nawet dostawcy ze światowej klasy praktykami SRE mogą nadal być potknięci przez nieoczekiwane interakcje między konfiguracją, zachowaniem bazy danych i zakodowanymi na stałe limitami.

Wczorajszy incydent Cloudflare jest wyraźnym przypomnieniem, że "chmura" to nie magia. W gruncie rzeczy jest to nadal oprogramowanie napisane przez ludzi, podlegające tym samym klasom błędów, co każda inna aplikacja - tylko z rzędami wielkości większą liczbą osób od niej zależnych.

Dla użytkowników incydent ten zostanie zapamiętany głównie jako "ten poranek, kiedy X i ChatGPT nie chciały się załadować".
Dla inżynierów będzie to prawdopodobnie podręcznikowy przykład tego, jak subtelne błędy konfiguracyjne w podstawowym systemie rozproszonym mogą przerodzić się w globalne wydarzenie internetowe.