Header di Cloudflare spiegati in modo semplice: cf-cache-status, cf-ray e gli altri

Hai messo il tuo sito WordPress dietro Cloudflare e vuoi sapere se la CDN sta facendo davvero qualcosa. All'improvviso, nelle risposte del tuo server compaiono righe come cf-cache-status: DYNAMIC o cf-ray: 8f2a1c3d4e5f6a7b-FRA. Questi header sono un po' il bugiardino di Cloudflare: ti dicono se un file è arrivato dalla cache, quale data center ha risposto e se è intervenuta una regola di sicurezza. Qui scopri cosa significano i singoli valori e cosa puoi dedurne per il tuo sito.

Cosa sono gli header di Cloudflare e come puoi leggerli?

Cloudflare si trova come proxy tra i tuoi visitatori e il tuo server. Ogni richiesta passa attraverso la rete di Cloudflare, e lungo il percorso si aggiungono degli header. Alcuni li vede il browser dei tuoi visitatori, altri arrivano solo al tuo server. Come funziona in generale una rete di questo tipo lo spiega il nostro articolo Cos'è una CDN?.

Gli header li vedi in un attimo negli strumenti per sviluppatori del tuo browser. Apri la scheda “Rete”, ricarica la pagina e fai clic sulla prima riga. Dal terminale fai ancora prima:

curl -sI https://example.com/

La risposta sarà più o meno così:

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=0
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 8f2a1c3d4e5f6a7b-FRA

Se mancano tutte le righe con cf-, la richiesta non passa affatto da Cloudflare. Di solito il record DNS è impostato su “DNS only” (nuvola grigia) invece che su “Proxied” (nuvola arancione).

Cosa significa cf-cache-status? Tutti i valori in sintesi

L'header cf-cache-status è il più importante di tutti. Ti dice come Cloudflare ha gestito proprio questa risposta. La documentazione ufficiale prevede nove valori:

• HIT: il file era nella cache ed è arrivato direttamente da Cloudflare. Il tuo server non se n'è nemmeno accorto. È il valore che vuoi vedere.
• MISS: il file può essere messo in cache, ma in questo data center non c'era ancora. Cloudflare lo ha preso dal tuo server. Alla richiesta successiva dovresti vedere HIT.
• EXPIRED: il file era nella cache, ma era scaduto. Cloudflare ne ha preso una copia aggiornata dal tuo server.
• REVALIDATED: la copia nella cache era scaduta. Cloudflare ha chiesto al tuo server se nel frattempo fosse cambiato qualcosa, e la risposta è stata no. Il file è quindi arrivato dalla cache, ma il visitatore ha dovuto aspettare questa verifica.
• UPDATING: la copia era scaduta, ma è stata consegnata subito lo stesso, mentre Cloudflare la rinnova in background. Succede quando il tuo server invia stale-while-revalidate.
• STALE: Cloudflare ha consegnato una copia scaduta perché il tuo server non era raggiungibile. Un segnale d'allarme da prendere sul serio.
• BYPASS: in linea di principio il file sarebbe stato un candidato per la cache, ma la risposta del tuo server lo ha impedito, per esempio con un cookie.
• DYNAMIC: Cloudflare non ha nemmeno guardato nella cache, perché in base alle regole in vigore questo contenuto non viene messo in cache.
• NONE/UNKNOWN: Cloudflare ha generato la risposta da sé, per esempio con un reindirizzamento a HTTPS, un blocco del firewall o un Worker.

Buono a sapersi: dal 26 maggio 2026 Cloudflare distingue due di questi valori in modo più netto. Prima, alcune risposte che non potevano essere messe in cache ricevevano un MISS a ogni richiesta. Dopo la modifica lì compare sempre BYPASS. Ora MISS significa soltanto: memorizzabile in cache, ma al momento non disponibile. Molte guide più vecchie che trovi in rete descrivono ancora il comportamento precedente.

Perché il tuo sito WordPress mostra cf-cache-status: DYNAMIC?

È la domanda più frequente su questo tema, e la risposta è rassicurante: per una normale pagina WordPress, DYNAMIC è la norma. Con le impostazioni predefinite Cloudflare non mette in cache né HTML né JSON. La decisione dipende dall'estensione del file, non dal contenuto. Immagini, CSS, JavaScript, font e PDF finiscono nella cache, l'HTML delle tue pagine no.

C'è un buon motivo. WordPress genera le pagine in modo dinamico, e Cloudflare non può sapere se nell'HTML c'è un carrello, una barra di amministrazione o un saluto personale. Se mettesse in cache queste pagine senza che nessuno glielo chieda, nel peggiore dei casi un visitatore vedrebbe il carrello di un altro.

Le tue immagini e i tuoi script, invece, dovrebbero riportare HIT. Per questo non controllare solo la homepage, ma anche un file CSS o un'immagine.

Se vuoi che Cloudflare consegni anche l'HTML, hai due strade:

