Down Cloudflare: le reali motivazioni del malfunzionamento del 18 Novembre 2025

Il 18 novembre 2025 resterà nella memoria di molti utenti e amministratori di rete come il giorno in cui Cloudflare, uno dei principali provider di servizi di rete e sicurezza Internet a livello globale, ha lamentato un malfunzionamento di vasta scala. L’interruzione ha interessato servizi critici e popolari, tra cui X (ex Twitter), ChatGPT, Canva e persino Downdetector, ironicamente colpito nel momento stesso in cui raccoglieva le segnalazioni degli utenti rispetto a Cloudflare e ad altri servizi.

Gli aggiornamenti ufficiali sulla dashboard Cloudflare System Status evidenziavano chiaramente che il problema non era circoscritto a singole rotte o regioni specifiche, ma interessava l’intera rete globale. I continui aggiornamenti indicavano un malfunzionamento radicato nell’infrastruttura centrale e non in problemi locali di connettività o routing, con impatti diffusi sui clienti e sulle applicazioni distribuite sulla rete globale di Cloudflare.

Alle ore 15,42 italiane Cloudflare ha comunicato di aver risolto il problema. “È stata implementata una correzione e riteniamo che l’incidente sia stato risolto. Continuiamo a monitorare eventuali errori per garantire che tutti i servizi tornino alla normalità“, si osserva dalla società.

La cronologia dell’incidente

La prima segnalazione ufficiale di Cloudflare è arrivata intorno alle 12:53 UTC, confermando che si stavano investigando problemi che causavano errori HTTP 500, rilevati anche sulla dashboard e lato API. Già dai primi minuti si è notata la gravità dell’evento.

L’errore più comune è Internal Server Error (500) che compare visitando tutti quei siti Web configurati per usare Cloudflare come Web proxy. La pagina esposta al browser mostra “You, Browser, working / Cloudflare error / Host working“.

Tuttavia, si stanno registrando problemi anche con i pagamenti elettronici. Le verifiche sulle carte di credito passano da secure7.arcot.com che, al momento del down di Cloudflare, risulta anch’esso affetto dal medesimo problema.

Il problema principale si manifestava, come detto, sotto forma di errori HTTP 500 a livello di server, segnale di malfunzionamenti interni nei nodi della rete globale di Cloudflare. Le possibili cause:

• Problemi di distribuzione a livello di rete: aggiornamenti o manutenzioni che impattano i server critici.
• Attacco DDoS mirato: Cloudflare ha recentemente respinto attacchi record da 11,5 Tbps, suggerendo la possibilità di un nuovo tentativo malevolo.
• Errore di configurazione interna: problemi nel propagare modifiche alle API o al DNS.

Un punto di interesse è il conseguente effetto domino: servizi che dipendono dall’infrastruttura Cloudflare hanno subito malfunzionamenti indiretti, evidenziando il rischio legato alla concentrazione di servizi critici su un unico provider.

L’errore “Sblocca challenges.cloudflare.com per continuare“

I Cloudflare Challenges sono dei meccanismi di verifica usati da Cloudflare. L’obiettivo principale è distinguere il traffico legittimo (umano) dal traffico potenzialmente dannoso o automatizzato (bot, scraper, attacchi DDoS). In pratica, quando si accede a un sito protetto da Cloudflare, il sistema può decidere di mostrare una “challenge”, ovvero una sfida che da superare per continuare: CAPTCHA, esecuzione automatica di codice JavaScript, controllo dell’integrità del browser.

Il down generalizzato di Cloudflare ha messo al tappeto anche i meccanismi alla base del sistema Challenges: il risultato è la comparsa, su molti siti, del messaggio “Sblocca challenges.cloudflare.com per continuare“.

Vale la pena osservare che esistono strumenti per scoprire l’indirizzo IP reale dei siti protetti tramite reverse proxy Cloudflare: in linea generale, recuperando tale IP e modificando il file HOSTS locale è possibile visitare i siti che risultassero temporaneamente irraggiungibili a valle di un down del Web proxy.

L’infrastruttura Cloudflare: un ecosistema complesso e fortemente interdipendente

Per comprendere la gravità del problema è necessario ricordare come Cloudflare gestisce il traffico dei suoi clienti. Ogni richiesta — HTTP, API, mobile app o servizio automatizzato — attraversa tre livelli fondamentali:

• Terminazione TLS/HTTP, che accoglie la connessione dell’utente.
• FL / FL2 (Frontline), il proxy interno che applica le politiche di sicurezza, routing e accelerazione.
• Pingora, il motore che decide se servire dalla cache o recuperare i contenuti dall’origine.

