Cloudflare Cache Response Rules: Sikrere headerrettelser på edge-niveau

Af Greg Nowak. Senest opdateret 2026-10-18.

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.

Cache Rule eller Cache Response Rule?

En Cache Rule ser på requesten og afgør, om URL'en kan caches, under hvilken nøgle og hvor længe. En Cache Response Rule ser på origin-responsen og kan omskrive Cache-Control, ændre cache-tags eller fjerne Set-Cookie, ETag og Last-Modified, før Cloudflare beslutter, om den skal gemmes. I praksis: DYNAMIC er et Cache Rule-problem, BYPASS er som regel et Cache Response Rule-problem. Response Rules findes på alle planer (10 regler på Free, 25 på Pro, 50 på Business, 300 på Enterprise) og er det eneste sted, man kan tilsidesætte origins cache-headers; en Worker eller en Response Header Transform Rule kører efter cache-beslutningen og kan ikke ændre den.

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-page

Registrer 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.

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

1. Baseline: Registrer headers og cache-status for et repræsentativt udvalg af routes, før konfigurationen ændres.
2. Klassificér: Skeln mellem kvalificeringsproblemer i requestfasen, headerproblemer i responsefasen og reelle afhængigheder i applikationen.
3. Skift én ting ad gangen: Kombiner ikke ændringer af kvalificering, cache-key, cookies og TTL i én release, der ikke kan spores.
4. 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.
5. 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.
6. Overvåg: Hold øje med BYPASS på 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.

Hurtige svar

Kan en Cache Response Rule gøre en DYNAMIC-side cachebar?

Nej. Kvalificeringen afgøres af Cache Rules på requesten. Tilføj først en Cache Rule for routen, og brug derefter en Response Rule til den header, der stadig giver BYPASS.

Kører den på responses, Cloudflare ikke cacher?

Ja. Reglen kører på alle matchende origin-responses, cachede eller ej, så den kan for eksempel fjerne en Set-Cookie fra en response, der forbliver dynamisk.

Hvem vinder, når en Cache Rule og en Cache Response Rule er uenige?

Response Rule. Når en Response Rule matcher, skifter Cloudflare desuden til Origin Cache Control-adfærd for den response, og blandt flere matchende Response Rules vinder den sidste for samme indstilling. Tjek med Cloudflare Trace, før du slår reglen til.

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.

Kilder

• Cache Response Rules
• Cloudflare-cache-responses
• Revalidering
• Cache Response Rules understøtter nu zone-versionering
• BYPASS-status returneres nu for responses, der ikke kan caches