Hvorfor viser CF-Cache-Status DYNAMIC, BYPASS eller MISS?

Kort svar: DYNAMIC betyder normalt, at requesten ikke var cache-egnet, før Cloudflare slog op i cachen. BYPASS betyder, at requesten kunne vurderes til cache, men en regel, cookie eller originens svar forhindrede lagring. MISS betyder, at ressourcen er cache-egnet, men ikke fandtes i det aktuelle edge-cachepunkt. Test samme URL flere gange med samme query, cookies og datacenter. En MISS efter purge er normal; en HIT på kurv eller konto er farlig.

Risiko: Lav ved læsning, middel ved regelændring Forventet tid: 10-30 minutter Hav klar: Browserens Network-panel eller et header-værktøj og kendskab til aktive Cache Rules

Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. Headerfortolkningen er fagligt gennemgået. Hostious er ikke bag Cloudflare, så en syntetisk CF-Cache-Status-visning fra staging er et undervisningseksempel og ikke en header målt fra Cloudflare eller Hostious-produktion.

CF-Cache-Status er et svarheader fra Cloudflare. Det beskriver cachebeslutningen for den konkrete request — ikke en permanent egenskab ved hele siden. To besøgende kan få forskellige værdier, hvis cookies, query strings, hostname, metode eller edge-datacenter er forskellige.

Læs headeren uden at ændre noget

Åbn browserens Network-panel, genindlæs siden og vælg dokumentet eller filen. Under Response Headers finder du cf-cache-status. Alternativt kan du hente headers:

curl -I "$DIN_TEST_URL"

Brug samme URL ved gentagelsen. En ændret query string kan skabe en anden cache key. Browserens “Disable cache” styrer browsercachen; den slår ikke automatisk Cloudflares edge-cache fra.

Betydningen af de vigtigste værdier

Værdi	Hvad den fortæller	Normal situation	Hvornår du undersøger videre
DYNAMIC	Requesten blev ikke cache-egnet	HTML uden fuld sidecache, POST, bypass-regel	Når en statisk/cache-planlagt URL altid er DYNAMIC
BYPASS	Originrespons eller konfiguration forhindrede cache	Sessioncookie, private/no-cache, auth	Når en offentlig fil burde kunne cachelagres
MISS	Cache-egnet, men objektet var ikke i denne cache	Første request efter purge eller i nyt datacenter	Når samme request bliver ved med MISS
HIT	Objektet blev leveret fra edge-cache	CSS, JS, billeder og bevidst cachet offentlig HTML	Når svaret er personligt eller dynamisk
EXPIRED	Objektet var udløbet og skulle hentes igen	Første request efter TTL	Ved meget kort eller utilsigtet TTL
REVALIDATED	Cloudflare validerede objektet mod origin	Origin bruger ETag/Last-Modified	Hvis validering sker på hver request
STALE	Et gammelt objekt blev leveret under bestemte fejl-/cachevilkår	Kontrolleret stale-politik	Hvis ændringer ikke bliver synlige
UPDATING	Stale objekt vises, mens opdatering sker	Populært objekt under asynkron refresh	Hvis værdien aldrig går tilbage til HIT

Cloudflares UI og adfærd udvikler sig. Brug altid headeren sammen med aktive regler og originens Cache-Control, ikke som et isoleret facit.

Hvorfor får HTML ofte DYNAMIC?

Cloudflare cacher ikke enhver HTML-side som standard. Hvis filtypen ikke er en standard cachetype, og ingen Cache Rule gør den cache-egnet, er DYNAMIC forventet. Det er ikke en fejl og betyder ikke, at Cloudflare er “slukket”. DNS-proxy, TLS, WAF og andre funktioner kan stadig være aktive.

En Cache Rule med Bypass cache kan også resultere i DYNAMIC, fordi reglen gør requesten uegnet før cacheopslaget. Derfor er “DYNAMIC betyder ingen regel” en forkert konklusion. Brug Cloudflare Trace eller gennemgå reglerne i rækkefølge.

Hvorfor får du BYPASS?

BYPASS ses typisk, når originens svar eller requestens tilstand fortæller Cloudflare, at objektet ikke skal lagres. Det kan være:

• en Cache-Control-værdi som private eller no-cache;
• en Set-Cookie-respons eller en sessioncookie afhængigt af cachekonfigurationen;
• en bypassregel for login, kurv eller konto;
• en autoriseret request;
• en Worker eller anden konfiguration, som ændrer cachebeslutningen.

På personlige sider er BYPASS ofte korrekt. Før du “fikser” det, afgør om to brugere må modtage samme HTML. Hvis svaret er nej, skal siden ikke blive HIT.

Hvorfor bliver MISS ved med at komme?

Første request efter purge eller i et nyt Cloudflare-datacenter er normalt MISS. Gentag fra samme klient og med præcis samme URL. Hvis MISS fortsætter, undersøg:

1. Query strings: Hver unik parameter kan skabe en ny key.
2. Cookies eller headers i custom cache key: En værdi pr. bruger forhindrer genbrug.
3. Meget kort edge TTL: Objektet udløber mellem requests.
4. Purge-loop: WordPress, deployment eller webhook rydder cachen hele tiden.
5. Objektstørrelse eller responsvilkår: Originens svar bliver ikke stabilt lagret.
6. Forskellige datacentre: En VPN eller mobilforbindelse kan flytte requesten.

Kontrollér CF-Ray-suffixet for datacenter uden at offentliggøre hele Ray ID'et. Se også efter Age: et stigende Age sammen med HIT viser, at det samme cacheobjekt genbruges.

En sikker diagnose i seks requests

Vælg en offentlig statisk fil, som må deles mellem alle brugere.

1. Hent filen uden query string og gem status, CF-Cache-Status, Age, Cache-Control og CF-Ray-lokation.
2. Gentag efter få sekunder med samme klient.
3. Gentag i privat vindue uden cookies.
4. Tilføj en unik query string og se, om du bevidst skaber MISS.
5. Fjern query string og bekræft, at den oprindelige key stadig kan være HIT.
6. Brug Cloudflare Trace på URL'en, hvis resultatet ikke matcher reglerne.

Lav ikke testen på checkout, Min konto eller en side med persondata. Der er målet DYNAMIC eller BYPASS, ikke HIT.

Ret DYNAMIC eller BYPASS, når siden faktisk bør caches

Kontrollér først, at URL'en er offentlig og identisk for alle besøgende. Gennemgå derefter matching Cache Rules og originens response headers. Fjern kun den betingelse, der utilsigtet forhindrer caching.

Hvis en bred cookie findes på alle sider, bør du afklare, om den kan begrænses til de routes, der bruger den. Ignorér ikke alle cookies i cache key eller cacheeligibility; det kan blande login- eller kurvesessioner.

Ret gentagen MISS uden at ødelægge dynamik

Reducer unødvendig cache-key-variation. Ignorér kun dokumenterede marketingparametre, når HTML-indholdet er identisk med og uden dem. Bevar parametre, der skifter sprog, valuta, produktvisning eller adgang.

Undersøg purge-kilden før du øger TTL. Hvis et plugin rydder hele cachen ved enhver lille ændring, skal purge gøres mere præcis. En længere TTL løser ikke et konstant purge-loop.

Mikroeksempel: fire requests, fire forskellige forklaringer

En anonym produktside giver MISS og derefter HIT. Det er et normalt første cachefyld. Den samme URL med en valuta-cookie giver BYPASS, fordi svaret varierer efter brugerstate. Checkout giver DYNAMIC, fordi HTML'en ikke er cache-egnet. En statisk CSS-fil giver HIT med en stigende Age. Værdierne er ikke en rangliste; de beskriver fire forskellige, muligvis korrekte beslutninger.

Når en tester siger “jeg får altid MISS”, så sammenlign først requestidentiteten. Skifter edge-datacenter, query string, Accept-Encoding, hostname eller en cookie, kan hver request have sin egen cache key. Et cachelag kan også blive purget af en deployment eller en fejlbehæftet WordPress-hook mellem målingerne. Notér disse forskelle, før TTL hæves.

Headerkombinationer, der fortjener ekstra opmærksomhed