• Cache Rule: crei nella dashboard una regola che contrassegna l'HTML come “Eligible for cache”. A quel punto tocca a te fare in modo che restino esclusi gli utenti che hanno effettuato l'accesso, l'area di amministrazione, il carrello e la pagina di pagamento.
• APO per WordPress: l'Automatic Platform Optimization gestisce queste eccezioni al posto tuo e svuota la cache non appena modifichi un articolo. Ne parliamo più avanti.

Se DYNAMIC compare anche su immagini o CSS, di solito la causa è una regola con “Bypass cache” oppure il Development Mode. Quest'ultimo disattiva completamente la cache per tre ore e capita spesso di dimenticarlo acceso.

cf-cache-status BYPASS o sempre MISS: da cosa dipende?

Con BYPASS Cloudflare voleva mettere in cache, ma la risposta del tuo server non lo ha permesso. La guida alla risoluzione dei problemi indica soprattutto queste cause:

• La risposta contiene un header Set-Cookie. Con WordPress è il caso classico: uno shop, un plugin multilingua o un plugin di tracciamento imposta un cookie a ogni richiesta, e da quel momento non viene più messo in cache nulla.
• Il tuo server invia Cache-Control: no-store o private.
• La risposta contiene Vary: *.
• Il file supera il limite del tuo piano (512 MB per Free, Pro e Business).

Se a ogni richiesta resta MISS, il file è sì memorizzabile in cache, ma Cloudflare non lo ritrova mai. Spesso dietro ci sono parametri variabili nell'indirizzo, come utm_source o un ID di sessione, perché ogni variante conta come un file a sé. Sui siti con pochi visitatori, inoltre, i file richiesti di rado escono prima dalla cache. E ogni data center ha la propria cache: se due richieste arrivano in sedi diverse, vedi due volte MISS.

Un buon aiuto è l'header Age. Indica in secondi da quanto tempo la copia si trova nella cache. Se richiedi un file due volte di seguito e vedi HIT con un valore di Age che cresce, tutto funziona.

Cosa rivela l'header cf-ray?

Ogni richiesta che passa attraverso Cloudflare riceve un proprio identificativo, il Ray ID. Si trova nell'header cf-ray ed è composto da due parti: una stringa di caratteri e un codice di tre lettere. Il codice indica il data center che ha risposto. FRA sta per Francoforte, AMS per Amsterdam, CDG per Parigi.

Nel lavoro di tutti i giorni il Ray ID ti aiuta in tre situazioni. Quando Cloudflare mostra a un visitatore una pagina di errore, il Ray ID è riportato in fondo alla pagina, e con quello ritrovi proprio quella richiesta nei log o nei Security Events. In secondo luogo, dal codice capisci se i tuoi visitatori arrivano davvero a una sede vicina. E in terzo luogo spiega più di un MISS misterioso, quando due richieste sono arrivate in data center diversi.

Tra l'altro, Cloudflare invia lo stesso Ray ID anche al tuo server. Se lo scrivi lì nel log, puoi seguire una richiesta dal browser fino a PHP.

cf-apo-via e cf-edge-cache: APO per WordPress funziona?

Se usi l'Automatic Platform Optimization, si aggiungono altri due header. Secondo Cloudflare riconosci una configurazione funzionante da tre righe:

• cf-cache-status: HIT indica che l'HTML è arrivato dalla cache.
• cf-apo-via: tcache indica che è stato APO a servire la richiesta.
• cf-edge-cache: cache,platform=wordpress conferma che il plugin Cloudflare è installato e attivo in WordPress.

Se manca cf-edge-cache, di solito il plugin è disattivato o non è collegato al tuo account. Se cf-apo-via riporta un valore diverso da tcache, APO non ha consegnato la pagina dalla cache, per esempio perché hai effettuato l'accesso. Per questo fai sempre le prove in una finestra privata.

Cosa significa cf-mitigated: challenge?

Questo header compare solo quando Cloudflare, al posto della tua pagina, consegna una pagina di verifica, cioè il noto avviso in cui si legge che il visitatore viene controllato per qualche istante. challenge è l'unico valore valido.

Per le persone di solito è solo un breve ritardo. Per tutto ciò che accede al tuo sito in modo automatico è invece un vero ostacolo. La pagina di verifica è sempre HTML, anche quando in realtà era stato richiesto JSON. Se il tuo JavaScript chiama la REST API e all'improvviso riceve una pagina di verifica, va incontro a un errore che senza questo header difficilmente sapresti inquadrare. Lo stesso vale per i servizi di monitoraggio, i provider di pagamento con webhook e gli strumenti di analisi. Se vedi cf-mitigated: challenge su accessi che dovrebbero passare, vale la pena dare un'occhiata ai Security Events nella dashboard. Lì trovi quale regola è scattata.

Quali header di Cloudflare arrivano al tuo server?

