Quando Cloudflare va giù, non è semplicemente “un servizio” a non funzionare: è un pezzo significativo dell’infrastruttura di Internet a smettere di rispondere. Nella mattinata del 5 dicembre 2025, milioni di utenti in tutto il mondo hanno iniziato a vedere un’unica schermata bianca con un messaggio impietoso: 500 Internal Server Error – Cloudflare.
Non si tratta di un semplice degrado, né di un problema isolato: i disservizi hanno coinvolto una porzione critica della rete di distribuzione globale di Cloudflare, con ripercussioni dirette su piattaforme come LinkedIn, Medium, Notion, Shopify, NPM, Claude, Perplexity, oltre a migliaia di siti aziendali e consumer.
L’evento è reso ancora più evidente dal fatto che persino cloudflare.com e cloudflarestatus.com hanno risposto con errori 500, impedendo agli utenti di recuperare informazioni ufficiali sul problema occorso.
(Aggiornamento): l’azienda ha comunicato di aver applicato un intervento risolutivo ed è iniziata la fase di monitoraggio post-incidente.
Un blackout Cloudflare con caratteristiche anomale
Il nuovo down di Cloudflare, che si verifica a pochi giorni di distanza dal grave episodio del 18 novembre 2025, si è manifestato con un comportamento insolito:
- Errori 500 “puri”, non le tipiche pagine Cloudflare personalizzate.
- Dashboard e API irraggiungibili, rendendo impossibile intervenire rapidamente sulle configurazioni.
- Status page non aggiornata nella fase iniziale, probabilmente per indisponibilità interna.
- Molti siti piccoli ancora online, mentre le piattaforme ad alto traffico cadevano una dopo l’altra.
Questi indizi suggeriscono un problema a livello di reverse proxy e dei servizi core, non necessariamente legato ai prodotti serverless (Workers, KV, R2), che in molti casi sono rimasti operativi.
Il ruolo del datacenter di Chicago (ORD)
Cloudflare aveva programmato una finestra di manutenzione nel datacenter ORD (Chicago), con una comunicazione formale di un possibile aumento della latenza nella regione.
L’operazione avrebbe dovuto prevedere un failover trasparente; in realtà si è ingenerato un “guasto” molto più ampio, propagatosi ben oltre il perimetro regionale e, di conseguenza, diversi sistemi non sono riusciti a reindirizzare correttamente il traffico.
L’ipotesi più accreditata, in attesa di una presa di posizione da parte di Cloudflare, è che una modifica errata sulla configurazione del datacenter di Chicago (forse non propagata correttamente) ha avuto un impatto su tutti i proxy edge globali. Sarebbe la stessa tipologia di errore che storicamente ha causato outage significativi per altri hyperscaler.
Dipendenze critiche: quando una CDN diventa un single point of failure
La caduta simultanea di interi ecosistemi (Shopify, NPM, LinkedIn,…) dimostra quanto il mercato abbia progressivamente trasformato Cloudflare in un single point of failure involontario.
Aziende di ogni dimensione hanno investito su una gestione centralizzata nelle mani di Cloudflare: DNS autoritativo, CDN, Reverse proxy, WAF e mitigazione DDoS, Edge compute (Workers, Durable Objects, Pages), Tunneling e Zero Trust access.
La promessa era: “metti Cloudflare davanti a tutto e non avrai più downtime”. Ultimamente, due episodi di down globale a distanza di pochi giorni stanno gettando scompiglio a livello globale e portando a ripensare il modello architetturale prevalente.