Cloudflare, down globale del 18 novembre: cosa è successo davvero ai servizi online

rete internet

Il 18 novembre 2025 è entrato nel calendario aziendale di Cloudflare come uno dei giorni più complessi dalla nascita della società. In poche decine di minuti, una realtà che gestisce CDN, protezione DDoS, sicurezza applicativa e instradamento del traffico per milioni di siti e applicazioni si è trovata al centro di una interruzione diffusa, visibile a chiunque stesse navigando.

La centralità di Cloudflare nelle infrastrutture di rete è tale che un singolo malfunzionamento interno è sufficiente a far comparire, in simultanea, errori sui browser di utenti e aziende in ogni area geografica. È esattamente ciò che è accaduto poco dopo mezzogiorno, quando una ondata di errori 5xx ha reso irraggiungibili numerosi servizi appoggiati alla piattaforma.

A raccontare in dettaglio cosa è successo è stato Matthew Prince, amministratore delegato dell’azienda, in un lungo aggiornamento pubblicato sul blog ufficiale. Fin dall’inizio ha voluto sgombrare il campo da un sospetto prevedibile: non è stato un attacco informatico né il risultato di attività malevole, ma la conseguenza di una modifica interna finita fuori controllo.

Dal cluster ClickHouse al “feature file”: come è iniziato il problema

Secondo la ricostruzione di Prince, tutto ha avuto origine intorno alle 12:05 italiane, quando su un cluster ClickHouse sono stati modificati i permessi relativi a una parte dei dati gestiti dal sistema. L’intervento era pensato per migliorare la gestione e la leggibilità dei permessi all’interno dell’infrastruttura, ma ha generato un effetto collaterale imprevisto: il database ha iniziato a produrre righe duplicate all’interno del cosiddetto feature file.

Questo file di configurazione è un elemento chiave del Bot Management di Cloudflare: contiene i “segnali” che il modello di machine learning usa per stabilire se una richiesta provenga da un utente reale oppure da un bot. Il sistema rigenera il feature file automaticamente ogni pochi minuti e lo distribuisce ai nodi della rete globale, in modo che le decisioni sulla natura del traffico siano sempre aggiornate.

Con l’introduzione dei dati duplicati, la dimensione del file è cresciuta in modo improvviso, superando la soglia gestibile dal componente software incaricato di leggerlo. Da qui è nato un errore interno che ha mandato in crisi una parte del core proxy, cioè il cuore del sistema che instrada e protegge le richieste web.

Il risultato è stato una vera e propria cascata di errori 5xx, diffusi via via che le versioni difettose del feature file raggiungevano i diversi nodi. Nelle fasi iniziali il comportamento del sistema è sembrato ancora più enigmatico: file corretti e file errati continuavano a alternarsi a causa del comportamento instabile del cluster ClickHouse, dando l’impressione di un problema che si risolveva da solo per poi ripresentarsi poco dopo.

A complicare la lettura degli eventi è intervenuta una coincidenza: la pagina di stato pubblica di Cloudflare, ospitata su un’infrastruttura separata, risultava a sua volta irraggiungibile in quelle ore. Questo elemento ha inizialmente rafforzato l’idea di un possibile attacco dall’esterno, prima che l’analisi interna chiarisse la vera natura del guasto.

Errori 5xx a catena: servizi coinvolti e effetti per gli utenti

Il collasso della rete Cloudflare è apparso in modo evidente intorno alle 12:20 italiane, quando la configurazione alterata ha raggiunto un numero sufficiente di nodi da produrre un blocco generalizzato. Da quel momento, la crescita degli errori è stata rapida e coerente con la diffusione del feature file corrotto, fino al raggiungimento della fase più grave del blackout.

Le conseguenze si sono fatte sentire su diversi fronti. La CDN e l’intero livello di sicurezza applicativa hanno iniziato a restituire agli utenti la pagina di errore HTTP generata dal core proxy, rendendo molti siti improvvisamente non disponibili. Il sistema Turnstile, usato per i controlli di verifica nelle pagine web e nei flussi di autenticazione, non riusciva più a caricarsi in modo corretto, bloccando di fatto alcuni passaggi chiave per l’accesso ai servizi.

