Întreruperea majoră a Cloudflare din 18 noiembrie - un rezumat

La 18 noiembrie 2025, o mare parte din internet s-a prăbușit.
Dacă ați deschis ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase sau nenumărate site-uri mai mici, ați fost întâmpinați cu o pagină de eroare 5xx marca Cloudflare - sau site-urile pur și simplu nu s-au încărcat deloc. Ceea ce părea la început un alt mare moment "internetul este stricat" s-a dovedit a fi ceva mai subtil și, într-un fel, mai îngrijorător: o eroare autoprovocată în interiorul infrastructurii Cloudflare.

Mai jos este prezentată o prezentare detaliată a ceea ce s-a întâmplat în timpul întreruperii Cloudflare de ieri (18 noiembrie 2025), de ce s-a întâmplat, pe cine a afectat și ce lecții ar trebui să tragă echipele de infrastructură.

Ce s-a întâmplat de fapt ieri?

Marți, 18 noiembrie 2025, spre sfârșitul dimineții UTC, Cloudflare a început să returneze volume mari de erori de server HTTP 5xx pentru traficul care trecea prin rețeaua sa. Pentru utilizatorii finali, aceasta a însemnat pagini "Internal Server Error" sau "Gateway Error" atunci când au încercat să acceseze multe site-uri și aplicații populare.

Potrivit blogului post-incident al Cloudflare, întreruperea:

• A început să afecteze traficul HTTP al clienților la ora 11:28 UTC

• Au apărut erori 5xx pe scară largă în serviciile de bază CDN și de securitate

• Au fost luate măsuri majore de atenuare în jurul orei 13:05-14:30 UTC

• Volumul de erori 5xx a revenit la nivelul de referință până la 17:06 UTC Blogul Cloudflare

Cloudflare însuși a descris-o ca fiind cea mai gravă întrerupere din 2019, deoarece nu a afectat doar o caracteristică sau un tablou de bord - a întrerupt stratul proxy de bază care direcționează majoritatea traficului clienților prin rețeaua sa. Blogul Cloudflare

Monitorizarea terță parte a susținut acest lucru. Cisco ThousandEyes a observat o întrerupere globală care a afectat Cloudflare, cu timeout-uri și erori 5xx pe servicii precum X, OpenAI (ChatGPT) și Anthropic, în timp ce căile de rețea în sine păreau sănătoase. Acest lucru indică în mod clar o defecțiune a serviciului backend, nu o problemă la nivel de ISP sau de rutare. ThousandEyes

Cine a fost afectat?

Deoarece Cloudflare se află în fața unei părți masive a internetului (aproximativ 20 % din site-urile web se bazează pe Cloudflare pentru performanță și securitate), raza exploziei a fost enormă. AP News+1

Printre serviciile raportate ca fiind afectate:

• ChatGPT / OpenAI

