18 listopada 2025 r. Cloudflare doświadczył jednej ze swoich najbardziej dotkliwych awarii od 2019 r., przez którą miliony witryn wyświetlały błędy 5xx, a duże części internetu na krótko stały się niedostępne.
🔍 Co poszło nie tak
Mimo wczesnych podejrzeń o masowy atak DDoS Cloudflare potwierdził, że problem miał wyłącznie wewnętrzne źródło:
✔ Zmiana uprawnień w bazie danych
→ spowodowała powstanie zduplikowanych wpisów
→ podwoiła rozmiar „pliku funkcji” (feature file) Bot Management
→ przekroczyła limit pamięci w głównym proxy Cloudflare.
Gdy zbyt duży plik rozpropagował się globalnie, proxy uległy awarii — powodując masowe przerwy w ruchu w całej sieci Cloudflare.
🌐 Jak to wyglądało z perspektywy użytkowników
- Witryny chronione przez Cloudflare zwracały błędy 5xx
- Własna strona statusu Cloudflare wydawała się niedostępna (zbieg okoliczności)
- Sesje logowania i wewnętrzne API przestały działać
- Workers KV i Cloudflare Access były częściowo zakłócone
🔁 Dlaczego trudno było postawić diagnozę
System co kilka minut naprzemiennie działał i zawodził, ponieważ różne fragmenty (shardy) bazy danych generowały „dobre” lub „złe” wersje pliku funkcji.
Ta przerywana awaria wyglądała na skutek aktywnego ataku.
🛠 Jak Cloudflare to naprawił
Do godziny 14:30 UTC Cloudflare:
- Przestał dystrybuować wadliwy plik konfiguracyjny
- Ręcznie wdrożył znany, poprawny plik
- Zrestartował główne systemy proxy
- Zwiększył przepustowość, aby obsłużyć skoki ruchu po przywróceniu usług
Wszystkie systemy zostały w pełni przywrócone do godziny 17:06 UTC.
📌 Reakcja Cloudflare
Cloudflare otwarcie uznał to za niedopuszczalną awarię i obiecał:
- Bardziej rygorystyczną walidację wewnętrznych plików konfiguracyjnych
- Więcej przełączników awaryjnych (kill switch) i zabezpieczeń typu fail-safe
- Lepszą obsługę błędów w modułach proxy
- Ulepszone procesy wdrażania uprawnień w ClickHouse
🧠 Dlaczego to ważne
Cloudflare znajduje się w centrum globalnej infrastruktury internetu.
Gdy zawodzi — nawet na kilka minut — efekt domina jest ogromny.
Takie incydenty potwierdzają, jak ważne są:
- Obrona warstwowa (defense-in-depth), także przed zmianami wewnętrznymi
- Architektura zero trust wewnątrz infrastruktury krytycznej
- Globalne przełączniki awaryjne dla systemów o dużym wpływie
- Sanityzacja plików konfiguracyjnych, tak samo jak danych wprowadzanych przez użytkowników
