Cloudflare headers begrijpen: cf-cache-status, cf-ray en meer eenvoudig uitgelegd

Je hebt je WordPress website achter Cloudflare gezet en wilt weten of het CDN eigenlijk wel iets doet. In de antwoorden van je server duiken ineens regels op als cf-cache-status: DYNAMIC of cf-ray: 8f2a1c3d4e5f6a7b-FRA. Die headers zijn een soort bijsluiter van Cloudflare: ze laten zien of een bestand uit de cache kwam, welk datacenter heeft geantwoord en of er een beveiligingsregel tussenbeide is gekomen. Hier lees je wat de afzonderlijke waarden betekenen en wat je daaruit voor je website kunt afleiden.

Wat zijn Cloudflare headers en hoe lees je ze uit?

Cloudflare zit als proxy tussen je bezoekers en je server. Elk verzoek gaat door het netwerk van Cloudflare, en onderweg komen er headers bij. Sommige daarvan ziet de browser van je bezoekers, andere komen alleen bij je server terecht. Hoe zo'n netwerk in grote lijnen werkt, lees je in ons artikel Wat is een CDN?.

Het snelst zie je de headers in de ontwikkelaarstools van je browser. Open het tabblad “Netwerk”, laad de pagina opnieuw en klik op de eerste regel. Nog sneller gaat het in de terminal:

curl -sI https://example.com/

Het antwoord ziet er dan ongeveer zo uit:

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

Ontbreken alle regels met cf-, dan loopt het verzoek helemaal niet via Cloudflare. Meestal staat het record in je DNS dan op “DNS only” (grijze wolk) in plaats van op “Proxied” (oranje wolk).

Wat betekent cf-cache-status? Alle waarden op een rij

De header cf-cache-status is de belangrijkste van allemaal. Hij vertelt je hoe Cloudflare met precies dit antwoord is omgegaan. De officiële documentatie kent negen waarden:

• HIT: Het bestand stond in de cache en kwam rechtstreeks van Cloudflare. Je server heeft er niets van gemerkt. Dit is de waarde die je wilt zien.
• MISS: Het bestand mag in de cache, maar was in dit datacenter nog niet aanwezig. Cloudflare heeft het bij je server opgehaald. Vraag je het opnieuw op, dan hoort er HIT te staan.
• EXPIRED: Het bestand stond in de cache, maar was verlopen. Cloudflare heeft een verse versie bij je server opgehaald.
• REVALIDATED: De kopie in de cache was verlopen. Cloudflare heeft bij je server nagevraagd of er iets was veranderd, en het antwoord was nee. Het bestand kwam dus uit de cache, maar de bezoeker moest wel op die controle wachten.
• UPDATING: De kopie was verlopen en werd toch meteen uitgeleverd, terwijl Cloudflare op de achtergrond een nieuwe versie ophaalt. Dat gebeurt wanneer je server stale-while-revalidate meestuurt.
• STALE: Cloudflare heeft een verlopen kopie uitgeleverd, omdat je server niet bereikbaar was. Een waarschuwingssignaal dat je serieus moet nemen.
• BYPASS: Het bestand kwam in principe in aanmerking voor de cache, maar het antwoord van je server heeft dat verhinderd, bijvoorbeeld door een cookie.
• DYNAMIC: Cloudflare heeft niet eens in de cache gekeken, omdat deze inhoud volgens de geldende regels niet wordt gecachet.
• NONE/UNKNOWN: Cloudflare heeft het antwoord zelf gemaakt, bijvoorbeeld bij een doorverwijzing naar HTTPS, een blokkade door de firewall of een Worker.

Goed om te weten: sinds 26 mei 2026 maakt Cloudflare een duidelijker onderscheid tussen twee van deze waarden. Vroeger kregen sommige antwoorden die niet in de cache konden, bij elk verzoek een MISS. Sinds de aanpassing staat daar altijd BYPASS. MISS betekent nu alleen nog: mag in de cache, maar is er op dit moment niet. Veel oudere handleidingen op internet beschrijven nog het oude gedrag.

Waarom toont je WordPress website cf-cache-status: DYNAMIC?

Dat is de meest gestelde vraag over dit onderwerp, en het antwoord stelt gerust: bij een gewone pagina van WordPress is DYNAMIC heel normaal. Cloudflare slaat in de standaardinstelling geen HTML en geen JSON op in de cache. De beslissing valt op basis van de bestandsextensie, niet op basis van de inhoud. Afbeeldingen, CSS, JavaScript, lettertypen en pdf's komen in de cache terecht, de HTML van je pagina's niet.

Daar is een goede reden voor. WordPress maakt pagina's dynamisch aan, en Cloudflare kan niet weten of er in de HTML op dat moment een winkelwagen, een adminbalk of een persoonlijke begroeting zit. Zou Cloudflare zulke pagina's ongevraagd in de cache zetten, dan zag in het ergste geval de ene bezoeker de winkelwagen van een ander.

Je afbeeldingen en scripts horen daarentegen HIT te melden. Controleer daarom niet alleen de homepage, maar ook een stylesheet of een afbeelding.