• HIT sammen med personligt indhold er akut, selv om siden er hurtig.
• BYPASS med Set-Cookie kan være helt korrekt; find cookiens ejer, før den fjernes.
• MISS uden efterfølgende HIT kan skyldes lagring, purge eller skiftende cache key.
• DYNAMIC på HTML er ikke automatisk en fejl, særligt ved login, formular og checkout.
• Manglende CF-Cache-Status kan betyde, at hostnavnet ikke er proxied, eller at et andet lag svarer før Cloudflare.

Brug ikke en syntetisk header som bevis for en aktiv zone. Den kan lære dig at læse feltet, men kun en rigtig response fra det konkrete hostname viser, hvilken edgebeslutning der blev truffet.

Sådan eftertester du

• En offentlig cache-egnet testfil går fra MISS til HIT fra samme datacenter.
• Age stiger på gentagne HIT-svar, hvis headeren er tilgængelig.
• HTML uden planlagt fuld sidecache forbliver DYNAMIC/BYPASS.
• Kurv, checkout, konto og login er aldrig HIT.
• En purge giver forventet MISS og derefter HIT — uden at personligt indhold deles.
• Trace og CF-Cache-Status stemmer overens med den sidste matchende regel.

Rul tilbage

Deaktivér eller gendan den ene Cache Rule, cache key eller TTL, du ændrede. Purge kun de berørte URL'er, hvis muligt. Test derefter både en offentlig side og en sessionsside. Hvis en sessionsside nogensinde viser HIT, skal den brede cacheregel straks rulles tilbage.

Hvornår skal hosting eller udvikler hjælpe?

Hosting skal hjælpe, når originens headers eller servercache skaber BYPASS/MISS. En udvikler skal gennemgå cookies, sessions og purge-hooks. WordPress-hosting hos Hostious kan være relevant, når edge- og origin-cache skal analyseres samlet.

Ofte stillede spørgsmål om CF-Cache-Status

Hvorfor viser min side DYNAMIC i stedet for HIT?

Fordi Cloudflare som standard ikke cacher HTML – kun statiske filtyper. DYNAMIC betyder ‘ikke cache-egnet uden regel’. Vil du cache HTML, kræver det en Cache Rule med Eligible for cache.

Hvad betyder BYPASS, og hvornår er det korrekt?

At noget aktivt forhindrede caching: en regel, en cookie eller originens Cache-Control. På kurv, checkout og login er BYPASS præcis, hvad du VIL se – dér må der aldrig caches.

Er MISS et problem?

Nej – MISS betyder blot, at svaret var cache-egnet, men ikke lå i cachen endnu. Næste request fra samme edge bør give HIT. Konstant MISS tyder på kort TTL eller mange cache keys.

Læs også

• Opsæt sikre standarder med Cloudflare-indstillinger til WordPress.
• Webshops skal bruge Cloudflare Cache Rules til WooCommerce.
• Kontrollér om værtsnavnet overhovedet er proxied i orange eller grå sky i Cloudflare DNS.
• Ved forældet WordPress-indhold bør du også kontrollere sidens lokale cachelag i WordPress performance og cache.
• Se hele emnet i Cloudflare-guides til WordPress.
• WordPress hosting hos Hostious – hosting der er hurtig uden ekstra lag ovenpå

Sådan dokumenterer du din egen cacheanalyse

Gem en lille requestmatrix i stedet for et enkelt screenshot. Brug samme URL, hostname, query string og cookie-state mindst tre gange, og skriv CF-Cache-Status, Age, Cache-Control, eventuelle Set-Cookie samt det datacenter, du ramte. Gentag derefter med en bevidst ændring — for eksempel uden cookies — så forskellen kan forklares.

En maskinevenlig tabel kan have kolonnerne tidspunkt, klientstate, URL, status, CF-Cache-Status, Age og relevant regel. Cookieværdier skal fjernes; navnene er normalt nok til at finde en bypass. Hvis Cloudflare Trace bruges, beskæres konto- og zoneidentitet, men den matchende regel og dens placering i rækkefølgen bevares.

Efter en ændring skal du dokumentere både det tilsigtede hit og den tilsigtede undtagelse. En offentlig artikel kan forventes at gå fra MISS til HIT, mens login, konto, kurv og checkout fortsat skal være dynamiske eller bypassede. Det er først en forbedring, når begge dele er sande. Hvis kun hitraten stiger, men sessioner blandes, har testen afsløret en sikkerhedsfejl — ikke en cachegevinst.