Cloudflare Down: Come un Singolo unwrap() in Rust Ha Mandato Offline Metà Internet per 6 Ore

Il 18 novembre 2025, alle 11:20 UTC, è successo qualcosa di incredibile. Cloudflare, l’azienda che gestisce il traffico di circa il 20% dei siti web mondiali, è andata completamente offline per quasi 6 ore.

ChatGPT? Down. Claude? Inaccessibile. Spotify? Silenzio. E migliaia di altri servizi usati da miliardi di persone? Tutti fuori servizio. Contemporaneamente.

La causa? Un singolo unwrap() in Rust che ha mandato in panic l’intera infrastruttura globale di Cloudflare, causando il peggiore outage degli ultimi 6 anni.

Una. Singola. Riga. Di. Codice.

Lascia che ti racconti come è successo. E perché è molto più complesso (e interessante) di “Rust cattivo, programmatori incompetenti”.

Il Giorno in cui Internet Si è Fermato

Alle 11:20 UTC del 18 novembre 2025, qualcosa è andato storto. Molto storto.

Cloudflare ha subito il suo peggiore outage in 6 anni, bloccando l’accesso a molti siti web e piattaforme online per quasi 6 ore. Non stiamo parlando di un piccolo hiccup. Stiamo parlando di un blackout quasi completo che ha colpito:

ChatGPT e Sora (OpenAI)
Claude (Anthropic)
X (ex Twitter)
Truth Social (sì, anche quello di Trump)
Spotify
Shopify
Canva
E letteralmente migliaia di altri servizi

Circa il 20% dei siti web mondiali dipende da Cloudflare per gestire e proteggere il loro traffico. Quando Cloudflare cade, cade anche una fetta enorme di internet.

Il problema? Il sistema non era più in grado di instradare correttamente il traffico, causando errori HTTP 5xx su tutta la linea.

Per 5 ore e mezza, milioni di utenti hanno visto pagine di errore invece dei loro servizi preferiti. Durante l’outage, il prezzo delle azioni Cloudflare è sceso di circa il 3%.

E il bello? Inizialmente Cloudflare sospettava che i sintomi assomigliassero a un attacco DDoS su scala iper-massiva. Spoiler: non era un attacco. Era molto peggio. Era un bug interno.

La Catena di Eventi: Come un Piccolo Cambiamento Ha Causato un Disastro Globale

Ok, mettiamo i pezzi insieme. Perché questo non è stato un singolo punto di fallimento. È stata una cascata perfetta di assunzioni errate, limiti hardcoded, e deployment sincroni che si sono combinati nel modo peggiore possibile.

Atto Primo: Il Cambiamento “Innocente” ai Permessi

Tutto inizia alle 11:05 UTC quando gli engineer di Cloudflare fanno un cambiamento ai permessi del database ClickHouse.

Gli ingegneri stavano migliorando il modo in cui le query distribuite vengono eseguite in ClickHouse, permettendo alle query di restituire metadati sia dal database “default” che dal database sottostante “r0”.

L’intento era buono: migliorare sicurezza e reliability. Il problema? Il codice precedente aveva un’assunzione preimpostata: la lista di colonne restituita da tali query conteneva solo contenuto dal database default, e la query non filtrava per nome del database.

Quando i permessi sono cambiati, quella assunzione è diventata falsa. E in un sistema distribuito complesso, le assunzioni false sono bombe a orologeria.

Atto Secondo: Il File di Configurazione Impazzito

Una modifica ai permessi del database ha causato la generazione di righe duplicate in un file di feature usato dal sistema Bot Management, raddoppiandone le dimensioni.

Aspetta, cosa? Un file “di feature”? Che diavolo è?

Cloudflare usa un sistema di Bot Management per distinguere traffico legittimo da bot malevoli. Questo sistema si basa su un modello di machine learning che genera un “bot score” per ogni richiesta che attraversa la rete.

Il modello prende come input un file di configurazione “feature”. Questo file viene aggiornato ogni pochi minuti e pubblicato su tutta la rete, permettendo di reagire ai cambiamenti nei flussi di traffico internet.

Normalmente, questo file contiene un numero modesto di entry. Il 18 novembre, è improvvisamente raddoppiato di dimensione, superando un limite hardcoded di 200 feature.

E qui casca l’asino: il sistema non validava le dimensioni del file generato. Lo assumeva semplicemente corretto perché generato internamente.

Trust but don’t verify, giusto? Sbagliato.

Atto Terzo: Il Rust Panic che Ha Fatto Crollare Tutto

