Il Maggiore di Cloudflare 18 novembre - Un riassunto

Il 18 novembre 2025, un'enorme fetta di Internet è crollata.
Se aprivate ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase o innumerevoli siti minori, venivate accolti da una pagina di errore 5xx con il marchio Cloudflare, oppure i siti non si caricavano affatto. Quello che all'inizio sembrava l'ennesimo momento in cui "Internet è rotto" si è rivelato qualcosa di più sottile e, per certi versi, più preoccupante: un bug autoinflitto all'interno dell'infrastruttura di Cloudflare.

Qui di seguito viene illustrato nel dettaglio cosa è successo nell'interruzione di Cloudflare di ieri (18 novembre 2025), perché si è verificato, chi ha colpito e quali insegnamenti i team di infrastruttura dovrebbero trarne.

Cosa è successo realmente ieri?

Martedì 18 novembre 2025, verso la tarda mattinata UTC, Cloudflare ha iniziato a restituire grandi volumi di errori server HTTP 5xx per il traffico che passava attraverso la sua rete. Per gli utenti finali, ciò significava pagine di "Internal Server Error" o "Gateway Error" quando si cercava di accedere a molti siti web e applicazioni popolari.

Secondo il blog di Cloudflare dopo l'incidente, l'interruzione del servizio:

• Ha iniziato ad avere un impatto sul traffico HTTP dei clienti alle 11:28 UTC.

• Errori 5xx diffusi in tutti i servizi principali di sicurezza e CDN.

• Sono state effettuate importanti misure di mitigazione intorno alle 13:05-14:30 UTC.

• Il volume degli errori 5xx è stato riportato al livello di base alle 17:06 UTC Il blog di Cloudflare

Cloudflare stessa l'ha descritta come la sua peggiore interruzione dal 2019, perché non ha interessato solo una funzione o una dashboard, ma ha interrotto il livello proxy principale che instrada la maggior parte del traffico dei clienti attraverso la sua rete. Il blog di Cloudflare

Il monitoraggio di terze parti ha confermato questo dato. Cisco ThousandEyes ha riscontrato un'interruzione globale che ha interessato Cloudflare, con timeout ed errori 5xx su servizi come X, OpenAI (ChatGPT) e Anthropic, mentre gli stessi percorsi di rete sembravano sani. Questo fa pensare a un guasto del servizio di backend, non a un problema a livello di ISP o di routing. MilleOcchi

Chi è stato colpito?

Poiché Cloudflare si trova di fronte a un'enorme porzione di Internet (circa il 20% dei siti web si affida a Cloudflare per le prestazioni e la sicurezza), il raggio d'azione è stato enorme. Notizie AP+1

Tra i servizi segnalati come colpiti:

• ChatGPT / OpenAI