• X (fostul Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends și alte platforme de jocuri

• Diverse site-uri guvernamentale și de transport public, inclusiv New Jersey Transit și sistemele digitale ale căilor ferate franceze SNCF AP News+1

Dispozitivele de urmărire a întreruperilor, cum ar fi Downdetector, au înregistrat mii de rapoarte de probleme concomitente la vârf. Reuters a raportat aproximativ 5 000 de utilizatori afectați numai pentru X la un moment dat, înainte ca numărul acestora să scadă pe măsură ce soluțiile erau implementate. Reuters

Din perspectiva unui utilizator, acest lucru s-a manifestat astfel:

• Site-uri care nu se încarcă deloc

• fluxuri de conectare suspendate sau eșuate (în special în cazul în care au fost implicate Cloudflare Access sau Turnstile)

• API-uri care răspund intermitent sau cu erori 5xx

• Tablouri de bord și panouri de administrare cronometrate

Cu alte cuvinte: părți uriașe ale internetului "s-au simțit căzute", chiar dacă cauza principală era concentrată în sistemele interne ale unui singur furnizor.

Cum funcționează Cloudflare în mod normal (în termeni simpli)

Pentru a înțelege de ce această întrerupere a fost atât de gravă, este util să cunoaștem traseul aproximativ al unei cereri prin rețeaua Cloudflare.

Cloudflare acționează ca un proxy invers CDN și un strat de securitate:

1. Browserul sau aplicația dvs. se conectează la Cloudflare în loc să se conecteze direct la site-ul de origine.

2. Cloudflare termină TLS și HTTP la marginea sa.

3. Solicitările curg în sistemul proxy de bază al Cloudflare, numit FL ("Frontline") și generația sa mai nouă FL2.

4. Acest proxy de bază:

   • Aplică reguli WAF (firewall pentru aplicații web)

   • rulează modele de gestionare a roboților

   • Gestionează protecția DDoS, cachingul, ieșirea la origine

   • Rutează traficul către alte produse interne precum Workers, R2, Access etc. Blogul Cloudflare

În condiții normale de funcționare, această arhitectură este foarte rezistentă: dacă un centru de date are o problemă, traficul este direcționat prin altele; modificările de configurare sunt implementate cu atenție; caracteristicile individuale ar trebui să eșueze în moduri conținute.

Întreruperea de ieri a fost tocmai rea, deoarece defecțiunea a fost în interiorul căii proxy comune în sine și a fost strâns cuplată cu un fișier de configurare care este împins la nivel mondial frecvent și automat.

Cauza principală: un fișier caracteristic de gestionare a roboților care a luat-o razna

Explicația oficială a Cloudflare indică un vinovat principal:
un fișier de configurare a caracteristicilor utilizat de sistemul lor de gestionare a roboților. Blogul Cloudflare

Iată lanțul de evenimente în limbaj simplu:

1. Bot Management utilizează un "fișier de caracteristici"

   • Modelul Cloudflare de detectare a roboților se bazează pe un set de "caracteristici" - semnale despre fiecare cerere utilizate pentru a decide dacă este umană sau un robot.

   • Aceste caracteristici sunt grupate într-un fișier de configurare care este regenerat la fiecare câteva minute și implementat la nivel global, astfel încât Cloudflare să se poată adapta rapid la noi modele de atac. Blogul Cloudflare

2. O schimbare în comportamentul interogărilor ClickHouse

   • Fișierul de caracteristici este generat de interogările împotriva unei baze de date ClickHouse.

   • Cloudflare a făcut o schimbare în jurul orei 11:05 UTC pentru a îmbunătăți securitatea și permisiunile pentru interogările distribuite - permițând utilizatorilor să vadă metadatele nu doar dintr-o schemă implicită, ci și din tabelele r0 subiacente. Blogul Cloudflare

   • Interogarea care construiește lista de caracteristici nu a filtrat după numele bazei de date; dintr-o dată a început să obțină coloane duplicate atât din schema implicită, cât și din r0, dublând efectiv numărul de rânduri de caracteristici.

3. Fișierul de caracteristici a explodat în dimensiune

   • Modulul Bot Management are o limită strictă privind numărul de caracteristici pe care le acceptă (setată la 200, mult peste cele ~60 utilizate în mod normal).

   • Atunci când fișierul nou generat a depășit această limită, modulul a atins plafonul și a intrat în panică, din cauza unei erori nesoluționate în codul Rust care folosea Result::unwrap() pe o valoare de eroare. Blogul Cloudflare

4. Serviciile proxy de bază au început să returneze erori 5xx

   • Deoarece Bot Management este integrat în calea proxy de bază, panica a apărut ca răspunsuri HTTP 5xx pentru orice trafic care depindea de acest modul.

   • Pe noul motor FL2, clienții au văzut erori 5xx explicite.

   • Pe motorul FL mai vechi, scorurile bot au ajuns în tăcere la zero, ceea ce ar putea cauza pozitivi falși în regulile de blocare a bot-urilor. Blogul Cloudflare

5. Partea cu adevărat neplăcută: fișierul a continuat să oscileze între "bun" și "rău"

   • Clusterul ClickHouse a fost actualizat treptat, iar fișierul de caracteristici a fost regenerat la fiecare cinci minute.

   • Uneori interogarea rula pe noduri actualizate (producând un fișier rău), alteori pe noduri neactualizate (producând un fișier bun).

   • Aceasta înseamnă că, pentru o vreme, rețeaua Cloudflare a oscilat între funcționarea normală și defecțiune, pe măsură ce se propagau diferite versiuni ale fișierului. Blogul Cloudflare

Această oscilație a făcut ca situația să fie extrem de confuză la nivel intern. La început, echipele Cloudflare au suspectat un atac DDoS masiv, deoarece modelul de eroare nu arăta ca o simplă defecțiune software. Chiar și pagina de stare Cloudflare, care este găzduită în afara propriei infrastructuri, a prezentat pentru scurt timp erori - o coincidență care a alimentat și mai mult suspiciunea unui atac extern. BlogulCloudflare+1

Doar după ce au realizat că factorul comun era fișierul de caracteristici bot, imaginea a devenit clară.

Cronologia incidentului

Pe baza raportului postmortem al Cloudflare și a rapoartelor părților terțe, putem reconstitui o cronologie aproximativă pentru 18 noiembrie 2025: Blogul Cloudflare+2ThousandEyes+2

• 11:05 UTC - O modificare a controlului accesului la baza de date este implementată în ClickHouse.

• 11:20-11:30 UTC - Versiunile greșite ale fișierului de funcții Bot Management încep să fie generate și propagate.

• 11:28 UTC - Primul impact asupra clienților: erori HTTP 5xx ridicate observate în traficul clienților.

• 11:30-11:32 UTC - Instrumentele externe de monitorizare și testele automate încep să detecteze defecțiuni intermitente.

• 11:35 UTC - Cloudflare deschide un apel de incident intern; începe investigația.

• ~11:48 UTC - Cloudflare publică o actualizare de stare care confirmă un incident. Reîntoarcere

• 11:30-13:05 UTC - Echipele se concentrează pe ceea ce pare a fi un comportament degradat al Workers KV și investighează multiple cauze posibile (inclusiv scenarii de atac).

• 13:05 UTC - Atenuarea cheie: Workers KV și Cloudflare Access sunt schimbate pentru a ocoli proxy-ul principal; impactul este redus. Blogul Cloudflare

• 14:30 UTC - Cauza principală identificată; generarea și propagarea fișierelor de caracteristici proaste este oprită. Un fișier de configurare bun cunoscut este introdus manual și proxy-ul central este repornit. Majoritatea traficului core revine la normal. Blogul Cloudflare

• 14:40-15:30 UTC - Problemele legate de tabloul de bord și de autentificare persistă, deoarece Turnstile și întârzierile încercărilor de autentificare creează vârfuri secundare de încărcare. Blogul Cloudflare

• 17:06 UTC - Ratele de eroare revin la linia de bază; Cloudflare declară sistemele complet normale. Blogul Cloudflare

Din punctul de vedere al unui utilizator, întreruperea s-a simțit cel mai rău la sfârșitul dimineții până la începutul după-amiezii UTC, deși ferestrele exacte de impact au variat în funcție de regiune și de produsele Cloudflare de care depindea fiecare serviciu.

De ce această întrerupere contează atât de mult

Risc de centralizare

Cloudflare face parte dintr-un set restrâns de furnizori centrali de infrastructură de internet, alături de marile platforme cloud (AWS, Azure, GCP) și alte CDN-uri mari. Atunci când unul dintre acești actori eșuează, impactul este larg și adesea neobservabil.

Această întrerupere:

• Nu a fost cauzată de o eroare de rutare BGP sau de o întrerupere a cablului ISP.

• Nu a fost cauzată de un atac rău intenționat (în ciuda suspiciunilor inițiale).

• A provenit de la o singură configurație și de la o eroare limită într-o componentă internă.

Acest lucru este important deoarece arată cum sistemele complexe, strâns legate între ele, pot ceda în mod catastrofal chiar și fără interferențe externe. Atunci când mai multe organizații se bazează pe același furnizor, furnizorul respectiv devine de facto o parte importantă a internetului din punct de vedere sistemic.

Dependențele "ușoare" sunt și ele afectate

Unele dintre serviciile afectate nu foloseau Cloudflare doar ca un CDN idiot. Erau:

• Utilizau Cloudflare Access pentru autentificare și acces cu încredere zero.

• Utilizau Workers KV ca parte a planurilor de control intern.

• bazându-se pe Turnstile pentru autentificări rezistente la roboți. BlogulCloudflare+1

Atunci când aceste produse au cedat, nu a fost doar conținutul site-ului web care a căzut - autentificările, funcțiile de administrare și API-urile interne au cedat, de asemenea. Acest lucru face ca recuperarea să fie mai complexă: pagina dvs. de stare, instrumentele pentru incidente sau interfața de administrare ar putea, de asemenea, să se bazeze chiar pe furnizorul care tocmai a cedat.

Ce spune Cloudflare că va schimba

Blogul Cloudflare prezintă mai multe măsuri de remediere pe care compania le ia deja pentru a reduce riscul ca ceva similar să se repete: Blogul Cloudflare

1. Întărirea ingestiei fișierelor de configurare generate automat
   Tratați fișierele de configurare generate intern cu același scepticism și validare ca și intrările furnizate de utilizator, inclusiv verificarea strictă a schemei și a dimensiunii înainte de lansare.

2. Mai multe întrerupătoare globale
   Facilitați dezactivarea rapidă a modulelor interne problematice (cum ar fi Bot Management) în întreaga rețea, astfel încât acestea să eșueze la deschidere în loc să panicheze întreaga cale proxy.

3. Protejarea resurselor sistemului împotriva furtunilor de erori
   Asigurați-vă că descărcările de bază, metadatele de depanare și instrumentele de observabilitate nu pot copleși procesorul și memoria atunci când erorile încep să crească.

4. Examinați modurile de eșec ale modulelor proxy de bază
   Auditați sistematic modul în care se comportă fiecare modul intern în cazul unei intrări sau configurări neașteptate și asigurați o degradare grațioasă în locul unei defecțiuni globale.

5. Rafinarea lansărilor și a izolării
   Deși nu este explicat în detaliu, incidentul sugerează că Cloudflare va continua probabil să segmenteze modul în care noile configurații și comportamentele DB se propagă, pentru a reduce șansele ca o singură schimbare proastă să afecteze întreaga flotă.

De asemenea, ei au încadrat incidentul ca un eșec absolut al așteptărilor lor de reziliență, numindu-l "inacceptabil" și recunoscând explicit durerea pe care a provocat-o atât clienților, cât și utilizatorilor obișnuiți de internet. Blogul Cloudflare

Lecții pentru echipele de infrastructură și SRE

Chiar dacă nu executați ceva la fel de mare ca Cloudflare, există câteva lecții foarte practice de proiectare și operaționale în această întrerupere:

Tratați configurația internă ca pe o intrare neîncrezătoare

Este ușor să presupunem că "propria noastră" configurație generată este întotdeauna corectă. Ziua de ieri arată de ce acest lucru este periculos:

• Validați întotdeauna dimensiunea, forma și limitele fișierelor de configurare înainte de a le aplica.

• Luați în considerare aplicarea caniculară a configurației mai întâi la un mic subset de trafic sau noduri, cu revenire automată la anomalii.

• Mențineți limite superioare stricte și întrerupătoare de circuit în ceea ce privește numărul de funcții, prealocarea memoriei și utilizarea CPU.

Proiectare pentru eșec parțial grațios

O eroare în modulul Bot Management nu ar trebui să poată panica întreaga cale proxy:

• În unele straturi de securitate, în cazul în care alternativa este întreruperea completă a funcționării , să se opteze în mod implicit pentru fail-open vs fail-closed.

• Construiți întrerupătoare clare și testate pentru funcțiile care nu sunt esențiale.

• Asigurați-vă că subsistemele critice (autentificarea, pagina de stare, instrumentele pentru incidente) pot funcționa în mod degradat sau prin rute alternative.

Observați semnalele corecte

Oscilația între "configurare bună" și "configurare proastă" la fiecare cinci minute a făcut ca semnalul să pară trafic de atac sau comportament extern zgomotos:

• Asigurați-vă că aveți o corelație per-versiune sau per-config în conducta dvs. de observabilitate.

• Creați tablouri de bord care fac modificările de configurare evidente din punct de vedere vizual pe lângă graficele de erori.

• Includeți teste sintetice puternice dintr-un punct de vedere extern, astfel încât să puteți distinge rapid eșecul intern de problemele de rețea/căi.

Nu vă puneți toate ouăle într-un singur coș infra

Pentru organizațiile care utilizează Cloudflare:

• Luați în considerare configurațiile multi-CDN pentru proprietățile cu adevărat critice pentru misiune.

• Evitați ca pagina dvs. de stare să depindă în întregime de același furnizor ca și stiva dvs. principală (Cloudflare face acest lucru, dar ieri au existat probleme întâmplătoare cu gazda paginii lor de stare, ceea ce a încurcat și mai mult lucrurile). BlogulCloudflare+1

• Gândiți-vă de două ori înainte de a vă cupla strâns autentificarea, planurile de control API și livrarea front-end la același furnizor fără căi de rezervă.

Imaginea de ansamblu

Numai în ultimele câteva luni, am asistat la întreruperi majore la Microsoft Azure, Amazon Web Services și acum Cloudflare, care au scos temporar din funcțiune o mare parte din serviciile destinate consumatorilor și întreprinderilor. AP News+2TheWashington Post+2

Modelul este clar:

• Internetul este din ce în ce mai dependent de o mână de furnizori de infrastructură giganți.

• Întreruperile sunt adesea autoprovocate, provenind mai degrabă din schimbări interne complexe decât din atacuri externe.

• Chiar și furnizorii cu practici SRE de clasă mondială pot fi împiedicați de interacțiuni neașteptate între configurație, comportamentul bazei de date și limitele codificate.

Incidentul Cloudflare de ieri ne reamintește clar că "cloud-ul" nu este magic. În esență, este un software scris de oameni, supus acelorași tipuri de erori ca orice altă aplicație, doar că mai multe persoane depind de el.

Pentru utilizatori, incidentul va fi amintit mai ales ca "dimineața aceea când X și ChatGPT nu se încărcau".
Pentru ingineri, acesta va fi probabil studiat ca un exemplu de manual al modului în care erori subtile de configurare într-un sistem distribuit central se pot transforma într-un eveniment global pe internet.