Il rapporto Cloudflare Radar ricostruisce le principali interruzioni del secondo trimestre del 2026. Dietro ogni disservizio ricompaiono energia, cavi, data center, errori umani e decisioni politiche
LA NOTIZIA IN BREVE – Per mandare in crisi Internet non serve necessariamente un attacco informatico. Nel secondo trimestre del 2026 sono bastati un tifone, un blackout, un cavo reciso e perfino un errore nella gestione delle chiavi di sicurezza per ridurre la connettività di interi Paesi. Il rapporto di Cloudflare Radar racconta una rete molto meno invulnerabile di quanto appaia: dietro servizi digitali, cloud e piattaforme globali restano centrali elettriche, infrastrutture fisiche, data center e decisioni politiche. A Guam il traffico è crollato durante il passaggio del tifone Sinlaku; in Tanzania la rete ha ceduto insieme all’elettricità; in Germania un problema DNSSEC ha reso irraggiungibili numerosi domini .de. In Sudan e Iraq, invece, Internet è stata limitata per scelta delle autorità durante gli esami. Il vero punto debole non è un singolo nodo, ma la dipendenza reciproca tra sistemi che sembrano separati e invece possono fermarsi uno dopo l’altro.
Se vuoi andare oltre alla sintesi della nostra notizia leggi qui di seguito l’approfondimento
L’APPROFONDIMENTO – L’infrastruttura globale su cui viaggiano i servizi Internet è più fragile di quanto si possa pensare. Nel secondo trimestre del 2026 sono bastati un tifone, alcuni blackout, il taglio di un cavo in fibra e un errore nella gestione delle chiavi di sicurezza per rallentare o isolare interi Paesi. In altri casi non si è rotto nulla: sono stati i governi a limitare deliberatamente l’accesso alla rete. Il rapporto trimestrale di Cloudflare Radar mette insieme episodi molto diversi, accomunati da una conseguenza concreta: quando una parte dell’infrastruttura cede, comunicazioni, pagamenti, attività economiche e servizi pubblici possono fermarsi quasi nello stesso momento.
Internet viene spesso descritta come una rete distribuita, capace di trovare automaticamente una strada alternativa quando un nodo smette di funzionare. Questo è vero, ma soltanto in parte. I dati possono essere replicati, il traffico può cambiare percorso e le applicazioni possono essere trasferite su un altro centro di elaborazione. Ma antenne, router e data center hanno bisogno di elettricità; i continenti restano collegati da cavi fisici; i domini dipendono da sistemi di risoluzione condivisi. E l’ultimo tratto della connessione, quello che raggiunge abitazioni e aziende, difficilmente dispone delle stesse protezioni riservate alle grandi dorsali.
Che cosa è successo a Guam durante il tifone?
L’interruzione più lunga osservata nel trimestre è stata associata al Super Tifone Sinlaku, passato a metà aprile poco a nord di Guam. L’isola ha evitato l’impatto diretto, ma i forti venti hanno danneggiato la rete elettrica e creato problemi anche al sistema idrico. Tra il 13 e il 14 aprile il traffico Internet rilevato da Cloudflare è sceso fino all’80% sotto i livelli attesi.
La percentuale non equivale necessariamente al numero di connessioni rimaste fuori servizio. Cloudflare confronta i dati transitati sulla propria rete con il volume che si sarebbe normalmente registrato nello stesso periodo. Una caduta di quelle dimensioni indica comunque che gran parte dell’attività digitale dell’isola è stata compromessa.
La sequenza è nota agli operatori delle telecomunicazioni. Quando manca la corrente, gli apparati continuano a funzionare grazie a batterie e generatori. Sono soluzioni pensate per superare interruzioni limitate, non per garantire un’autonomia indefinita. Se il guasto si prolunga, occorrono carburante, manutenzione e strade percorribili per raggiungere i siti. Un’infrastruttura di rete può quindi essere tecnicamente integra e spegnersi lo stesso.
Il caso di Guam ridimensiona anche una convinzione molto diffusa tra le imprese: replicare i dati in più regioni cloud non risolve ogni problema di continuità. Il servizio centrale può restare perfettamente disponibile, mentre dipendenti e clienti non riescono più a raggiungerlo. La vulnerabilità, in quel momento, non si trova nei server ma nelle reti locali e nell’alimentazione che le mantiene operative.
Leggi di più
Che cosa hanno mostrato i terremoti in Venezuela?
Il 24 giugno due terremoti hanno colpito il Venezuela settentrionale a meno di un minuto di distanza. Il catalogo dello United States Geological Survey attribuisce ai due eventi principali magnitudo 7,2 e 7,5. Circa 25 minuti più tardi è stata registrata un’altra scossa di magnitudo 6,9.
Il dato corregge un’imprecisione presente nel materiale iniziale, che indicava entrambe le prime scosse come terremoti di magnitudo 7,5. Nello stesso momento Cloudflare ha osservato un netto calo del traffico sulle reti di Fibex Telecom, CANTV e VNET.
La variazione della connettività non dice quanti edifici siano stati danneggiati né consente di stimare le vittime. Può però offrire un primo indizio sull’estensione dei problemi: una caduta simultanea su più operatori può segnalare blackout, guasti alle dorsali o perdita di copertura mobile prima che arrivino informazioni complete dal territorio.
Questo tipo di monitoraggio acquista valore soprattutto nelle prime fasi di un’emergenza. Ospedali, sistemi di allerta, piattaforme della protezione civile e canali istituzionali possono rimanere formalmente online, ma diventano inutili se cittadini e soccorritori non riescono a collegarsi. La continuità digitale non coincide quindi con il semplice funzionamento del centro dati. Comprende tutto il percorso necessario per raggiungerlo.
Perché senza elettricità la rete resiste solo per poche ore?
Il 27 giugno un blackout nazionale in Tanzania ha fatto crollare il traffico Internet per almeno cinque ore. Dal punto di vista dell’utente, gli effetti non erano molto diversi da quelli di uno shutdown imposto dalle autorità: servizi irraggiungibili, comunicazioni interrotte e attività commerciali rallentate.
Le reti mobili sono particolarmente esposte. Ogni stazione radio base dispone di sistemi di emergenza, ma la loro durata varia in base alle batterie installate, al carico e alle possibilità di rifornire i generatori. Proteggere migliaia di siti sparsi sul territorio è molto più complesso che alimentare un singolo grande data center.
La densificazione delle reti, necessaria per aumentare capacità e velocità, moltiplica inoltre il numero degli apparati da mantenere accesi. Le antenne diventano più numerose e vicine agli utenti, ma ciascun nuovo sito rappresenta anche un punto che può restare senza energia.
Per questo i piani di continuità non dovrebbero limitarsi alla copia dei dati. Un’azienda deve sapere per quanto tempo le proprie sedi possono funzionare durante un blackout, quali operatori utilizza e se le connessioni alternative percorrono realmente infrastrutture differenti. Due linee commercialmente separate possono dipendere dalla stessa centrale, dallo stesso cavidotto o dalla medesima dorsale.
Perché l’Iran è tornato online soltanto in parte?
Cloudflare ha documentato anche il graduale ritorno della connettività in Iran dopo un’interruzione nazionale durata 88 giorni, iniziata il 28 febbraio. I primi segnali di riapertura sono comparsi il 26 maggio. Il giorno successivo il traffico aveva recuperato circa il 40% dei livelli precedenti; dopo una risalita temporanea, si è stabilizzato intorno al 59%.
Dire che un Paese è tornato online, dunque, può risultare fuorviante. La connessione può essere disponibile soltanto per alcune reti o categorie di utenti; possono restare filtri, rallentamenti, guasti e limitazioni sui servizi raggiungibili. La telemetria di Cloudflare non permette di attribuire con certezza il calo a una sola causa, ma mostra chiaramente che il recupero è rimasto incompleto.
La stessa crisi regionale ha interessato la regione cloud AWS me-central-1, negli Emirati Arabi Uniti. Amazon Web Services aveva comunicato il 30 aprile che l’area non era più in grado di sostenere in modo affidabile le applicazioni dei clienti. Aggiornamenti precedenti avevano segnalato danni fisici a strutture negli Emirati e conseguenze su un sito in Bahrein.
È un promemoria poco rassicurante per chi immagina il cloud come uno spazio separato dal territorio. I dati vengono gestiti a distanza, ma restano ospitati in edifici alimentati dalla rete elettrica, collegati da cavi e sottoposti alle condizioni politiche e militari del Paese in cui sorgono.
Scegliere una regione cloud soltanto in base al prezzo, alla latenza o alla normativa applicabile lascia fuori una parte importante della valutazione. Conta anche la stabilità dell’area e, soprattutto, la capacità dell’azienda di spostare davvero i servizi altrove. Una replica inutilizzata e mai sottoposta a prova può rivelarsi inservibile proprio nel momento in cui diventa necessaria.
Perché Sudan e Iraq spengono Internet durante gli esami?
Nel secondo trimestre Cloudflare ha rilevato dieci interruzioni in Sudan e tre in Iraq, tutte disposte per limitare i tentativi di copiatura durante gli esami nazionali.
In Sudan gli shutdown si sono concentrati tra il 13 e il 23 aprile e sono durati circa tre ore e mezza. In Iraq le interruzioni del 2, 11 e 28 giugno si sono protratte per una novantina di minuti. La regolarità degli orari e la ripetizione nei giorni delle prove confermano la natura amministrativa dei cali osservati.
Il provvedimento colpisce però una platea molto più vasta degli studenti. Durante quelle ore la rete diventa meno accessibile anche per banche, negozi, imprese, professionisti e servizi pubblici. L’obiettivo è circoscritto, ma il costo economico e sociale ricade su tutti.
Uno shutdown deciso dal governo è inoltre più difficile da affrontare di un normale guasto. Le imprese possono duplicare i server e utilizzare più fornitori, ma queste precauzioni servono poco quando l’accesso nazionale viene bloccato a monte. In simili contesti tornano utili soluzioni quasi elementari: procedure utilizzabili offline, copie locali dei dati indispensabili, canali telefonici alternativi e istruzioni definite in anticipo. Benché non siano strumenti capaci di sostituire Internet, possono tuttavia evitare che ogni attività si fermi insieme alla rete.
Come ha fatto un errore DNSSEC a bloccare i domini tedeschi?
Il 5 maggio numerosi siti con estensione .de sono diventati irraggiungibili per circa tre ore. La causa non era un attacco informatico, ma un errore avvenuto durante il cambio programmato delle chiavi DNSSEC.
Il DNS è il sistema che associa il nome di un sito all’indirizzo numerico del server. DNSSEC aggiunge firme crittografiche per verificare che la risposta non sia stata alterata. Se le firme risultano incoerenti, i sistemi che effettuano il controllo scartano la risposta. Il server continua a funzionare, ma il browser non riesce più a raggiungerlo.
Il rapporto pubblicato da DENIC, il registro responsabile del dominio tedesco, ha ricostruito una catena di errori molto concreta. Un difetto nel software impiegato per il cambio delle chiavi aveva generato tre coppie differenti, una per ciascun modulo hardware, assegnando a tutte lo stesso identificatore. Nel registro era stata pubblicata soltanto una delle chiavi pubbliche. Di conseguenza, una parte consistente delle firme non poteva essere verificata.
Il problema non era emerso durante i test perché l’ambiente di prova utilizzava un solo modulo hardware. In produzione, invece, gli apparati erano tre. I sistemi di monitoraggio avevano anche rilevato gli errori, ma le segnalazioni non avevano prodotto l’intervento necessario.
L’incidente tedesco non racconta quindi la fragilità di una tecnologia troppo complessa in senso astratto. Mostra un difetto nel codice, un ambiente di prova incompleto e una gestione inadeguata degli allarmi. Tre problemi separati che, sovrapponendosi, hanno reso inaccessibili servizi perfettamente funzionanti.
Quanto può pesare il taglio di un solo cavo?
La sera del 21 giugno il traffico della rete Karib Cable, a Saint Lucia, è precipitato quasi a zero. Il guasto è stato attribuito al taglio di un collegamento in fibra vicino all’isola. Poiché l’operatore rappresenta uno dei principali fornitori locali, l’incidente ha ridotto di circa il 60% il traffico Internet nazionale rispetto alla settimana precedente.
I piccoli Stati insulari dipendono spesso da un numero limitato di collegamenti verso l’esterno. Quando uno viene meno, le tratte rimaste possono non avere capacità sufficiente per assorbire tutto il traffico. In alcuni casi l’alternativa esiste sulla carta, ma condivide con il collegamento principale una stazione di approdo, un condotto o un tratto terrestre.
La vera ridondanza richiede percorsi fisicamente separati. Due cavi posati nello stesso punto possono essere interrotti dalla stessa ruspa, dalla stessa frana o dalla stessa ancora. Contare le linee disponibili, senza sapere dove passano, restituisce quindi un’immagine incompleta della sicurezza.
Quanto sono rappresentativi i dati di Cloudflare?
Cloudflare gestisce una parte significativa del traffico mondiale, ma non osserva ogni connessione. Radar utilizza dati aggregati e anonimizzati provenienti dalla rete dell’azienda, dal resolver pubblico 1.1.1.1, dai flussi di rete e dalle richieste indirizzate ai siti distribuiti attraverso la sua piattaforma.
I grafici mostrano variazioni rispetto all’andamento abituale, non il numero esatto di utenti rimasti senza collegamento. Anche l’attribuzione delle cause viene integrata con comunicazioni di operatori, autorità e mezzi di informazione. Cloudflare presenta infatti il proprio rapporto come una selezione degli eventi più rilevanti e documentati, non come un censimento completo di tutte le interruzioni avvenute nel mondo.
Il limite va tenuto presente, soprattutto quando le percentuali sono molto elevate. Un calo dell’80% del traffico osservato non significa automaticamente che l’80% degli abitanti sia rimasto senza Internet. Indica però un cambiamento abbastanza forte da rendere evidente una crisi nella connettività.
Quando il crollo compare nello stesso momento su più operatori e coincide con un terremoto o un blackout, il dato può offrire una prima misura dell’impatto. La ricostruzione completa richiede poi le informazioni dei gestori telefonici, delle autorità, dei punti di interscambio e delle società elettriche.
Che cosa dovrebbe fare l’Italia?
L’Italia ha recepito la direttiva europea NIS2 con il decreto legislativo 138 del 4 settembre 2024. La disciplina riguarda, tra gli altri, operatori di comunicazioni elettroniche, fornitori cloud, data center, servizi DNS e numerosi soggetti pubblici e privati considerati essenziali o importanti. L’autorità nazionale competente è l’Agenzia per la cybersicurezza nazionale.
La normativa non si limita agli attacchi informatici. La gestione del rischio deve comprendere anche incendi, alluvioni, guasti elettrici, interruzioni delle telecomunicazioni e danni fisici alle strutture. La sicurezza digitale, in sostanza, deve occuparsi anche di ciò che accade fuori dai computer.
Per le imprese significa verificare aspetti molto pratici:
- Per quante ore una sede può funzionare senza corrente?
- Le connessioni acquistate da operatori diversi percorrono davvero strade separate?
- In quale luogo fisico vengono conservati i dati?
- Il trasferimento su una regione cloud alternativa è già stato provato?
- Esistono servizi secondari che continuano comunque a dipendere dal nodo principale?
Le stesse domande riguardano la Pubblica amministrazione. Sanità, protezione civile, pagamenti e identità digitale devono restare raggiungibili anche quando una parte della rete cade. Mantenere acceso il sistema centrale serve a poco se cittadini e operatori non dispongono più di un collegamento per utilizzarlo.
Il rapporto Cloudflare, nonostante non indichi una soluzione universale, mostra dove cercare le vulnerabilità: nell’alimentazione elettrica, nei percorsi dei cavi, nelle procedure tecniche, nella distribuzione dei servizi e nelle scelte dei governi.
Link e fonti
Rapporti tecnici, dati di monitoraggio e documenti ufficiali utilizzati per verificare le interruzioni della connettività e il quadro normativo sulla resilienza digitale.
-
Rapporto principale
Natural disasters and government interference: gli incidenti Internet del secondo trimestre 2026
Il rapporto ricostruisce le interruzioni provocate da tifoni, terremoti, blackout, shutdown governativi, guasti DNSSEC e tagli ai collegamenti in fibra.
Consulta il rapporto -
Analisi della connettività
Il ritorno parziale dell’Iran sulla rete Internet globale
L’analisi esamina i primi segnali di ripristino del traffico iraniano dopo 88 giorni di isolamento e chiarisce perché la riapertura sia rimasta soltanto parziale.
Consulta l’analisi -
Rapporto tecnico
Rapporto finale sul guasto DNS del dominio tedesco .de
La ricostruzione tecnica spiega come un errore nel cambio delle chiavi DNSSEC abbia limitato per circa tre ore la raggiungibilità dei domini con estensione .de.
Consulta il rapporto tecnico -
Banca dati sismologica
Terremoti significativi registrati nel 2026
Il catalogo USGS riporta i terremoti di magnitudo 7,2 e 7,5 registrati nel Venezuela settentrionale il 24 giugno 2026, utilizzati per correggere e verificare i dati sismici.
Consulta il catalogo -
Normativa italiana
Decreto legislativo n. 138 del 2024 sulla direttiva NIS2
Il decreto recepisce in Italia la direttiva NIS2 e disciplina gli obblighi di gestione del rischio e di sicurezza per infrastrutture, servizi digitali e soggetti essenziali.
Consulta il decreto -
Direttiva europea
Direttiva UE 2022/2555 sulla sicurezza delle reti e dei sistemi
La direttiva NIS2 stabilisce un livello comune elevato di cibersicurezza nell’Unione europea e introduce misure per prevenire, gestire e comunicare gli incidenti rilevanti.
Consulta la direttiva
