Dana 18. studenog 2025., ogroman dio interneta se srušio.
Ako biste otvorili ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase ili bezbroj manjih stranica, dočekala bi vas stranica s greškom 5xx s oznakom Cloudflarea - ili se stranice jednostavno uopće nisu učitavale. Ono što je u početku izgledalo kao još jedan veliki trenutak "internet je pokvaren" pokazalo se nečim suptilnijim i, u nekim aspektima, zabrinjavajućim: samoprouzročenom greškom duboko u vlastitoj infrastrukturi Cloudflarea.
U nastavku slijedi detaljan pregled onoga što se dogodilo tijekom jučerašnjeg prekida rada Cloudflarea (18. studenog 2025.), zašto se to dogodilo, na koga je utjecalo i koje bi lekcije timovi za infrastrukturu trebali izvući iz toga.
Što se zapravo dogodilo jučer?
U utorak, 18. studenog 2025., oko kasnog jutra UTC, Cloudflare je počeo vraćati velike količine HTTP 5xx pogrešaka poslužitelja za promet koji je prolazio kroz njegovu mrežu. Za krajnje korisnike to je značilo stranice „Interna pogreška poslužitelja“ ili „Pogreška pristupnika“ pri pokušaju pristupa mnogim popularnim web stranicama i aplikacijama.
Prema vlastitom blogu Cloudflarea nakon incidenta, prekid rada:
Počeo je utjecati na HTTP promet korisnika u 11:28 UTC
Vidio je raširene 5xx pogreške u osnovnoj CDN mreži i sigurnosnim uslugama
Poduzeti su veliki koraci za ublažavanje oko 13:05–14:30 UTC
Vratio je 5xx količinu pogrešaka na početnu vrijednost do 17:06 UTC Cloudflare blog
Sam Cloudflare opisao je to kao svoj najgori prekid rada od 2019. godine, jer nije utjecao samo na jednu značajku ili nadzornu ploču – poremetio je osnovni proxy sloj koji usmjerava većinu prometa korisnika kroz njegovu mrežu. Cloudflare blog
Praćenje treće strane potvrdilo je to. Cisco ThousandEyes je zabilježio globalni prekid rada koji je utjecao na Cloudflare, s vremenskim ograničenjima i 5xx pogreškama na servisima poput X, OpenAI (ChatGPT) i Anthropic, dok su sami mrežni putevi izgledali ispravno. To je snažno ukazivalo na kvar pozadinske usluge, a ne na problem na razini ISP-a ili usmjeravanja. ThousandEyes
Tko je pogođen?
Budući da se Cloudflare nalazi ispred velikog dijela interneta (oko 20% web stranica oslanja se na Cloudflare za performanse i sigurnost), radijus eksplozije bio je ogroman. AP News+1
Među servisima za koje je prijavljeno da su pogođeni:
ChatGPT / OpenAI
X (ranije Twitter)
Canva, Shopify, Dropbox, Coinbase
League of Legends i druge platforme za igre
Razne stranice javnog prijevoza i vlade, uključujući New Jersey Transit i francuske SNCF željezničke digitalne sustave AP News+1
Praćenje prekida poput Downdetectora zabilježilo je tisuće istovremenih izvješća o problemima na vrhuncu. Reuters je u jednom trenutku izvijestio o oko 5000 pogođenih korisnika samo za X, prije nego što je broj opao kako su se uvodila rješenja. Reuters
Iz perspektive korisnika, to se manifestiralo kao:
Web-stranice se uopće ne učitavaju
Prijave se zaglavljuju ili ne uspijevaju (posebno tamo gdje su bili uključeni Cloudflare Access ili Turnstile)
API-ji reagiraju povremeno ili s 5xx pogreškama
Nadzorne ploče i administratorske ploče su istekle
Drugim riječima: veliki dijelovi interneta "pali su", iako je uzrok bio koncentriran u internim sustavima jednog pružatelja usluga.
Kako Cloudflare obično radi (jednostavno rečeno)
Da biste razumjeli zašto je ovaj prekid bio tako ozbiljan, pomaže znati grubi put zahtjeva kroz Cloudflareovu mrežu.
Cloudflare djeluje kao obrnuti proxy CDN i sigurnosni sloj:
Vaš preglednik ili aplikacija povezuje se s Cloudflareom umjesto izravno s izvornom web-lokacijom.
Cloudflare prekida TLS i HTTP na svom rubu.
Zahtjevi se ulijevaju u Cloudflareov glavni proxy sustav, nazvan FL („Frontline“) i njegovu noviju generaciju FL2.
Taj glavni proxy:
Primjenjuje WAF (web application firewall) pravila
Pokreće modele upravljanja botovima
Ruči DDoS zaštitu, predmemoriranje, izlaz prema izvoru
Usmjerava promet na druge interne proizvode poput Workersa, R2, Accessa itd. Cloudflare blog
U normalnom radu ova je arhitektura vrlo otporna: ako jedan podatkovni centar ima problem, promet se usmjerava kroz druge; promjene konfiguracije se pažljivo uvode; pojedinačne značajke trebale bi zakazati na kontrolirane načine.
Jučerašnji prekid rada bio je upravo loš jer se kvar dogodio unutar same zajedničke proxy putanje i bio je usko povezan s konfiguracijskom datotekom koja se često i automatski širi diljem svijeta.
Korijenski uzrok: datoteka značajke za upravljanje botovima postala je neispravna
Službeno objašnjenje Cloudflarea ukazuje na jednog ključnog krivca: konfiguracijsku datoteku značajke koju koristi njihov sustav za upravljanje botovima. Cloudflare blog
Evo niza događaja jednostavnim jezikom:
Upravljanje botom koristi "datoteku značajki"
Cloudflareov model detekcije botova oslanja se na skup "značajki" - signala o svakom zahtjevu koji se koriste za odlučivanje je li riječ o čovjeku ili botu.
Ove značajke su objedinjene u konfiguracijsku datoteku koja se regenerira svakih nekoliko minuta i globalno se uvodi, tako da se Cloudflare može brzo prilagoditi novim obrascima napada. Cloudflare blog
Promjena u ponašanju upita ClickHousea
Datoteka značajki generira se upitima prema bazi podataka ClickHousea.
Cloudflare je napravio promjenu oko 11:05 UTC kako bi poboljšao sigurnost i dozvole za distribuirane upite - allo
wing korisnicima da vide metapodatke ne samo iz zadane sheme već i iz temeljnih r0 tablica. Cloudflare Blog
Upit koji izrađuje popis značajki nije filtrirao prema nazivu baze podataka; odjednom je počeo dobivati duplicirane stupce i iz zadane i iz r0, učinkovito udvostručujući broj redaka značajki.
Datoteka značajki eksplodirala je u veličini
Modul Bot Management ima čvrsto ograničenje koliko značajki će prihvatiti (postavljeno na 200, znatno iznad ~60 koje se inače koriste).
Kada je novogenerirana datoteka premašila to ograničenje, modul je dosegao gornju granicu i paničario zbog neobrađene pogreške u Rust kodu koja je koristila Result::unwrap() na vrijednosti pogreške. Cloudflare Blog
Osnovne proxy usluge počele su vraćati 5xx pogreške
Budući da je Bot Management integriran u glavnu proxy putanju, panika se pojavila kao HTTP 5xx odgovori za bilo koji promet koji je ovisio o tom modulu.
Na novom FL2 engineu, korisnici su vidjeli eksplicitne 5xx pogreške.
Na starijem FL engineu, rezultati botova tiho su padali na nulu, što je moglo uzrokovati lažno pozitivne rezultate u pravilima blokiranja botova. Cloudflare Blog
Zaista gadan dio: datoteka se stalno prebacivala između "dobrog" i "lošeg"
ClickHouse klaster se postupno ažurirao, a datoteka značajki se regenerirala svakih pet minuta.
Ponekad se upit izvršavao na ažuriranim čvorovima (proizvodeći lošu datoteku), ponekad na neažuriranim čvorovima (proizvodeći ispravnu datoteku).
To je značilo da je Cloudflareova mreža neko vrijeme oscilirala između normalnog rada i kvara dok su se širile različite verzije datoteke. Cloudflare Blog
Ova oscilacija je situaciju učinila izuzetno zbunjujućom interno. U početku su Cloudflareovi timovi sumnjali na masovni DDoS napad jer uzorak pogreške nije izgledao kao jednostavan softverski pad. Čak je i Cloudflareova statusna stranica, koja se nalazi izvan njihove vlastite infrastrukture, nakratko prikazala pogreške – slučajnost koja je dodatno potaknula sumnju na vanjski napad. Cloudflare Blog+1
Tek kada su shvatili da je zajednički faktor datoteka značajki bota, slika je postala jasna.
Vremenska crta incidenta
Na temelju Cloudflareove analize i izvješća trećih strana, možemo sastaviti okvirnu vremensku crtu za 18. studenog 2025.: Cloudflare Blog+2ThousandEyes+2
11:05 UTC – U ClickHouseu je implementirana promjena kontrole pristupa bazi podataka.
11:20–11:30 UTC – Počinju se generirati i širiti loše verzije datoteke značajke Bot Management.
11:28 UTC – Prvi utjecaj na kupca: povišene HTTP 5xx pogreške uočene u prometu kupaca.
11:30–11:32 UTC – Vanjski alati za praćenje i automatizirani testovi počinju otkrivati povremene kvarove.
11:35 UTC – Cloudflare otvara interni poziv za incident; počinje istraga.
~11:48 UTC – Cloudflare objavljuje ažuriranje statusa kojim potvrđuje incident. Ponovno slanje
11:30–13:05 UTC – Timovi se usredotočuju na ono što se čini kao degradirano ponašanje Workers KV-a i istražuju više mogućih uzroka (uključujući scenarije napada).
13:05 UTC – Ključno ublažavanje: Workers KV i Cloudflare Access preusmjereni su kako bi se zaobišao glavni proxy; utjecaj je smanjen. Cloudflare Blog
14:30 UTC – Identificiran je glavni uzrok; generiranje i širenje loših datoteka značajki je zaustavljeno. Poznato dobra konfiguracijska datoteka ručno se umeće i glavni proxy se ponovno pokreće. Većina glavnog prometa vraća se u normalu. Cloudflare Blog
14:40–15:30 UTC – Problemi s nadzornom pločom i prijavom zaostaju jer Turnstile i zaostaci pokušaja autentifikacije stvaraju sekundarne skokove opterećenja. Cloudflare Blog
17:06 UTC – Stope pogrešaka vraćaju se na početnu vrijednost; Cloudflare proglašava sustave potpuno normalnima. Cloudflare blog
S korisničke točke gledišta, prekid se najgore osjetio u kasnim jutarnjim do ranim poslijepodnevnim satima UTC-a, iako su se točni prozori utjecaja razlikovali ovisno o regiji i o tome o kojim se Cloudflare proizvodima oslanjala svaka usluga.
Zašto je ovaj prekid toliko važan
Rizik centralizacije
Cloudflare je dio malog skupa pružatelja središnje internetske infrastrukture, uz glavne cloud platforme (AWS, Azure, GCP) i druge velike CDN-ove. Kada jedan od ovih igrača zakaže, utjecaj je širok i često nejasan.
Ovaj prekid:
Nije nastao zbog problema s BGP usmjeravanjem ili prekida kabela ISP-a.
Nije nastao zbog zlonamjernog napada (unatoč početnim sumnjama).
Nastao je zbog greške u jednoj konfiguraciji i ograničenjima u internoj komponenti.
To je važno jer pokazuje kako složeni, čvrsto povezani sustavi mogu katastrofalno zakazati čak i bez vanjskog uplitanja. Kada mnoge organizacije grade na istom pružatelju usluga, taj pružatelj usluga postaje de facto sistemski važan dio interneta.
„Meke“ ovisnosti također su naštetile
Neke od pogođenih usluga nisu koristile Cloudflare samo kao glupi CDN. One su:
Koristile Cloudflare Access za autentifikaciju i pristup nultom povjerenju.
Koristile Workers KV kao dio internih kontrolnih ravnina.
Oslanjale se na Turnstile za prijave otporne na botove. Cloudflare Blog+1
Kada su ti proizvodi zakazali, nije se srušio samo sadržaj web stranice – prijave, administratorske funkcije i interni API-ji također su se pokvarili. To oporavak čini složenijim: vaša stranica sa statusom,
Alati za incidente ili administratorsko korisničko sučelje također se mogu oslanjati na istog pružatelja usluga koji je upravo zakazao.
Što Cloudflare kaže da će se promijeniti
Cloudflareov blog opisuje nekoliko koraka sanacije koje tvrtka već poduzima kako bi smanjila rizik od ponavljanja nečeg sličnog: Cloudflare Blog
Pooštrite unos automatski generiranih konfiguracijskih datoteka
Tretirajte interno generirane konfiguracije s istim skepticizmom i validacijom kao i unose koje je korisnik dao, uključujući strogu provjeru sheme i veličine prije uvođenja.
Više globalnih prekidača za zaustavljanje
Olakšajte brzo onemogućavanje problematičnih internih modula (poput Upravljanja botovima) u mreži, tako da se ne otvore ispravno umjesto da paničare cijeli put proxyja.
Zaštitite sistemske resurse od oluja pogrešaka
Osigurajte da izvatci jezgre, metapodaci za otklanjanje pogrešaka i alati za promatranje ne mogu preopteretiti CPU i memoriju kada pogreške počnu naglo rasti.
Pregledajte načine kvara u svim modulima jezgre proxyja
Sustavno revidirajte kako se svaki interni modul ponaša pod neočekivanim unosom ili konfiguracijom i osigurajte gracioznu degradaciju umjesto globalnog kvara.
Poboljšajte implementacije i izolaciju
Iako nije detaljno opisano, incident sugerira da će Cloudflare vjerojatno dodatno segmentirati način širenja novih konfiguracija i ponašanja baza podataka kako bi se smanjila mogućnost da jedna loša promjena utječe na cijelu flotu.
Također su incident uokvirili kao apsolutni neuspjeh svojih očekivanja otpornosti, nazvavši ga "neprihvatljivim" i izričito priznajući bol koju je prouzročio i kupcima i običnim korisnicima interneta. Cloudflare blog
Pouke za timove za infrastrukturu i SRE
Čak i ako ne vodite nešto tako veliko kao što je Cloudflare, postoje neke vrlo praktične lekcije o dizajnu i radu u ovom prekidu:
Tretirajte internu konfiguraciju kao nepouzdan unos
Lako je pretpostaviti da je "naša vlastita" generirana konfiguracija uvijek ispravna. Jučerašnji dan pokazuje zašto je to opasno:
Uvijek provjerite veličinu, oblik i ograničenja konfiguracijskih datoteka prije nego što ih primijenite.
Razmislite o promjenjivoj primjeni konfiguracije na mali podskup prometa ili čvorova, s automatskim vraćanjem na anomalije.
Održavajte stroge gornje granice i prekidače oko broja značajki, prealokacije memorije i korištenja CPU-a.
Dizajn za graciozan djelomični kvar
Jedan bug u modulu za upravljanje botovima ne bi trebao uzrokovati paniku na cijelom proxy putu:
Postavite zadano otvaranje u slučaju kvara naspram zatvaranja u nekim slojevima sigurnosti kada je alternativa potpuni prekid rada.
Izgradite jasne, testirane prekidače za kill switcheve za neosnovne značajke.
Osigurajte da kritični podsustavi (autentifikacija, stranica statusa, alati za incidente) mogu raditi u degradiranom načinu rada ili putem alternativnih ruta.
Promatrajte prave signale
Oscilacija između "dobre konfiguracije" i "loše konfiguracije" svakih pet minuta činila je da signal izgleda kao napadni promet ili bučno vanjsko ponašanje:
Pobrinite se da imate korelaciju po verziji ili po konfiguraciji u svom cjevovodu za promatranje.
Izradite nadzorne ploče koje vizualno čine promjene konfiguracije očitima na vrhu grafova pogrešaka.
Uključite snažne sintetičke testove s vanjske točke gledišta kako biste mogli brzo razlikovati unutarnji kvar od problema s mrežom/putom.
Ne stavljajte sva jaja u jednu košaru za infrastrukturu
Za organizacije koje koriste Cloudflare:
Razmislite o postavkama više CDN-ova za doista kritična svojstva.
Izbjegavajte da vaša stranica statusa u potpunosti ovisi o istom pružatelju usluga kao i vaš primarni stog (Cloudflare to radi, ali jučer je slučajno došlo do problema s njihovim hostom stranice statusa, što je dodatno zbunilo stvari). Cloudflare Blog+1
Dvaput razmislite prije nego što čvrsto povežete svoju autentifikaciju, API kontrolne ravnine i isporuku frontenda s istim dobavljačem bez rezervnih puteva.
Šira slika
Samo u posljednjih nekoliko mjeseci vidjeli smo velike prekide u Microsoft Azureu, Amazon Web Servicesu, a sada i Cloudflareu, koji su privremeno isključili velike dijelove potrošačkih i poslovnih usluga. AP News+2The Washington Post+2
Uzorak je jasan:
Internet sve više ovisi o nekolicini divovskih pružatelja infrastrukture.
Prekidi su često samoizazvani, dolazeći od složenih unutarnjih promjena, a ne od vanjskih napada.
Čak i pružatelji usluga s vrhunskim SRE praksama mogu se spotaknuti o neočekivane interakcije između konfiguracije, ponašanja baze podataka i čvrsto kodiranih ograničenja.
Jučerašnji incident s Cloudflareom oštar je podsjetnik da „oblak“ nije magija. U osnovi, to je i dalje softver koji pišu ljudi, podložan istim klasama grešaka kao i svaka druga aplikacija - samo s redovima veličine više ljudi koji ovise o njemu.
Korisnici će incident uglavnom pamtiti kao „ono jutro kada se X i ChatGPT nisu htjeli učitati“.
Inženjeri će ga vjerojatno proučavati kao školski primjer kako suptilne konfiguracijske greške u jezgri distribuiranog sustava mogu prerasti u globalni internetski događaj.
10529 
IT Pro 