Ora arriviamo alla parte che ha fatto esplodere Twitter (quando Twitter è tornato online): il codice Rust.

Cloudflare stava migrando dal vecchio proxy engine (FL) a uno nuovo chiamato FL2, scritto in Rust. A settembre 2024, Cloudflare aveva riscritto il suo codice core nel linguaggio “memory-safe” Rust, affermando che grazie alle caratteristiche del linguaggio, questo refactoring era “più veloce e più sicuro”.

Il problema? Quando il file oversized è stato propagato a tutte le macchine FL2, è successo qualcosa del genere (codice semplificato per chiarezza):

let features = parse_config(&config_file).unwrap();

L’unwrap() ha generato un panic: “called Result::unwrap() on an Err value”.

E qui viene il bello: I framework web Rust standard catturano i panic ai confini delle richieste e restituiscono gracefully uno status HTTP 500 sulle richieste che vanno in panic, che è esattamente ciò che è successo nel caso di Cloudflare.

Quindi il sistema ha fatto quello che doveva: ha crashato gracefully. Il problema? Ogni macchina crashava. Contemporaneamente. Su tutta la rete globale.

Un gigantesco boot-loop globale: panic → reboot → panic → repeat.

Atto Quarto: Il Deployment Sincronizzato (aka “Oops, Everything at Once”)

Ma aspetta. Perché tutto è crashato contemporaneamente? Non c’erano canary deployment? Rolling updates? Staged rollouts?

Apparentemente no.

Ogni 5 minuti, una query generava file di configurazione corretti o difettosi, a seconda di quali nodi del cluster erano stati aggiornati, causando fluttuazioni della rete tra stati funzionanti e guasti.

Il file di configurazione veniva sincronizzato simultaneamente su tutte le macchine della rete. Quando il file difettoso è stato pubblicato, ha raggiunto 330+ datacenter praticamente nello stesso momento.

I rollout uniformi sono pericolosi. Gli aggiornamenti sincronizzati all’edge sono pericolosi.

Non c’era un modo per fermare la propagazione gradualmente. Non c’era un fallback automatico alla configurazione precedente. Non c’era un circuit breaker.

Era tutto o niente. E in questo caso, è stato niente.

Ma È Davvero Colpa di Rust?

Ok, quindi abbiamo un unwrap() che ha causato un panic. Chiaramente Rust è terribile e dovremmo tutti tornare a scrivere PHP, giusto?

No. Assolutamente no.

E qui arriva la parte interessante: Questo fallimento sarebbe accaduto in Go, Java, C++, Zig o Python. Il problema non è nato a causa di un unwrap(), né perché Rust incoraggia cattiva gestione degli errori.

Analizziamo i veri problemi:

Problema #1: Validazione Insufficiente dell’Input

Il codice assumeva che i file generati internamente fossero sempre corretti e non implementava controlli di validazione delle dimensioni.

Questa non è una questione di linguaggio. È una questione di architectural decision.

In qualsiasi linguaggio, se assumi che l’input sia sempre valido senza verificarlo, prima o poi ti exploderà in faccia. Rust non ti protegge dalle assunzioni sbagliate. Nessun linguaggio lo fa.

Problema #2: Limiti Hardcoded Senza Graceful Degradation

Il sistema aveva un limite hardcoded di 200 feature. Quando il file ha superato questo limite, invece di:

Loggare un warning e usare le prime 200
Degradare gracefully a un subset
Fallback alla configurazione precedente

Ha semplicemente crashato.

Gestire l’errore e fare shutdown gracefully del proxy perché un invariante importante è stato violato (aka un bug) avrebbe potuto causare lo stesso outage.

Problema #3: Deployment Sincrono Senza Staged Rollout

Cloudflare mancava di controllo preflight della configurazione, limitazione del delta delle dimensioni della config, rollout staged, e fallback alla configurazione precedente funzionante: ognuno di questi avrebbe potuto prevenire l’outage.

Questo è il vero problema. Non il linguaggio. L’architettura.

La Verità Scomoda

Puoi costruire sistemi fragili in linguaggi sicuri e sistemi robusti in linguaggi non sicuri. Il linguaggio è ortogonale alla resilienza architetturale. Rust dà memory safety. Non dà correctness safety. Non dà assumption safety. Non dà rollout safety.

Il vero problema di questo outage non è tecnico. È un problema di marketing e aspettative.

Cloudflare ha venduto la migrazione a Rust come qualcosa che avrebbe reso il sistema “più veloce e più sicuro”. E tecnicamente è vero: Rust previene intere classi di bug come use-after-free, buffer overflow, e race condition.