Wil je ook de HTML door Cloudflare laten uitleveren, dan heb je twee mogelijkheden:

• Cache Rule: Je maakt in het dashboard een regel aan die HTML als “Eligible for cache” markeert. Dan moet je er zelf voor zorgen dat ingelogde gebruikers, het beheergedeelte, de winkelwagen en de afrekenpagina uitgesloten blijven.
• APO voor WordPress: Automatic Platform Optimization regelt die uitzonderingen voor je en leegt de cache zodra je een bericht wijzigt. Daarover verderop meer.

Staat er ook bij afbeeldingen of CSS DYNAMIC, dan ligt dat meestal aan een regel met “Bypass cache” of aan de Development Mode. Die schakelt de cache drie uur lang volledig uit en wordt vaak vergeten.

Waarom staat cf-cache-status op BYPASS of steeds op MISS?

Bij BYPASS wilde Cloudflare wel cachen, maar het antwoord van je server stond het niet toe. De handleiding voor probleemoplossing noemt vooral deze oorzaken:

• Het antwoord bevat de header Set-Cookie. Bij WordPress is dat de klassieker: een webshop, een plugin voor meertaligheid of een trackingplugin zet bij elk verzoek een cookie, en meteen wordt er niets meer gecachet.
• Je server stuurt Cache-Control: no-store of private.
• Het antwoord bevat Vary: *.
• Het bestand is groter dan de limiet van je abonnement (512 MB bij Free, Pro en Business).

Blijft het bij elk verzoek bij MISS, dan mag het bestand wel in de cache, maar Cloudflare vindt het nooit terug. Daar zitten vaak wisselende parameters in het adres achter, zoals utm_source of een ID voor de sessie, want elke variant telt als een apart bestand. Op websites met weinig bezoekers verdwijnen bestanden die zelden worden opgevraagd bovendien eerder uit de cache. En elk datacenter heeft zijn eigen cache: komen twee verzoeken op verschillende locaties binnen, dan zie je twee keer MISS.

Een handig hulpmiddel is de header Age. Die geeft in seconden aan hoe lang de kopie al in de cache staat. Vraag je een bestand twee keer achter elkaar op en zie je HIT met een stijgende Age, dan werkt alles.

Wat verraadt de header cf-ray?

Elk verzoek dat via Cloudflare loopt, krijgt een eigen kenmerk, de Ray ID. Die staat in de header cf-ray en bestaat uit twee delen: een reeks tekens en een afkorting van drie letters. De afkorting geeft het datacenter aan dat heeft geantwoord. FRA staat voor Frankfurt, AMS voor Amsterdam, CDG voor Parijs.

In de praktijk helpt de Ray ID je op drie punten. Laat Cloudflare een bezoeker een foutpagina zien, dan staat de Ray ID onderaan die pagina, en daarmee vind je precies dat verzoek terug in de logs of de Security Events. Ten tweede zie je aan de afkorting of je bezoekers echt bij een locatie in de buurt uitkomen. En ten derde verklaart het menige raadselachtige MISS, wanneer twee verzoeken in verschillende datacenters zijn aangekomen.

Dezelfde Ray ID stuurt Cloudflare trouwens ook naar je server. Schrijf je hem daar in de log, dan kun je een verzoek volgen van de browser tot aan PHP.

cf-apo-via en cf-edge-cache: werkt APO voor WordPress?

Gebruik je Automatic Platform Optimization, dan komen er nog twee headers bij. Volgens Cloudflare herken je een werkende configuratie aan drie regels:

• cf-cache-status: HIT laat zien dat de HTML uit de cache kwam.
• cf-apo-via: tcache laat zien dat APO het verzoek heeft afgehandeld.
• cf-edge-cache: cache,platform=wordpress bevestigt dat de Cloudflare plugin in WordPress is geïnstalleerd en actief is.

Ontbreekt cf-edge-cache, dan is de plugin meestal gedeactiveerd of niet met je account verbonden. Staat bij cf-apo-via een andere waarde dan tcache, dan heeft APO de pagina niet uit de cache geleverd, bijvoorbeeld omdat je bent ingelogd. Test daarom altijd in een privévenster.

Wat betekent cf-mitigated: challenge?

Deze header verschijnt alleen als Cloudflare in plaats van je pagina een controlepagina uitlevert, dus de bekende melding dat de bezoeker even wordt geverifieerd. challenge is de enige geldige waarde.

Voor mensen is dat meestal alleen een korte vertraging. Voor alles wat automatisch je website benadert, is het een echt obstakel. De controlepagina is altijd HTML, ook als er eigenlijk JSON werd opgevraagd. Roept je eigen JavaScript de REST API aan en krijgt het ineens een controlepagina terug, dan loopt het tegen een fout aan die je zonder deze header nauwelijks zou kunnen plaatsen. Hetzelfde geldt voor monitoringdiensten, betaalproviders met webhooks en analysetools. Zie je cf-mitigated: challenge bij verzoeken die gewoon door zouden moeten komen, kijk dan in het dashboard bij de Security Events. Daar staat welke regel heeft ingegrepen.