Anche Workers KV, il sistema di archiviazione chiave-valore utilizzato da numerose applicazioni serverless sulla piattaforma, ha registrato un incremento netto di risposte 5xx. La dashboard di Cloudflare, l’interfaccia con cui amministratori e sviluppatori gestiscono i propri domini, risultava consultabile soltanto per chi aveva già una sessione attiva: il processo di login si appoggiava infatti a componenti che, in quel momento, non erano in grado di funzionare.

Sul fronte della Email Security sono emersi problemi nel recupero delle informazioni sulla reputazione degli indirizzi IP e nelle automazioni legate al filtraggio della posta, con procedure che non venivano eseguite come previsto. Anche Cloudflare Access, il servizio che protegge l’accesso alle applicazioni interne, falliva quasi sempre le autenticazioni, impedendo alle organizzazioni di raggiungere risorse aziendali critiche.

A tutto questo si è sommato un incremento generale della latenza. I sistemi interni di analisi e debugging, nel tentativo di arricchire le segnalazioni con dettagli diagnostici utili, hanno iniziato a generare traffico aggiuntivo proprio mentre l’infrastruttura era sotto stress, finendo per aggravare il carico complessivo nei minuti più delicati.

Cronologia del ripristino e contromisure annunciate da Cloudflare

La fase decisiva del ripristino è iniziata attorno alle 13:00 italiane, quando i tecnici hanno iniziato a restringere il perimetro della ricerca, collegando con sempre maggiore chiarezza l’anomalia al comportamento del sistema di Bot Management. Alle 13:05 sono stati introdotti primi bypass per Workers KV e per Access, che sono stati fatti appoggiare temporaneamente a una versione precedente del proxy, riducendo i disagi su autenticazioni e percorsi applicativi più sensibili.

Il passo chiave è arrivato alle 14:24, quando il team ha individuato con certezza il feature file difettoso come origine dell’interruzione. La sua distribuzione è stata immediatamente bloccata, in modo da evitare che nuove copie errate raggiungessero altri nodi della rete. Pochi minuti dopo, alle 14:30, una versione precedente e corretta del file è stata preparata, verificata e distribuita sull’infrastruttura globale, permettendo al traffico di tornare gradualmente su livelli vicini alla normalità.

Da lì è iniziata una fase più lenta ma necessaria: il riavvio e il riallineamento dei servizi secondari che erano entrati in stato critico durante il blackout. Questo lavoro si è protratto per diverse ore, fino alle 18:06, quando Cloudflare ha dichiarato l’intero ecosistema dei propri servizi di nuovo pienamente operativo.

Conclusa l’emergenza, Prince ha delineato una serie di interventi strutturali. In primo luogo, i file di configurazione verranno trattati come se fossero contenuti provenienti dagli utenti, con livelli di verifica più severi prima della distribuzione globale, per intercettare anomalie in fase precoce. Verranno introdotti kill switch globali, cioè meccanismi in grado di bloccare in modo quasi immediato la diffusione di un file non valido non appena emergono segnali anomali.

Un’altra misura riguarderà i sistemi che generano i report di errore: l’obiettivo dichiarato è evitare che, in presenza di molte segnalazioni, questi strumenti consumino risorse essenziali e peggiorino la stabilità dell’infrastruttura. È prevista inoltre una revisione approfondita dei moduli del core proxy, per analizzare come ciascun componente reagisce ai dati inattesi e ridurre la possibilità che condizioni non previste generino nuovi scenari simili.

Nelle sue considerazioni finali, il CEO ha definito quanto accaduto la peggiore interruzione registrata dall’azienda dal 2019 e ha spiegato che un episodio di questo tipo, per un attore così centrale nelle infrastrutture di rete, viene considerato del tutto inaccettabile. Il messaggio rivolto a clienti e utenti è stato netto: Cloudflare riconosce la gravità del blackout del 18 novembre, si scusa apertamente per i disagi causati e assicura che quanto accaduto diventerà materia di lavoro per ridurre il rischio di nuovi guasti di questa portata.

CONDIVIDI L'ARTICOLO