Ma ha creato un’aspettativa irrealistica: che Rust ti protegga da tutti i bug. E quando inevitabilmente qualcosa è andato storto, la reazione è stata “Vedete? Rust non è speciale”.

Questo non è un fallimento tecnico, è un fallimento di marketing. Non del marketing di Cloudflare, ma del marketing di Rust.

L’Anatomia Completa del Disastro

Ora che abbiamo capito il “cosa” e il “perché”, vediamo esattamente come si è propagato il disastro attraverso l’infrastruttura.

Timeline del Caos

11:05 UTC: Cambiamento ai permessi ClickHouse
11:20 UTC: Primo spike di errori 5xx sulla rete
~12:50 UTC: Cloudflare pubblica il primo status update
13:04 UTC: Patch applicata a Workers KV per bypassare il core proxy
14:30 UTC: Il traffico core torna normale dopo sostituzione del file difettoso
17:06 UTC: Tutti i sistemi completamente operativi

Sono passate quasi 6 ore dall’inizio alla risoluzione completa. In termini di internet time, è un’eternità.

I Servizi Colpiti

L’outage ha colpito i servizi CDN e di sicurezza core di Cloudflare, Turnstile, Workers KV, l’accesso alla dashboard, la sicurezza email e l’autenticazione access.

Ma facciamo il breakdown:

Core CDN e Security Services: HTTP 5xx errors su tutta la linea. Siti web irraggiungibili. API down. È stato un blackout totale per i servizi che dipendevano da Cloudflare.

Turnstile: Il sistema di verifica Turnstile di Cloudflare, usato come parte del flusso di login, è stato impattato dall’outage, impedendo ai clienti senza una sessione dashboard attiva di fare login.

Quindi non solo non potevi accedere ai tuoi servizi, ma non potevi nemmeno accedere alla dashboard di Cloudflare per vedere cosa stava succedendo. Ironia bella.

Workers KV: Spike massivo di error rate fino alla patch delle 13:04.

Cloudflare Access: Ha sperimentato fallimenti di autenticazione dall’inizio dell’incidente. Le sessioni esistenti rimanevano valide, ma i nuovi tentativi fallivano.

Email Security: Ha continuato a processare email ma ha temporaneamente perso accesso a una fonte di reputation IP, riducendo leggermente l’accuratezza del rilevamento spam.

La Risposta (e gli Errori) di Cloudflare

Cloudflare inizialmente sospettava che i sintomi assomigliassero a un attacco DDoS su scala iper-massiva, preoccupazione plasmata in parte dalle recenti campagne di attacco “Aisuru”.

Questo è comprensibile. Quando vedi il tuo traffico esplodere e tutto crasha contemporaneamente, la prima ipotesi è “siamo sotto attacco”.

Ma ha anche causato un ritardo nella diagnosi corretta. Stavano cercando attaccanti esterni quando il problema era un bug interno.

Una volta che gli engineer hanno scoperto il file di feature difettoso, hanno fermato la sua propagazione e reinserito una versione precedente stabile.

La vera domanda è: perché non c’era un meccanismo automatico per fare questo? Perché ha richiesto intervento manuale?

Le Lezioni (Dolorose) da Imparare

Ok, abbastanza analisi post-mortem. Parliamo di cosa dovremmo imparare da questo disastro.

Lezione #1: Non Fidarti Mai dell’Input, Anche Se “Interno”

Cloudflare ha dichiarato che rafforzerà la verifica di ricezione dei file di configurazione generati internamente secondo gli standard di protezione per l’input generato dagli utenti.

Questa è probabilmente la lezione più importante. Solo perché qualcosa è “generato internamente” non significa che sia corretto.

Validate everything. Size limits. Format checks. Sanity checks. Se un file improvvisamente è 2x più grande del solito, questo dovrebbe triggerare almeno un warning, se non un blocco completo.

Lezione #2: Limiti Hardcoded Devono Essere Documentati e Monitorati

Avevi un limite di 200 feature? Ottimo. Ma:

Era documentato da qualche parte perché esisteva?
C’erano alerting quando ti avvicinavi al limite?
C’era un piano per cosa fare se il limite veniva superato?

Apparentemente no a tutte e tre. E questo è un problema.

Lezione #3: Staged Rollouts Non Sono Opzionali

I rollout uniformi sono pericolosi. Gli aggiornamenti sincronizzati all’edge sono pericolosi.

Non importa quanto sei sicuro che una modifica sia safe. Mai deployare tutto contemporaneamente.

