导航|地址|刷新
How Workers interact with Cache Rules
图
Skip to contentDocumentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/cache/llms.txt
Use this file to discover all available pages before exploring further.



DocsDirectoryAPISDKsChangelog

Search

Log in






Cache / CDN

/




Overview

Plans

Get started


Concepts


CDN-Cache-Control

Cloudflare cache responses

Customize cache

Default cache behavior

Head Requests and Set-Cookie Headers

Origin Cache Control

Retention vs Freshness (TTL)

Revalidation

Vary






Cache configuration



Purge cache


Overview

Purge by single-file

​Purge everything

Purge cache by cache-tags

​Purge cache by hostname

​Purge cache by prefix (URL)

Purge cache key resources

P​urge varied images

Purge zone versions via API






Cache Response Rules


Overview

Create a rule in the dashboard

Create a rule via API

Terraform example

Available settings






Cache Rules


Overview

Create a rule in the dashboard

Create a rule via API

Terraform example

Available settings

Order and priority


Examples


Overview

Browser Cache TTL

Bypass Cache on Cookie

Cache by Device Type

Cache Deception Armor

Cache everything for hostnames in a list

Cache Everything while ignoring query strings

Cache Level (Cache Everything)

Cache TTL by status code

Custom Cache Key

Edge Cache TTL

Origin Cache Control

Query String Sort

Respect Strong ETags





Migration from Page Rules






Edge and Browser Cache TTL


Overview

Set Browser Cache TTL





Always Online

Cache by status code

Cache keys

Caching levels

Tiered Cache






Advanced configuration


Serving tailored content

Cache Reserve

Crawler Hints

Early Hints

Query String Sort

Vary for images






Performance review


Cache Analytics

Cache performance






Cache security


Avoid web cache poisoning

Cache Deception Armor

Cross-Origin Resource Sharing (CORS)






Reference


CDN Reference Architecture ↗

CSAM Scanning Tool

Development Mode

Using ETag Headers with Cloudflare






Interaction with Cloudflare products


Customize cache behavior with Workers

How Workers interact with Cache Rules

Enable cache in an R2 bucket

Control cache access with WAF and Snippets






Troubleshooting


Dynamic content and login issues

Issues with MP4 videos on iOS and Safari

Bot Management cookie causes cache bypass in O2O setups

edgeResponseBytes and cacheResponseBytes discrepancy

Always Online





Changelog

Glossary


Agent resources


Agent setup ↗

Cloudflare Skills ↗

Code Mode MCP Server ↗

Domain-specific MCP Servers ↗MCP

Cache llms.txt ↗

Cache llms-full.txt ↗

Cloudflare Docs llms.txt ↗

Cloudflare Docs llms-full.txt ↗













Home

/Cache / CDN

/Interaction with Cloudflare products

/How Workers interact with Cache Rules



How Workers interact with Cache Rules


Last updated May 7, 2026|Copy as Markdown|View as Markdown|Agent setup

OverviewPrecedence orderCompatibility flags Compatibility date behavior Example (Older compatibility date)




When you use both Cache Rules and Workers on the same request, the Worker's cache settings take priority — but only when the required compatibility flags are enabled.

Your Workers script can override Cache Rules behavior, whether the request is for a domain proxied through Cloudflare or a domain that is not. For example, if a Cache Rule is configured to bypass cache for example.com/foo, but your Workers script sets cacheEverything: true in the cf object of a fetch() request, the Worker's setting takes precedence and the response is cached.


Precedence order


Cache behavior is determined by the following order of precedence:

Workers script settings

Cache rules

Page rules

Workers override Cache Rules, and Cache Rules override Page Rules. When multiple rules at the same level match the same request, the last matching rule wins for any conflicting settings.


Compatibility flags


The override behavior is controlled by compatibility flags — configuration settings that opt your Worker into specific runtime behaviors. There are two flags because Workers have two ways to interact with the cache:

For the Fetch API (fetch() with cf properties): request_cf_overrides_cache_rules

For the Cache API (caches.default.put() / caches.default.match()): cache_api_request_cf_overrides_cache_rules

These flags must be enabled to allow Workers scripts to override Cache Rules. If the correct flag is not enabled for the API you are using, your Worker's cache settings are silently ignored and Cache Rules apply instead.


Compatibility date behavior


A Worker's compatibility date determines which flags are active by default. When you set a compatibility date, all flags with an enable date on or before that date are automatically turned on.


FlagEnabled by defaultPrerequisite
request_cf_overrides_cache_rules (Fetch API)Compatibility dates on or after 2025-04-02None
cache_api_compat_flagsCompatibility dates on or after 2025-04-19None
cache_api_request_cf_overrides_cache_rules (Cache API)Compatibility dates on or after 2025-05-19Requires cache_api_compat_flags



The Cache API has an extra requirement: cache_api_compat_flags must be enabled for any compatibility flags to take effect on the Cache API. Without it, the Cache API ignores all compatibility flags, even ones you explicitly list in your configuration.

If your Worker uses a compatibility date before the dates listed above, you must manually add the flags to your configuration. Otherwise, cache behavior follows Cache Rules instead of the Worker's settings.


Example (Older compatibility date)


A Cache Rule bypasses cache for example.com/foo. A Worker with a compatibility date before 2025-04-02 sets cacheEverything: true via fetch(). Because the compatibility date is too old for request_cf_overrides_cache_rules to be active by default, the Cache Rule wins and the response is not cached.

Similarly, if you use the Cache API and your compatibility date is before 2025-04-19, cache_api_compat_flags is not active. Even if you manually add cache_api_request_cf_overrides_cache_rules to your configuration, it has no effect because the Cache API does not recognize compatibility flags without cache_api_compat_flags.


PreviousCustomize cache behavior with WorkersNextEnable cache in an R2 bucket


Was this helpful?

YesNo

Edit pageReport issue




On this page

Overview

Precedence order

Compatibility flags

Compatibility date behavior

Example (Older compatibility date)


Edit pageReport issue














Getting started
PlansContact salesPartnersFind a partnerStartupsUnder attack?Domain name search


Company
AboutCareersInvestorsPressPress kitGlobal network




Public interest
Project GalileoAthenian ProjectCloudflare for CampaignsProject FairshotImpact/ESG


Compliance
Compliance resourcesTrust HubData ProtectionResponsible AITransparency reportReport abuse




Resources
App innovation reportCloudflare RadarCase studiesStatusSupportEventsBlog


Developers
DocumentationLearning centerCommunity




Solutions
SSE and SASE platformCloudflare AI CloudAI SecurityFrontend Development PlatformMulti-Tenant Platform DevelopmentWeb Security Platform


Start BuildingLog In












© 2026 Cloudflare, Inc.

Privacy policy|Report security issues|Terms of use|Trademark
|
Your privacy choices








Docs




------
导航页 打开网址