Welke Cloudflare headers komen bij je server aan?

Niet alle headers zijn voor de browser bedoeld. Sommige voegt Cloudflare aan het verzoek toe voordat het je server bereikt. De volledige lijst is lang, voor WordPress zijn vooral deze belangrijk:

• CF-Connecting-IP: het echte IP van de bezoeker. Zonder deze header ziet je server alleen adressen van Cloudflare.
• X-Forwarded-For: de keten van alle proxy's waar het verzoek doorheen is gegaan. Cloudflare raadt aan om voor het adres van de bezoeker liever CF-Connecting-IP uit te lezen.
• X-Forwarded-Proto en CF-Visitor: laten zien of de bezoeker via HTTP of HTTPS is gekomen.
• CF-IPCountry: het land van de bezoeker als code van twee letters. XX betekent onbekend, T1 staat voor verkeer via Tor.
• CDN-Loop: voorkomt dat een verzoek eindeloos in een kringetje door Cloudflare blijft lopen.

Het echte IP is meer dan een detail. Beveiligingsplugins blokkeren aanvallers op basis van hun IP, WordPress slaat het op bij reacties en je hostingprovider gebruikt het in de logs. Komt daar alleen het adres van Cloudflare aan, dan sluit je plugin voor je het weet alle bezoekers tegelijk buiten. De meeste hostingproviders en beveiligingsplugins kun je hierop instellen. Belangrijk daarbij: vertrouw de header alleen als het verzoek echt van een adres uit het netwerk van Cloudflare komt. Anders kan iedereen een willekeurig IP in de header zetten.

Ook een bekende foutbron hangt hiermee samen. Staat SSL in Cloudflare op “Flexible”, dan praat Cloudflare onversleuteld met je server. WordPress denkt dan dat de bezoeker via HTTP is gekomen, stuurt door naar HTTPS, en er ontstaat een oneindige lus. De nette oplossing is een certificaat op de server en de instelling “Full (strict)”.

Hoe bepaal je met Cache-Control wat Cloudflare in de cache zet?

Hoe lang Cloudflare een bestand bewaart, bepaalt in de eerste plaats je server. Daarvoor zijn er drie headers, die Cloudflare in deze volgorde evalueert:

1. Cloudflare-CDN-Cache-Control geldt alleen voor Cloudflare en wordt niet aan de browser doorgegeven.
2. CDN-Cache-Control geldt voor alle CDN's onderweg.
3. Cache-Control geldt voor browsers en, als de andere twee ontbreken, ook voor Cloudflare.

Zo kun je browser en CDN apart aansturen. Een voorbeeld: de browser mag een bestand maar een uur bewaren, Cloudflare een hele dag.

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

Stuurt je server helemaal geen instructies mee, dan gelden de standaardwaarden. Antwoorden met status 200 en 301 blijven 120 minuten in de cache, doorverwijzingen met 302 en 303 maar 20 minuten, fouten met 404 en 410 drie minuten. Dat laatste verrast veel mensen: upload je een ontbrekende afbeelding alsnog, dan kan Cloudflare nog een paar minuten de oude foutmelding uitleveren.

Welke andere headers voegt Cloudflare toe?

Naast de bekende regels vallen je misschien nog een paar andere op:

• server: cloudflare vervangt de vermelding van je webserver. Of daarachter Apache, nginx of LiteSpeed draait, ziet van buitenaf niemand meer.
• report-to en nel horen bij Network Error Logging. Daarmee meldt de browser verbindingsfouten aan Cloudflare. De functie kun je in het dashboard uitschakelen, wat met het oog op privacy voor sommige websites interessant is.
• alt-svc laat de browser weten dat de website ook via HTTP/3 bereikbaar is. Stuurt je server zelf een header alt-svc mee, dan haalt Cloudflare die weg.

Een paar headers van je server komen trouwens nooit bij de bezoeker aan. Daartoe horen Cache-Tag en de headers van nginx die met X-Accel beginnen. Kijk dus niet vreemd op als je er in de browser tevergeefs naar zoekt.

Hoe controleer je Cloudflare headers met InspectWP?

InspectWP leest bij het maken van een rapport de headers van je website uit en toont je in het onderdeel “Kopteksten” onder meer cf-cache-status en cf-ray. Je ziet dus zonder terminal of je website via Cloudflare loopt en hoe de homepage is uitgeleverd. Daarnaast krijg je de waarden die met caching samenhangen: de compressie, de versie van HTTP en de beveiligingsheaders.

Vooral als je meerdere websites beheert, is dat handig. Met automatische rapporten merk je het op wanneer een pagina ineens niet meer uit de cache komt of wanneer Cloudflare na een verhuizing helemaal niet meer voor de website staat. Blokkeert een controlepagina van Cloudflare de crawl, dan wijst InspectWP je daarop. In ons hulpartikel Wat te doen wanneer de crawl mislukt lees je hoe je de botbescherming daarvoor goed instelt. Een gratis rapport laat je binnen korte tijd zien welke headers je website op dit moment verstuurt.