Canary deployments. Blue-green deployments. Rolling updates. Circuit breakers. Feature flags.

Scegli il metodo che preferisci, ma devi avere un modo per fermare un rollout problematico prima che colpisca il 100% del tuo sistema.

Lezione #4: Fallback Automatici Sono Essenziali

Quando qualcosa va storto, il sistema dovrebbe automaticamente:

Rilevare il problema
Fermare la propagazione del file difettoso
Tornare all’ultima configurazione funzionante
Alertare gli umani

Tutto questo dovrebbe succedere in secondi, non ore.

Cloudflare ha dichiarato che aggiungerà più interruttori di emergenza globali per le funzioni rilevanti.

Meglio tardi che mai, suppongo.

Lezione #5: Memory Safety ≠ Total Safety

Questa è per la community Rust (e per chiunque venda tecnologia con promesse esagerate):

Rust ti protegge da use-after-free, data races, e buffer overflows. Questo è enorme e estremamente valido.

Ma non ti protegge da:

Logica di business sbagliata
Assunzioni architetturali errate
Problemi di deployment
Configurazioni sbagliate
Limiti dimensionali hardcoded
Mancanza di validation dell’input

Non puoi esternalizzare il giudizio.

Nessun linguaggio di programmazione, non importa quanto “safe”, può compensare decisioni architetturali sbagliate o processi operazionali inadeguati.

Lezione #6: La Centralizzazione È una Singola Point of Failure

Questa è la lezione più scomoda di tutte.

Circa il 20% dei siti web mondiali dipende da Cloudflare. Quando Cloudflare cade, cade anche una fetta gigantesca di internet.

Viviamo in una monocultura di dipendenze. Pochi layer di open source e una manciata di service provider reggono tutto il resto.

Questo è… terrificante? Conveniente? Entrambi?

La verità è che la centralizzazione porta efficienza e costi ridotti. Ma porta anche rischio sistemico.

Se hai un business critico che dipende interamente da Cloudflare (o AWS, o Google Cloud, o qualsiasi singolo provider), non hai un piano di disaster recovery. Hai una speranza e una preghiera.

Il Post-Mortem Onesto di Cloudflare

Devo dare credito dove è dovuto: Cloudflare ha fatto qualcosa di raro nella nostra industria. Hanno pubblicato l’esatto codice che è fallito.

“Data l’importanza dei servizi di Cloudflare, qualsiasi outage è inaccettabile. La rete non è stata in grado di instradare correttamente il traffico per un po’, il che ha profondamente rattristato ogni membro del nostro team. Sappiamo di avervi deluso oggi”, ha scritto Cloudflare nel post-mortem.

Questa trasparenza è rara nel nostro settore. La maggior parte delle aziende avrebbe pubblicato una spiegazione vaga tipo “problema tecnico temporaneo” e chiamato chiuso.

Invece, Cloudflare ha:

Pubblicato una timeline dettagliata
Spiegato esattamente cosa è andato storto
Mostrato il codice difettoso
Ammesso i propri errori
Delineato passi concreti per prevenire recidive

La trasparenza di Cloudflare merita rispetto. La loro cultura ingegneristica merita attenzione.

E francamente? Questo tipo di post-mortem onesto è molto più valido per l’industria che nascondere il problema sotto il tappeto.

Possiamo tutti imparare da questi errori. Ma solo se le aziende sono disposte a condividerli.

I Passi Successivi di Cloudflare

Quindi, cosa farà Cloudflare per assicurarsi che non succeda di nuovo?

L’azienda ha spiegato i passi successivi per rafforzare il sistema, tra cui: rafforzare la verifica di ricezione dei file di configurazione generati internamente secondo gli standard di protezione per l’input generato dagli utenti; aggiungere più interruttori di emergenza globali per le funzioni rilevanti; evitare che core dumps o altri error report occupino troppe risorse di sistema; condurre una revisione completa delle modalità di fallimento degli scenari di errore di tutti i moduli del proxy core.

Sono tutti passi nella giusta direzione. Ma la vera domanda è: perché non c’erano prima di questo outage?

Input validation? Dovrebbe essere standard. Emergency shutoff switches? Dovrebbero già esistere. Resource limits per error reporting? Sembra ovvio.

Il problema è che questi sono il tipo di cose che sono “ovvie in retrospect” ma facili da trascurare quando stai costruendo velocemente e shippando features.

È la natura del software engineering moderno: move fast and break things. Fino a quando “things” significa “metà di internet”.

Il Significato Più Ampio: Il Problema della Monocultura di Internet