All’interno del proxy Frontline operano numerosi moduli: mitigazione DDoS, WAF, Access, Workers, filtraggio bot e molte altre funzioni. Una singola anomalia in uno di questi moduli può, se non correttamente isolata, compromettere l’intera catena. Ed è esattamente ciò che è accaduto.

L’innesco: un cambiamento nelle autorizzazioni del cluster ClickHouse

Come spiegato nell’analisi post-incidente, alle 11:05 UTC Cloudflare ha distribuito una modifica alle autorizzazioni di un cluster ClickHouse, parte del processo di revisione della sicurezza.

Un cluster ClickHouse è un insieme di più server che lavorano insieme per distribuire dati e carichi di lavoro. In pratica, serve a suddividere i dati su più nodi (shard) per gestire grandi volumi; replicare le informazioni per garantire alta disponibilità; eseguire query in parallelo, aumentando notevolmente le prestazioni; continuare a funzionare anche se un nodo si guasta, grazie alla ridondanza.

Il cambiamento apportato dai tecnici Cloudflare aveva uno scopo ben preciso: permettere ai processi di vedere esplicitamente le tabelle sottostanti e applicare controlli più granulari sui permessi.

Il sistema di Bot Management di Cloudflare genera, ogni pochi minuti, un feature file: un file che contiene tutte le “feature” (cioè i parametri) che il modello di machine learning usa per calcolare il punteggio bot. Per costruire questo file, il sistema esegue una query sui metadati delle colonne presenti in una specifica tabella ClickHouse.

Quando Cloudflare ha reso visibili anche le tabelle interne, la query ha restituito il doppio delle colonne. Non era previsto e non era un’operazione gestita. Ciò ha causato un file il doppio più grande, che il sistema non era in grado di caricare.

Il file delle feature Bot Management: un punto di fallimento centrale

Il modulo Bot Management si basa su un file contenente tutte le feature utilizzate dal modello di machine learning per identificare traffico automatizzato e bot malevoli.

Il file è rigenerato ogni cinque minuti mediante una query ClickHouse; viene propagato globalmente a tutti i nodi; deve rispettare limiti dimensionali precisi per permettere un caricamento rapido e prevedibile.

La duplicazione dei metadati ha prodotto un file il cui numero di feature ha superato il limite rigido imposto dal modulo. In FL2 (vedere i paragrafi precedenti), implementato in Rust, la condizione anomala ha generato un errore “panic” non gestito, provocando la restituzione di codici HTTP 5xx ai client.

Nei nodi ancora basati su FL (vecchio proxy), il modulo non è crashato, ma ha assegnato a tutto il traffico una bot score pari a zero, con effetti collaterali sui sistemi che applicano regole basate su quel punteggio.

La natura intermittente dell’errore: un fattore aggravante

Poiché la modifica ai permessi veniva distribuita progressivamente nel cluster, per alcuni minuti la query era eseguita correttamente su nodi non aggiornati, erroneamente su quelli già aggiornati.

Il risultato è stato un comportamento oscillante, con finestre di apparente recupero seguite da nuovi fallimenti. Questo comportamento ha inizialmente fatto sospettare un attacco DDoS mirato, anche perché — coincidenza sfortunata — la pagina di stato esterna di Cloudflare ha subìto un malfunzionamento non correlato.

La diagnosi si è quindi concentrata su ipotesi sbagliate prima che venisse individuata la causa reale.

Il malfunzionamento del core proxy ha avuto impatti eterogenei su un ampio ventaglio di servizi Cloudflare, mostrando come un singolo file propagato globalmente potesse compromettere funzionalità di alto livello.

Lezioni a lungo termine: sicurezza, resilienza e validazione dei file interni

Cloudflare ha annunciato diverse misure correttive, che possono essere lette come un’evoluzione della cultura DevOps aziendale:

• Hardening dei file generati internamente. Trattare file e configurazioni interne come se fossero input potenzialmente malevoli.
• Kill-switch globali più granulari. Possibilità di disattivare rapidamente moduli specifici in caso di comportamenti anomali.
• Limitazione dell’impatto dei core dump. Durante l’incidente, i sistemi di debug hanno consumato CPU in modo eccessivo, peggiorando la latenza.
• Riesame della modalità failure del proxy FL/FL2. Garantire che errori di parsing non provochino interruzioni totali dei servizi.

Sono misure che rafforzano non solo l’affidabilità del servizio, ma anche la postura complessiva dell’Internet globale.