Af Greg Nowak. Senest opdateret 2026-07-23.
En offentlig side bør ikke kræve en ny release af applikationen, blot fordi dens response indeholder den forkerte cache-header. Cloudflare Cache Response Rules giver driftsteams en mere direkte mulighed: De kan justere udvalgte Cache-Control-direktiver, administrere cache-tags eller fjerne bestemte headers, efter at Cloudflare har modtaget origin-responsen, men før platformen beslutter, hvordan den skal caches.
Det er nyttigt for indholdssites, kategorisider i webshops, kampagnelandingssider, dokumentation og andre anonyme routes, hvor unødvendige requests til origin påvirker performance og driftsomkostninger. Det giver også bureauer en klart afgrænset opgave, som de kan auditere, teste og aflevere med tydeligt ejerskab. Det vigtige ord er dog udvalgte. Edge-regler er et præcisionsværktøj, ikke en tilladelse til at cache alle URL'er.
Hvad Cache Response Rules faktisk ændrer
Reglerne blev lanceret i marts 2026 og kører i Cloudflares http_response_cache_settings-fase. De kan ændre individuelle cache-direktiver, tilføje eller transformere cache-tags og fjerne Set-Cookie, ETag eller Last-Modified. De kan matche egenskaber fra både request og response, herunder hostname, sti, metode, response-status og response-headers.
De erstatter ikke almindelige Cache Rules. Cache Rules i requestfasen afgør fortsat, om et aktiv kan caches. En Response Rule kan rette headers på en response, der er kvalificeret til caching, eller gøre den ikke-cachebar med no-store, men den kan ikke i sig selv ændre en DYNAMIC-beslutning fra requestfasen til en kvalificeret route.
Begynd med data fra rigtige URL'er
Opbyg et udvalg, der omfatter kommercielt vigtige sider, sider med lav trafik, autentificerede routes og mindst én URL fra hver væsentlig skabelon. Undersøg en almindelig GET-response i stedet for at antage, at en HEAD-request opfører sig på samme måde:
curl -sS -D - -o /dev/null https://www.example.com/important-pageRegistrer CF-Cache-Status, Age, Cache-Control, Set-Cookie, ETag og Last-Modified. Gentag requesten: En første MISS efterfulgt af et HIT er som regel normalt, mens en vedvarende status peger på en beslutning om policy eller cache-kvalificering.
| Status | Hvad den betyder | Hvor du skal undersøge sagen |
|---|---|---|
HIT |
Responsen kom fra Cloudflares cache. | Kontrollér, at TTL og purge-adfærd passer til indholdets udgivelsescyklus. |
MISS |
Responsen kunne caches, men fandtes ikke i den lokale cache. | Gentag requesten, før du betragter det som en fejl. |
BYPASS |
Requesten var kvalificeret, men responsen kunne i sidste ende ikke caches. | Gennemgå Cache-Control, Set-Cookie, autorisation og andre blokeringer i responsefasen. |
DYNAMIC |
Cloudflare besluttede i requestfasen, at aktivet ikke var kvalificeret. | Gennemgå Cache Rules, route-design og bevidste bypasses. |
UPDATING |
Udløbet indhold blev leveret, mens Cloudflare opdaterede det asynkront. | Det er forventet, når stale-while-revalidate fungerer. |
REVALIDATED |
Cloudflare ventede på synkron validering hos origin. | Undersøg, om stale-while-revalidate mangler, eller om direktiver forhindrer levering af stale indhold. |
CF-Cache-Status-værdier.Forskellen mellem BYPASS og DYNAMIC er særlig værdifuld. Siden Cloudflares statusændring i maj 2026 har BYPASS konsekvent identificeret en response, som Cloudflare nægtede at cache, efter at den oprindeligt var vurderet som kvalificeret. Det gør statusværdien til et stærkt spor i arbejdet med at rydde op i response-headers. DYNAMIC sender dig normalt tilbage til cache-kvalificeringen i requestfasen.
Vælg sikre kandidater, ikke kun de nemme
En god kandidat er anonym, reproducerbar og dokumenterbart identisk på tværs af besøgende. Det kan eksempelvis være publicerede artikler, offentlig dokumentation og landingssider uden kontospecifikke priser eller eksperimenter. Dårlige kandidater er blandt andet dashboards, indkøbskurve, kontosider, checkout-flows, preview-URL'er og responses, hvor cookies styrer personalisering, samtykke, valuta eller autentificering.
Fjernelse af Set-Cookie kræver den grundigste vurdering. Identificer først præcist, hvad der sætter cookien, og om det ændrer adfærden at fjerne den. Afgræns reglen snævert efter hostname, sti, requestmetode og response-kode. Test flows for brugere, der henholdsvis er logget ud og logget ind. Hvis teamet ikke kan forklare cookiens funktion, er den sikre beslutning at lade den være, indtil de kan.
Vær lige så forsigtig med validatorer. Cloudflare oplyser, at fjernelse af enten ETag eller Last-Modified deaktiverer Smart Edge Revalidation for den pågældende response. Fjernelse kan løse ét afgrænset problem, men samtidig øge det efterfølgende arbejde med overførsel eller validering.
En udrulning, som driftsteamet kan eje
- Baseline: Registrer headers og cache-status for et repræsentativt udvalg af routes, før konfigurationen ændres.
- Klassificér: Skeln mellem kvalificeringsproblemer i requestfasen, headerproblemer i responsefasen og reelle afhængigheder i applikationen.
- Skift én ting ad gangen: Kombiner ikke ændringer af kvalificering, cache-key, cookies og TTL i én release, der ikke kan spores.
- Simulér og stage: Brug Cloudflare Trace til at se, om reglerne vil matche. Hvis Version Management er tilgængeligt i jeres setup, skal ændringer af response-regler holdes i en version og flyttes gennem miljøerne.
- Verificér adfærden i produktion: Gentag rigtige requests, test autentificerede brugerflows, og bekræft, at det returnerede indhold, cookies, browser-headers og purge-processen stadig fungerer korrekt.
- Overvåg: Hold øje med
BYPASSpå route-niveau, trafik til origin og supporthenvendelser, og dokumentér, hvem der ejer en eventuel rollback.
Én TTL-fælde er værd at fremhæve. Cloudflare dokumenterer, at s-maxage medfører revalideringsadfærd, som forhindrer stale-while-revalidate i at levere stale indhold. Hvis browsere og Cloudflare skal have forskellige TTL'er, samtidig med at asynkron revalidering forbliver aktiveret, skal du bruge max-age sammen med stale-while-revalidate i origin-policyen og konfigurere Cloudflares Edge Cache TTL separat.
Gør edge-rettelsen til en del af et system, der kan vedligeholdes
Den umiddelbare gevinst kan være færre unødvendige requests til origin, men det varige resultat er en cache-policy, som teamet forstår: hvilke routes der er offentlige, hvilke headers der er autoritative, hvordan indhold purges, hvem der godkender undtagelser, og hvordan ændringer testes.
Hvis jeres vigtige offentlige sider bliver ved med at returnere BYPASS eller DYNAMIC, kan Greg auditere de aktuelle headers, skelne mellem sikre edge-ændringer og arbejde i applikationen samt give teamet en plan for trinvis udrulning. Tal med Greg om en audit af Cloudflare-caching.
Relateret indhold på GrN.dk
- Cloudflare AI Gateway lægger LLM-budgetter ind i requeststien
- AI-agenter skal have en browser-policy, før de begynder at klikke rundt
- AI-automatiseringer skal have et dashboard over forbruget før den første løbske regning
Har du brug for hjælp til denne type arbejde?
Tal med Greg om en audit af Cloudflare-caching Kontakt Greg.