Non tutti gli header sono pensati per il browser. Alcuni vengono aggiunti da Cloudflare alla richiesta prima che questa raggiunga il tuo server. L'elenco completo è lungo, ma per WordPress contano soprattutto questi:

• CF-Connecting-IP: il vero indirizzo IP del visitatore. Senza questo header il tuo server vede solo indirizzi di Cloudflare.
• X-Forwarded-For: la catena di tutti i proxy attraverso cui è passata la richiesta. Per l'indirizzo del visitatore Cloudflare consiglia di leggere piuttosto CF-Connecting-IP.
• X-Forwarded-Proto e CF-Visitor: indicano se il visitatore è arrivato tramite HTTP o HTTPS.
• CF-IPCountry: il paese del visitatore come codice di due lettere. XX significa sconosciuto, T1 sta per la rete Tor.
• CDN-Loop: impedisce che una richiesta giri all'infinito attraverso Cloudflare.

Il vero indirizzo IP è più di un dettaglio. I plugin di sicurezza bloccano gli aggressori in base all'indirizzo IP, WordPress lo salva insieme ai commenti e il tuo provider di hosting lo analizza nei log. Se lì arriva solo l'indirizzo di Cloudflare, il tuo plugin rischia di bloccare tutti i visitatori in un colpo solo. La maggior parte dei provider di hosting e dei plugin di sicurezza si può configurare per questo caso. Una cosa importante: fidati dell'header solo se la richiesta proviene davvero da un indirizzo della rete di Cloudflare. Altrimenti chiunque può scrivere nell'header un indirizzo IP a piacere.

A questo è legata anche una causa di errori molto nota. Con l'impostazione SSL “Flexible”, Cloudflare comunica con il tuo server senza crittografia. WordPress crede allora che il visitatore sia arrivato tramite HTTP, reindirizza a HTTPS e si crea un ciclo infinito. La soluzione corretta è un certificato sul server e l'impostazione “Full (strict)”.

Come stabilisci con Cache-Control cosa mette in cache Cloudflare?

Per quanto tempo Cloudflare conserva un file lo decide prima di tutto il tuo server. Per farlo esistono tre header, che Cloudflare valuta in questo ordine:

1. Cloudflare-CDN-Cache-Control vale solo per Cloudflare e non viene inoltrato al browser.
2. CDN-Cache-Control vale per tutte le CDN lungo il percorso.
3. Cache-Control vale per i browser e, se mancano gli altri due, anche per Cloudflare.

Così puoi gestire browser e CDN separatamente. Un esempio: il browser deve conservare un file solo per un'ora, Cloudflare invece per un giorno intero.

Cache-Control: max-age=3600
Cloudflare-CDN-Cache-Control: max-age=86400

Se il tuo server non invia alcuna indicazione, valgono i valori predefiniti. Le risposte con stato 200 e 301 restano nella cache per 120 minuti, i reindirizzamenti con 302 e 303 solo per 20 minuti, gli errori con 404 e 410 per tre minuti. L'ultimo punto sorprende molti: se carichi in un secondo momento un'immagine che mancava, Cloudflare può continuare a consegnare il vecchio messaggio di errore ancora per qualche minuto.

Quali altri header imposta Cloudflare?

Oltre alle righe già viste, potresti notarne alcune altre:

• server: cloudflare sostituisce l'indicazione del tuo server web. Se dietro gira Apache, nginx o LiteSpeed, dall'esterno non lo vede più nessuno.
• report-to e nel fanno parte di Network Error Logging. Attraverso questi header il browser segnala a Cloudflare gli errori di connessione. La funzione si può disattivare nella dashboard, cosa interessante per alcuni siti dal punto di vista della privacy.
• alt-svc comunica al browser che il sito è raggiungibile anche tramite HTTP/3. Cloudflare rimuove un eventuale header alt-svc impostato dal tuo server.

Alcuni header del tuo server, tra l'altro, non arrivano mai al visitatore. Tra questi ci sono Cache-Tag e gli header X-Accel di nginx. Quindi non stupirti se nel browser li cerchi invano.

Come controlli gli header di Cloudflare con InspectWP?

InspectWP legge gli header del tuo sito durante la creazione di un report e, nella sezione Header, ti mostra tra gli altri cf-cache-status e cf-ray. Così vedi senza terminale se il tuo sito passa da Cloudflare e come è stata consegnata la homepage. A questi si aggiungono i valori legati al caching: la compressione, la versione HTTP e gli header di sicurezza.

Tutto questo è utile soprattutto se gestisci più siti. Con i report automatici ti accorgi quando una pagina all'improvviso non arriva più dalla cache o quando, dopo una migrazione, Cloudflare non è più davanti al sito. Se una pagina di verifica di Cloudflare blocca il crawl, InspectWP te lo segnala. Nel nostro articolo di aiuto Cosa fare quando il crawl fallisce trovi come impostare in modo adeguato la protezione dai bot. Un report gratuito ti mostra in poco tempo quali header sta inviando il tuo sito in questo momento.