Zoom out un secondo. Questo outage non è solo su Cloudflare o Rust o bot management.

È su come abbiamo costruito internet nel 2025.

Viviamo in una monocultura di dipendenze. Pochi layer di open source e una manciata di service provider reggono tutto il resto.

Pensa a cosa è successo:

Un CDN va giù
ChatGPT diventa inaccessibile
Spotify smette di funzionare
E-commerce va offline
Trasporto pubblico ha problemi

Questi servizi non hanno nulla a che fare l’uno con l’altro. Ma tutti dipendono dalla stessa infrastruttura sottostante.

È un problema dell’ecosistema, non un problema di Cloudflare.

E non c’è una soluzione facile. La centralizzazione porta efficienza. Ma porta anche fragilità sistemica.

Quando tutto dipende da poche aziende giganti, un singolo punto di fallimento può causare un effetto domino catastrofico.

È come avere un’intera città che dipende da una singola centrale elettrica. Efficiente? Assolutamente. Resiliente? Assolutamente no.

Cosa Puoi Fare Tu (Oltre a Pregare)

Ok, lezione di filosofia dell’architettura internet finita. Parliamo di cose pratiche.

Se Sei un Developer

1. Non fidarti mai dell’input

Anche se “è generato internamente”. Anche se “è da un sistema fidato”. Validate. Always.

2. Implementa staged rollouts

Canary deployments. Feature flags. Progressive rollouts. Scegli quello che preferisci, ma mai all-at-once.

3. Costruisci fallback automatici

Quando qualcosa va storto, il sistema dovrebbe automaticamente tornare a uno stato funzionante. Non dopo ore di debugging. Immediatamente.

4. Monitora le assunzioni

Se il tuo codice assume che un file sia sempre sotto 200 entries, monitora quella metrica. Quando si avvicina a 180, alert. A 190, panic (non è un gioco di parole).

5. Scrivi post-mortem onesti

Quando qualcosa va storto (e andrà storto), scrivilo. Condividilo. Lascia che altri imparino dai tuoi errori.

Se Gestisci Infrastruttura Critica

1. Diversifica i tuoi provider

Non mettere tutte le uova nello stesso paniere. Multi-cloud. Multi-CDN. È più costoso? Sì. Ma quando Cloudflare va giù, il tuo servizio resta su.

2. Implementa circuit breakers

Se un servizio esterno inizia a fallire, il tuo sistema dovrebbe automaticamente fermare di dipendere da esso (o degradare gracefully).

3. Testa i scenari di fallimento

Chaos engineering non è solo per Netflix. Spegni componenti random del tuo stack e vedi cosa succede. Meglio scoprirlo ora che durante un outage reale.

4. Documenta le dipendenze

Sai esattamente da quali servizi esterni dipendi? Tutti? Hai un piano per quando ognuno di essi fallisce?

Se Sei un Utente Finale

Onestamente? Non c’è molto che puoi fare.

Quando infrastruttura critica come Cloudflare va giù, sei alla loro mercé. L’unica consolazione è che:

È relativamente raro (questo è stato il primo outage così massiccio in 6 anni)
Di solito viene risolto in poche ore
Non sei l’unico - metà di internet è nella stessa barca

Considerare servizi che non dipendono da un singolo provider gigante? (Ne esistono ancora nel 2025?)

La Battuta Finale (Letteralmente)

Quindi, per rispondere alla domanda che tutti si sono posti: sì, è vero che si può riassumere tutto con “hai voluto Rust, ora settalo bene altrimenti crasha tutto”.

Ma è anche riduttivo.

Questo outage ci insegna che:

La tecnologia “sicura” non è un silver bullet
L’architettura conta più del linguaggio
Le assunzioni sono pericolose
La centralizzazione è fragile
La trasparenza è preziosa

Internet non è andato giù per colpa di Rust. È andato giù perché l’internet moderno è tenuto insieme da coordinazione, fiducia e assunzioni stratificate che occasionalmente collidono in modi sorprendenti.

E se vogliamo un futuro più resiliente, abbiamo bisogno di meno biasimo e più comprensione. Meno certezza e più curiosità. Meno tribalismo linguistico e più pensiero di system design.

Oh, e forse qualche staged rollout in più. Quello aiuterebbe anche.

Fonti:

Sei stato colpito da questo outage? ChatGPT down proprio quando ne avevi bisogno? Spotify che ti ha lasciato senza musica? Condividi la tua esperienza nei commenti – il dolore condiviso è dolore dimezzato. O almeno fa ridere.