• X (ex Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends e altre piattaforme di gioco

• Vari siti governativi e di trasporto pubblico, tra cui New Jersey Transit e i sistemi digitali ferroviari francesi SNCF AP News+1

I tracker di interruzioni, come Downdetector, hanno registrato migliaia di segnalazioni di problemi simultanei durante il picco. Reuters ha riportato circa 5.000 utenti interessati solo per X a un certo punto, prima che i conteggi diminuissero man mano che le correzioni venivano implementate. Reuters

Dal punto di vista dell'utente, il problema si è manifestato come segue:

• Siti che non si caricano affatto

• Flussi di login bloccati o falliti (soprattutto se erano coinvolti Cloudflare Access o Turnstile)

• API che rispondono in modo intermittente o con errori 5xx

• Dashboard e pannelli di amministrazione che si bloccano

In altre parole, enormi parti di Internet "si sentivano giù", anche se la causa principale era concentrata nei sistemi interni di un singolo provider.

Come funziona normalmente Cloudflare (in termini semplici)

Per capire perché questa interruzione è stata così grave, è utile conoscere il percorso approssimativo di una richiesta attraverso la rete di Cloudflare.

Cloudflare funge da reverse proxy CDN e da livello di sicurezza:

1. Il browser o l'applicazione si connette a Cloudflare invece che direttamente al sito di origine.

2. Cloudflare termina TLS e HTTP ai suoi margini.

3. Le richieste confluiscono nel sistema proxy principale di Cloudflare, chiamato FL ("Frontline") e nella sua nuova generazione FL2.

4. Questo proxy centrale:

   • applica le regole WAF (web application firewall)

   • Esegue modelli di gestione dei bot

   • Gestisce la protezione DDoS, la cache, l'uscita verso l'origine

   • instrada il traffico verso altri prodotti interni come Workers, R2, Access, ecc. Il blog di Cloudflare

In condizioni normali questa architettura è altamente resiliente: se un data center ha un problema, il traffico viene instradato attraverso altri; le modifiche alla configurazione vengono eseguite con attenzione; le singole funzionalità dovrebbero fallire in modi contenuti.

L'interruzione di ieri è stata proprio negativa perché il guasto si è verificato all'interno del percorso del proxy comune ed era strettamente legato a un file di configurazione che viene distribuito in tutto il mondo in modo frequente e automatico.

La causa principale: un file di configurazione per la gestione dei bot che ha fatto cilecca.

La spiegazione ufficiale di Cloudflare indica un colpevole chiave:
un file di configurazione utilizzato dal sistema di gestione dei bot. Il blog di Cloudflare

Ecco la catena di eventi in parole povere:

1. Bot Management utilizza un "file di configurazione".

   • Il modello di rilevamento dei bot di Cloudflare si basa su un insieme di "caratteristiche", ovvero segnali relativi a ogni richiesta utilizzati per decidere se si tratta di un essere umano o di un bot.

   • Queste caratteristiche sono raggruppate in un file di configurazione che viene rigenerato ogni pochi minuti e distribuito a livello globale, in modo che Cloudflare possa adattarsi rapidamente a nuovi modelli di attacco. Il blog di Cloudflare

2. Un cambiamento nel comportamento delle query ClickHouse

   • Il file delle caratteristiche è generato da query su un database ClickHouse.

   • Cloudflare ha apportato una modifica intorno alle 11:05 UTC per migliorare la sicurezza e le autorizzazioni per le query distribuite, consentendo agli utenti di visualizzare i metadati non solo da uno schema predefinito, ma anche dalle tabelle r0 sottostanti. Il blog di Cloudflare

   • La query che costruisce l'elenco delle caratteristiche non filtrava in base al nome del database; improvvisamente ha iniziato a ottenere colonne duplicate sia da default che da r0, raddoppiando di fatto il numero di righe di caratteristiche.

3. Il file delle caratteristiche è esploso in dimensioni

   • Il modulo Bot Management ha un limite rigido al numero di caratteristiche che accetta (impostato a 200, ben oltre le circa 60 normalmente in uso).

   • Quando il file appena generato ha superato tale limite, il modulo ha raggiunto il limite e si è spaventato, a causa di un errore non gestito nel codice Rust che utilizzava Result::unwrap() su un valore di errore. Il blog di Cloudflare

4. I servizi proxy del nucleo hanno iniziato a restituire errori 5xx

   • Poiché Bot Management è integrato nel percorso del proxy principale, il panico si è manifestato come risposte HTTP 5xx per tutto il traffico che dipendeva da quel modulo.

   • Sul nuovo motore FL2, i clienti hanno visto errori 5xx espliciti.

   • Sul vecchio motore FL, i punteggi dei bot si azzeravano silenziosamente, il che poteva causare falsi positivi nelle regole di blocco dei bot. Il blog di Cloudflare

5. La parte davvero spiacevole: il file continuava a passare da "buono" a "cattivo".

   • Il cluster ClickHouse veniva gradualmente aggiornato e il file delle caratteristiche veniva rigenerato ogni cinque minuti.

   • A volte la query veniva eseguita su nodi aggiornati (producendo un file cattivo), a volte su nodi non aggiornati (producendo un file buono).

   • Ciò significa che per un po' di tempo la rete di Cloudflare ha oscillato tra il funzionamento normale e il fallimento, man mano che venivano propagate le diverse versioni del file. Il blog di Cloudflare

Questa oscillazione ha reso la situazione estremamente confusa a livello interno. In un primo momento, i team di Cloudflare hanno sospettato un massiccio attacco DDoS perché il modello di errore non sembrava un semplice crash del software. Anche la pagina di stato di Cloudflare, ospitata al di fuori della propria infrastruttura, ha mostrato per breve tempo degli errori, una coincidenza che ha alimentato ulteriormente il sospetto di un attacco esterno. Il blog di Cloudflare+1

Solo quando si è capito che il fattore comune era il file di funzionalità del bot, il quadro è diventato chiaro.

Cronologia dell'incidente

Sulla base dell'autopsia di Cloudflare e dei rapporti di terze parti, possiamo ricostruire una timeline approssimativa del 18 novembre 2025: Il blog di Cloudflare+2ThousandEyes+2

• 11:05 UTC - Una modifica al controllo dell'accesso al database viene implementata in ClickHouse.

• 11:20-11:30 UTC - Iniziano a essere generate e propagate versioni errate del file di funzionalità di Bot Management.

• 11:28 UTC - Primo impatto sui clienti: errori HTTP 5xx elevati riscontrati nel traffico dei clienti.

• 11:30-11:32 UTC - Strumenti di monitoraggio esterni e test automatici iniziano a rilevare guasti intermittenti.

• 11:35 UTC - Cloudflare apre una chiamata di incidente interno; inizia l'indagine.

• ~11:48 UTC - Cloudflare pubblica un aggiornamento di stato che conferma un incidente. Reinvio

• 11:30-13:05 UTC - I team si concentrano su quello che sembra essere un comportamento degradato dei Worker KV e indagano su diverse possibili cause (compresi gli scenari di attacco).

• 13:05 UTC - Attenuazione chiave: Workers KV e Cloudflare Access vengono spostati per bypassare il proxy centrale; l'impatto è ridotto. Il blog di Cloudflare

• 14:30 UTC - Identificata la causa principale, la generazione e la propagazione dei file di configurazione difettosi viene interrotta. Viene inserito manualmente un file di configurazione noto e buono e il core proxy viene riavviato. La maggior parte del traffico del core torna alla normalità. Il blog di Cloudflare

• 14:40-15:30 UTC - I problemi di dashboard e login persistono, mentre Turnstile e i tentativi di autenticazione arretrati creano picchi di carico secondari. Il blog di Cloudflare

• 17:06 UTC - I tassi di errore tornano alla linea di base; Cloudflare dichiara i sistemi completamente normali. Il blog di Cloudflare

Dal punto di vista degli utenti, l'interruzione è stata più grave tra la tarda mattinata e il primo pomeriggio UTC, anche se le finestre di impatto esatto variavano a seconda della regione e dei prodotti Cloudflare da cui dipendeva ciascun servizio.

Perché questa interruzione è così importante

Rischio di centralizzazione

Cloudflare fa parte di un piccolo gruppo di fornitori di infrastrutture Internet centrali, insieme alle principali piattaforme cloud (AWS, Azure, GCP) e ad altre grandi CDN. Quando uno di questi attori si guasta, l'impatto è ampio e spesso non evidente.

Questa interruzione:

• non è stata causata da un errore di routing BGP o dall'interruzione di un cavo ISP.

• Non è stato causato da un attacco malevolo (nonostante i sospetti iniziali).

• È stato causato da un singolo bug di configurazione e di limiti in un componente interno.

Questo è importante perché dimostra come sistemi complessi e strettamente accoppiati possano fallire in modo catastrofico anche senza interferenze esterne. Quando molte organizzazioni si appoggiano allo stesso provider, questo diventa di fatto un pezzo di Internet di importanza sistemica.

Anche le dipendenze "soft" fanno male

Alcuni dei servizi colpiti non utilizzavano Cloudflare solo come un CDN stupido. Lo erano:

• Utilizzavano Cloudflare Access per l'autenticazione e l'accesso zero-trust.

• Utilizzando Workers KV come parte dei piani di controllo interni.

• Affidarsi a Turnstile per i login resistenti ai bot. Il blog di Cloudflare+1

Quando questi prodotti si guastano, non sono solo i contenuti del sito web ad andare in tilt, ma anche i login, le funzioni di amministrazione e le API interne. Questo rende il recupero più complesso: la vostra pagina di stato, gli strumenti per gli incidenti o l'interfaccia utente dell'amministrazione potrebbero anche dipendere dallo stesso provider che si è appena guastato.

Cosa cambia secondo Cloudflare

Il blog di Cloudflare illustra diverse misure di rimedio che l'azienda sta già adottando per ridurre il rischio che si ripeta un evento simile: Il blog di Cloudflare

1. Protezione dell'ingestione dei file di configurazione generati automaticamente
   Trattare le configurazioni generate internamente con lo stesso scetticismo e la stessa convalida degli input forniti dall'utente, compreso un rigoroso controllo dello schema e delle dimensioni prima del rollout.

2. Più kill switch globali
   Rendere più facile disabilitare rapidamente i moduli interni problematici (come Bot Management) in tutta la rete, in modo che falliscano all'apertura invece di gettare nel panico l'intero percorso proxy.

3. Proteggere le risorse di sistema dalle tempeste di errori
   Assicuratevi che i dump del core, i metadati di debug e gli strumenti di osservabilità non possano sovraccaricare la CPU e la memoria quando gli errori iniziano ad aumentare.

4. Esaminare le modalità di guasto dei moduli del proxy centrale
   Verificate sistematicamente il comportamento di ciascun modulo interno in presenza di input o configurazioni impreviste e assicurate un degrado graduale anziché un guasto globale.

5. Affinare i rollout e l'isolamento
   Sebbene non sia stato spiegato nei minimi dettagli, l'incidente suggerisce che Cloudflare probabilmente segmenterà ulteriormente il modo in cui le nuove configurazioni e i comportamenti del DB si propagano, per ridurre la possibilità che una singola modifica errata influisca sull'intero parco macchine.

Inoltre, Cloudflare ha definito l'incidente come un fallimento assoluto delle proprie aspettative di resilienza, definendolo "inaccettabile" e riconoscendo esplicitamente il dolore che ha causato ai clienti e ai normali utenti di Internet. Il blog di Cloudflare

Lezioni per i team di infrastruttura e SRE

Anche se non state gestendo qualcosa di così grande come Cloudflare, questa interruzione di servizio può fornire alcuni insegnamenti operativi e di progettazione molto pratici:

Trattare la configurazione interna come un input non attendibile

È facile pensare che la "nostra" configurazione generata sia sempre corretta. La giornata di ieri ha mostrato perché questo è pericoloso:

• Convalidare sempre le dimensioni, la forma e i limiti dei file di configurazione prima di applicarli.

• Considerare l'applicazione canaria della configurazione a un piccolo sottoinsieme di traffico o nodi, con rollback automatico in caso di anomalie.

• Mantenere limiti massimi e interruzioni rigorose per il numero di funzioni, la preallocazione della memoria e l'uso della CPU.

Progettare per un fallimento parziale aggraziato

Un bug nel modulo di gestione dei bot non deve mandare in panico l'intero percorso del proxy:

• Predefinito per fail-open vs fail-closed in alcuni livelli di sicurezza quando l'alternativa è l'interruzione completa.

• Creare kill switch chiari e testati per le funzioni non essenziali.

• Assicurarsi che i sottosistemi critici (autenticazione, pagina di stato, strumenti per gli incidenti) possano funzionare in modalità degradata o attraverso percorsi alternativi.

Osservare i segnali giusti

L'oscillazione tra "configurazione buona" e "configurazione cattiva" ogni cinque minuti ha fatto sembrare il segnale un traffico di attacco o un comportamento esterno rumoroso:

• Assicuratevi di avere una correlazione per versione o per configurazione nella vostra pipeline di osservabilità.

• Creare dashboard che rendano visivamente evidenti le modifiche alla configurazione, oltre ai grafici degli errori.

• Includete forti test sintetici da un punto di vista esterno, in modo da poter distinguere rapidamente i guasti interni dai problemi di rete o di percorso.

Non puntate tutto su un unico paniere infrastrutturale

Per le organizzazioni che utilizzano Cloudflare:

• Considerate le configurazioni multi-CDN per le proprietà veramente mission-critical.

• Evitate che la vostra pagina di stato dipenda interamente dallo stesso provider del vostro stack primario (Cloudflare lo fa, ma ieri si sono verificati problemi di coincidenza con l'host della pagina di stato che hanno confuso ulteriormente le cose). Il blog di Cloudflare+1

• Pensateci due volte prima di accoppiare strettamente l'autenticazione, i piani di controllo delle API e la distribuzione del frontend allo stesso fornitore senza percorsi di ripiego.

Il quadro generale

Solo negli ultimi mesi, abbiamo assistito a gravi interruzioni di Microsoft Azure, Amazon Web Services e ora Cloudflare, che hanno messo temporaneamente fuori uso grandi porzioni di servizi per i consumatori e le imprese. AP News+2IlWashington Post+2

Lo schema è chiaro:

• Internet dipende sempre più da una manciata di giganteschi fornitori di infrastrutture.

• Le interruzioni sono spesso autoinflitte, dovute a complessi cambiamenti interni piuttosto che ad attacchi esterni.

• Anche i provider con pratiche SRE di livello mondiale possono essere bloccati da interazioni impreviste tra la configurazione, il comportamento del database e i limiti codificati.

L'incidente di Cloudflare di ieri ci ricorda che il "cloud" non è magico. In fondo, si tratta sempre di software scritto da esseri umani, soggetto alle stesse classi di bug di qualsiasi altra applicazione, solo con ordini di grandezza maggiori di persone che dipendono da esso.

Per gli utenti, l'incidente sarà ricordato soprattutto come "quella mattina in cui X e ChatGPT non si caricavano".
Per gli ingegneri, invece, sarà probabilmente studiato come un esempio da manuale di come sottili bug di configurazione in un sistema distribuito centrale possano trasformarsi in un evento globale su Internet.