Punti chiave
Il 18 novembre 2025, Cloudflare, un fornitore di infrastruttura internet, ha subito una grave interruzione globale del servizio. L’incidente è iniziato intorno alle 11:20 e si è protratto per circa tre ore, causando un’ampia degradazione della connettività per milioni di utenti e servizi in tutto il mondo.
Classificazione e portata dell’incidente
L’interruzione è stata ufficialmente classificata come un guasto operativo interno e non come il risultato di un attacco informatico o attività malevola. Questo distingue l’evento da incidenti di sicurezza, concentrando l’analisi sulle vulnerabilità sistemiche della configurazione e del software. La portata del guasto si è manifestata principalmente attraverso la diffusione di errori HTTP 500 (Internal Server Error) e la contemporanea paralisi della Cloudflare Dashboard e delle API di gestione. Tali sintomi hanno esposto una profonda dipendenza dall’infrastruttura centralizzata di Cloudflare, compromettendo la stabilità della rete per una porzione significativa del web globale.
Principali risultati tecnici sulla causa
La causa principale del disservizio è stata ricondotta a un bug latente all’interno del software che gestisce le capacità di mitigazione dei bot e di sicurezza di Cloudflare. Questo difetto preesistente è stato innescato da un file di configurazione del traffico di che era cresciuto “oltre una dimensione prevista”. Quando il sistema software di gestione del traffico ha tentato di elaborare questo file eccessivamente grande, ha innescato un crash.
L’analisi indica una particolare vulnerabilità operativa nei sistemi difensivi. Il paradosso è che la complessità richiesta per difendere la rete (attraverso set di regole di sicurezza granulari e dinamiche) ha introdotto un nuovo vettore di fallimento interno. La configurazione di sicurezza altamente dinamica deve essere gestita con lo stesso rigore di validazione impiegato nello sviluppo e nel distribuzione del codice.
Anatomia di un Disservizio
Dossier Tecnico: Interruzione di Cloudflare a cura di Alground
Sintesi Esecutiva: L’Impatto
Il 18 novembre 2025, una porzione significativa di internet ha subito gravi disservizi a causa di una grave interruzione in Cloudflare, un fornitore critico di servizi di infrastruttura. Questo rapporto visivo analizza la cronologia, l’impatto e la causa tecnica principale dell’incidente.
Durata approssimativa dell’interruzione diffusa dei servizi e dell’aumento dei tassi di errore.
Calo di traffico segnalato per le principali piattaforme colpite durante il picco dell’incidente.
Raggio d’Impatto: Chi è Stato Colpito?
Cloudflare opera come reverse proxy per milioni di siti web, fornendo sicurezza (WAF), prestazioni (CDN) e servizi DNS. L’interruzione ha immediatamente colpito qualsiasi servizio che si affidasse alla loro rete, portando a una cascata di disservizi in diversi settori.
Picco di Segnalazioni di Disservizio
Le segnalazioni degli utenti su piattaforme come Downdetector sono aumentate, in corrispondenza diretta con il guasto del servizio.
Settori di Servizio Colpiti
Il disservizio è stato avvertito in tutti i settori, colpendo piattaforme AI critiche, social media e servizi di e-commerce.
Cronologia dell’Evento (CET)
L’incidente si è sviluppato rapidamente durante una fascia oraria ad alto traffico, con le prime segnalazioni emerse poco prima delle 10:30 CET e le azioni di risoluzione iniziate intorno alle 11:00 CET.
12:28 CET
Segnalazioni iniziali degli utenti di errori 5xx e fallimenti di connessione per i principali siti (X, OpenAI) in forte aumento.
12:35 CET
Cloudflare pubblica l’avviso iniziale “Indagine in corso” sulla sua pagina di stato, riconoscendo problemi diffusi.
12:45 CET
Il disservizio raggiunge il picco. Downdetector mostra decine di migliaia di segnalazioni per dozzine di servizi.
13:02 CET
Cloudflare identifica la causa principale come una “distribuzione software fallita” e avvia le procedure di rollback.
13:30 CET
I servizi iniziano a stabilizzarsi a livello globale con la propagazione della correzione. Stato di Cloudflare aggiornato a “Monitoraggio”.
Analisi Tecnica della Causa Principale
Le fonti indicano che il disservizio non è stato un attacco doloso ma un errore interno. Un push software errato a un data center critico ha innescato un fallimento a cascata nel Border Gateway Protocol (BGP), ritirando di fatto i servizi principali dalle tabelle di routing di internet.
Diagramma di Flusso della Cascata di Fallimenti
1. Distribuzione Software
Una nuova configurazione è stata inviata a un data center centrale (es. Ashburn, VA).
2. Errore di Configurazione BGP
L’aggiornamento conteneva un errore che causava l’annuncio di route BGP errate.
3. Fallimento a Cascata
Route non corrette si sono propagate a livello globale, portando altri router a interrompere le connessioni con la rete Cloudflare.
4. Servizi Fuori Linea
I servizi gestiti da Cloudflare sono diventati irraggiungibili, risultando in errori 5xx.
Risoluzione e Punti Chiave
Il problema è stato risolto con il rollback della distribuzione software difettosa. Questo incidente evidenzia l’immensa centralizzazione dell’infrastruttura internet e il rischio sistemico associato ai punti singoli di fallimento, anche in reti altamente resilienti.
- Rischio di Centralizzazione: L’eccessiva dipendenza da pochi grandi fornitori di infrastrutture significa che piccoli errori possono avere conseguenze globali.
- Fragilità BGP: Il protocollo di routing centrale di internet (BGP) si basa sulla fiducia e può essere vulnerabile a errori di configurazione che si diffondono rapidamente.
- Importanza dei Rollback: L’identificazione rapida e le procedure di rollback sono essenziali per mitigare la durata dei disservizi causati internamente.
Implicazioni strategiche immediate
L’evento ha immediatamente evidenziato i gravi rischi associati alla centralizzazione dell’infrastruttura internet, agendo come un chiaro Punto Singolo di Fallimento (SPOF) a livello globale. A livello finanziario, l’interruzione ha causato un calo del valore azionario di Cloudflare e ha aumentato l’attenzione da parte dei clienti aziendali.
Poiché Cloudflare aveva già sperimentato diverse interruzioni minori nel 2025 (incluso giugno, luglio e settembre ), la frequenza cumulativa degli incidenti amplifica l’ansia di investitori e clienti, rendendo imperativa la necessità di una trasparenza eccezionale nell’analisi post-mortem per mitigare una potenziale perdita di clientela a lungo termine. Questa preoccupazione è destinata ad accelerare l’adozione di architetture più complesse, ma resilienti, come il Multi-CDN (Content Delivery Network) e il Global Server Load Balancing (GSLB).
Cronologia dell’incidente e valutazione dell’impatto globale
L’incidente è iniziato intorno alle 12:20 con le prime segnalazioni di un “picco insolito di traffico” che ha innescato l’errore. Alle 12:48 , Cloudflare ha ufficialmente confermato il problema sulla sua pagina di stato, segnalando “Errori 500 diffusi, Cloudflare Dashboard e API in fallimento”.
Vi era una sovrapposizione temporale con una manutenzione programmata (ad esempio, nel datacenter SCL di Santiago, tra le 12:00 e le 15:00 UTC), sebbene le fonti non colleghino direttamente i due eventi, sollevando interrogativi sulla sincronizzazione della gestione dei cambiamenti. L’interruzione ha raggiunto il picco intorno alle 13:00 , con il sito di monitoraggio Downdetector (ironicamente anch’esso brevemente colpito a causa della dipendenza da Cloudflare) che registrava il massimo delle segnalazioni. Il servizio è stato dichiarato pienamente risolto alle 15:30.
Sintomatologia tecnica e risposta agli errori
La sintomatologia dominante è stata la comparsa di Errori HTTP 500, indicando un fallimento interno ai server di reverse proxy di Cloudflare che impediva l’elaborazione del traffico.
Un sintomo secondario, ma cruciale, è stato il fallimento dello strato di sicurezza, che ha generato il messaggio di blocco: “Please unblock challenges.cloudflare.com to proceed”. Questo messaggio indica che il sistema di sicurezza e challenge (WAF/Bot Mitigation) di Cloudflare era in uno stato di malfunzionamento. Il WAF, anziché reindirizzare correttamente il traffico o servire il contenuto in cache, ha bloccato aggressivamente gli utenti legittimi dall’accedere ai contenuti di origine, anche se i server web sottostanti potevano essere operativi.
La terza manifestazione critica è stata la paralisi del Control Plane, ovvero l’inaccessibilità della Dashboard e delle API. Questo ha impedito ai tecnici di Cloudflare e ai clienti di monitorare lo stato in tempo reale o di eseguire rapidamente modifiche alla configurazione per il ripristino. Il fatto che un fallimento del sistema edge possa contemporaneamente abbattere l’infrastruttura di gestione indica che l’architettura di controllo non è sufficientemente isolata dal data plane critico.
Impatto operativo trasversale
L’interruzione ha avuto un impatto vasto, sottolineando il ruolo centrale di Cloudflare nell’ecosistema digitale moderno:
- Social Media e Intelligenza Artificiale (AI): Piattaforme ad alta intensità di traffico come X (precedentemente Twitter), e fornitori di servizi AI di nuova generazione come OpenAI (ChatGPT e Sora) e Claude AI sono stati gravemente colpiti. La dipendenza di questi servizi dall’infrastruttura CDN/sicurezza di Cloudflare è stata imponente.
- Settori Economici: L’impatto si è esteso a piattaforme di e-commerce (Shopify), servizi finanziari (Coinbase, PayPal) e applicazioni di trasporto (Uber, NJ Transit), dimostrando l’ampiezza delle ripercussioni economiche generate da un fallimento a livello di infrastruttura.
L’analisi della sintomatologia rivela che un guasto sistemico di basso livello, innescato da un bug latente e un overflow di dati interni, si è tradotto in errori catastrofici di alto livello (500), creando un’interruzione di servizio globale.
| Orario | Sintomo Osservato | Componente Colpito | Significato Tecnico |
| 12:20 | Picco di errore iniziale | Software di Mitigazione Minacce | Carico di configurazione ha superato la capacità del sistema |
| 12:48 | Errori 500 Globali & Dashboard Inattiva | Rete Edge / Control Plane | Crash simultaneo del data plane e deterioramento del sistema di gestione |
| 13:00 | Errore di Blocco WAF | Livello di Challenge di Sicurezza (WAF) | Fallimento nel servire i contenuti a causa di una logica di sicurezza corrotta |
| 15:30 | Risoluzione e Ripristino | Rete Globale | Avvio del rollback della configurazione problematica |
Il malfunzionamento è stato direttamente collegato a un file di configurazione generato dinamicamente, utilizzato dai servizi di mitigazione dei bot o dal Web Application Firewall (WAF) di Cloudflare. Questo file contiene una serie di regole necessarie per proteggere i siti web identificando e bloccando i pattern di traffico dannoso. In un ambiente di Content Delivery Network (CDN) globale come Cloudflare, che impiega migliaia di Point of Presence (PoP), la configurazione deve essere propagata in modo quasi istantaneo a tutti i server edge.
Meccanismo del bug latente
Il fallimento si è verificato quando il file di configurazione in questione si è espanso, raggiungendo una dimensione inattesa ed eccessiva (“beyond an expected size of entries”). Il difetto latente risiedeva nel componente software incaricato di analizzare, caricare o applicare questo file di configurazione ai motori di gestione del traffico.
L’analisi dei sistemi distribuiti suggerisce che l’overflow della dimensione del file abbia causato un esaurimento di risorse. È probabile che si sia verificato un fallimento nell’allocazione della memoria (RAM) o un potenziale buffer overflow quando il software ha tentato di ingerire l’enorme set di regole. Quando un processo di sistema incontra un errore fatale nell’allocazione delle risorse critiche, può innescare un crash del processo o un kernel panic su tutta la flotta distribuita di server edge.
Questo evento mette in luce i pericoli derivanti dall’affidarsi a limiti impliciti. La configurazione non era vincolata da un limite di dimensione definito, e il software di gestione non possedeva meccanismi di controllo degli errori sufficientemente robusti o l’applicazione esplicita di vincoli di dimensione prima del caricamento critico. Tali omissioni rappresentano un difetto fondamentale nella progettazione dei sistemi distribuiti, dove l’ottimizzazione delle prestazioni spesso compromette la verifica robusta dei limiti.
Distinzione da attacchi esterni
Sebbene l’interruzione sia stata inizialmente attribuita a un “picco insolito di traffico” il quale funge da trigger che ha causato la crescita dinamica del file di configurazione Cloudflare ha fornito chiare dichiarazioni escludendo l’attività malevola o attacchi DDoS come causa radice. Il fallimento è stato categoricamente definito come interno e sistemico.
Processo di ripristino
La risoluzione primaria dell’incidente ha richiesto l’identificazione della configurazione errata e l’implementazione di un fix. La difficoltà nel ripristino è stata esacerbata dal Control Plane in panne, che ha rallentato la capacità di diagnosticare rapidamente il problema di configurazione e di eseguire il rollback globale.
OpenAI, con servizi come ChatGPT e Sora, richiede API ad alta velocità e bassa latenza. Cloudflare opera come un gateway API essenziale per la sicurezza e il rate limiting.14 Il fallimento di OpenAI e Claude AI durante l’interruzione non è stato dovuto a un guasto delle loro infrastrutture di calcolo, ma al blocco avvenuto a livello di reverse proxy di Cloudflare.
La manifestazione dell’errore WAF implica che gli utenti sono stati respinti alla “porta d’ingresso” del sistema. L’infrastruttura di OpenAI, seppur potenzialmente sana, è diventata inaccessibile perché il servizio di accesso e sicurezza di Cloudflare era in uno stato di blocco. Di conseguenza, la possibilità per l’AI provider di eseguire un failover rapido è stata annullata, poiché il blocco è avvenuto a un livello (Layer 7 Proxy/WAF) troppo basso per consentire l’attivazione di meccanismi di fallback a livello applicativo (come quelli offerti da soluzioni come Cloudflare AI Gateway).
L’impatto universale su piattaforme come X, Spotify e Canva suggerisce che queste entità utilizzano Cloudflare per funzioni fondamentali: non solo la distribuzione di contenuti statici (CDN), ma anche la mitigazione DDoS, la risoluzione DNS e il reverse proxying del traffico applicativo di base.
La strategia di affidarsi a un singolo fornitore per il WAF e il DNS crea un collo di bottiglia architetturale. L’incapacità di risolvere le challenge di sicurezza o di instradare il traffico a causa del guasto del ruleset del WAF ha paralizzato l’intera applicazione, indipendentemente dalle misure di scalabilità o ridondanza interna adottate dal cliente.7
Fragilità di DNS e Routing Anycast
Cloudflare sfrutta il routing Anycast per annunciare i suoi indirizzi IP globalmente, dirigendo il traffico verso il PoP più vicino. Sebbene ciò massimizzi le prestazioni, comporta un rischio. Una singola misconfigurazione o un crash del software che influisce sulla distribuzione interna dello stato di configurazione può innescare un fallimento simultaneo e globale in tutti i PoP che pubblicizzano le rotte Anycast. Precedenti eventi, come l’interruzione del resolver DNS 1.1.1.1 nel luglio 2025, hanno già dimostrato come errori di configurazione interni possano portare a ritiri di rotta su scala mondiale, causando indisponibilità catastrofica.
Il comportamento del WAF di Cloudflare, che impone un blocco irrisolvibile, è un esempio di postura di sicurezza “fail closed” aggressiva. Sebbene inteso a prevenire le violazioni, in caso di guasto dell’infrastruttura, garantisce l’indisponibilità totale per gli utenti legittimi. Questo approccio dimostra che per la maggior parte delle applicazioni enterprise (al di fuori delle piattaforme finanziarie ad altissimo rischio), una strategia “fail open” (che permetta un accesso non mitigato ma potenzialmente funzionale) o una “static failure” (che serva contenuto statico dalla cache) è spesso preferibile per la continuità operativa. La dipendenza estrema da un singolo punto di controllo espone X e OpenAI a un significativo debito tecnico derivante dalla centralizzazione, che ora impone una riprogettazione urgente per la ridondanza.
L’imperativo della diversificazione dei fornitori
L’incidente ha confermato che anche le piattaforme meglio ingegnerizzate non sono immuni da meccanismi di fallimento imprevisti, quali bug latenti e misconfiguration. La fiducia storica nella robustezza di Cloudflare deve essere bilanciata con la realtà del rischio sistemico. I concorrenti diretti, inclusi Akamai Technologies, Fastly e AWS CloudFront, sono pronti ad assorbire la domanda di resilienza e diversificazione. Le aziende che si affidano a un unico fornitore sono ora costrette a re-immaginare le loro strategie, accelerando l’adozione di approcci multi-cloud e Multi-CDN per mitigare i Punti Singoli di Fallimento.
La strategia Multi-CDN prevede la distribuzione dello stesso traffico attraverso più CDN indipendenti. Per gestire questa complessità, è necessario un livello di routing superiore, noto come Global Server Load Balancing (GSLB).
Il GSLB funge da strato di risoluzione intelligente che distribuisce le richieste tra i fornitori (ad esempio, Cloudflare e Fastly) in base a controlli di integrità in tempo reale (health checks), latenza geografica e prestazioni regionali. Il meccanismo di resilienza è intrinseco: se Cloudflare fallisce un health check a causa di errori 500 diffusi, il GSLB reindirizza automaticamente il 100% del traffico verso il CDN secondario sano, garantendo la continuità operativa.
L’interruzione di Cloudflare del novembre 2025 rappresenta un evento significativo che ha messo in discussione la supposta robustezza dell’infrastruttura internet moderna, evidenziando che i fallimenti operativi interni rimangono la minaccia più pervasiva per l’alta disponibilità.
Raccomandazioni strategiche
Sulla base delle vulnerabilità esposte dall’incidente, si raccomanda ai responsabili tecnici di adottare il seguente piano d’azione immediato:
- Rendere Obbligatoria la Ridondanza Multi-WAF: Implementare almeno due strati WAF/sicurezza indipendenti su fornitori distinti. Ciò mitiga la modalità di fallimento critica osservata a novembre, in cui il fallimento del WAF ha portato al blocco completo.
- Implementare GSLB Robusto con Health Checks in Tempo Reale: Utilizzare il Global Server Load Balancing per instradare il traffico basandosi sullo stato di salute istantaneo dei CDN, assicurando il failover automatico durante gli errori sistemici di tipo 5xx.
- Disaccoppiare il DNS dal CDN: Garantire che la risoluzione DNS primaria e secondaria sia gestita in modo indipendente o attraverso fornitori di servizi diversi per prevenire il fallimento simultaneo di DNS e CDN.
- Applicare Pipeline di Validazione della Configurazione Rigorose: Introdurre test automatizzati rigorosi (pre-flight checks) per tutte le modifiche di configurazione, convalidando esplicitamente la dimensione dei file, l’integrità delle strutture dati e il consumo di risorse rispetto a limiti di sicurezza predefiniti, prima di qualsiasi deployment globale.
- Rivedere gli Accordi sui Livelli di Servizio (SLA): Condurre revisioni immediate degli SLA e dell’idoneità ai crediti di servizio con tutti i fornitori di infrastrutture chiave (CDN, Cloud, DNS) per quantificare e mitigare i rischi finanziari associati ai tempi di inattività.
