# Cache # Changelog import { ProductChangelog } from "~/components"; {/* B[WAF] --> C[Cache] --> D[R2] ```
## Presigned URLs A presigned URL is a regular URL with a cryptographic token appended to it. The token contains a hash-based message authentication code (HMAC) computed from the URL path, a timestamp, and a secret key shared between the signing service and the validator. Anyone with the URL can access the content until the token expires, but the token cannot be reused for a different URL path. You can presign URLs similar to [S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html), enabling you to share direct access to your content with an associated timeout. This approach can be implemented using a combination of Snippets, Rules, or Cloudflare Workers. For optimal performance, we recommend separating the creation and validation processes: - [Snippets](/rules/snippets/examples/signing-requests/) for HMAC creation (signing the URL) - [WAF custom rules](/ruleset-engine/rules-language/functions/#hmac-validation) for HMAC validation (verifying the token on each request) In the Workers documentation, the [Signing requests](/workers/examples/signing-requests/) example shows how to both generate and verify signed requests using HMAC. The Workers implementation is compatible with the WAF's [`is_timed_hmac_valid_v0()` validation function](/waf/custom-rules/use-cases/configure-token-authentication/), so you can sign with Workers and validate with WAF custom rules, or handle both in Workers. # How Workers interact with Cache Rules When you use both [Cache Rules](/cache/how-to/cache-rules/) and [Workers](/workers/) on the same request, the Worker's cache settings take priority — but only when the required [compatibility flags](#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](/workers/runtime-apis/request/#the-cf-property-requestinitcfproperties) 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: 1. [Workers](/workers/) script settings 2. [Cache rules](/cache/how-to/cache-rules/) 3. [Page rules](/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](/cache/how-to/cache-rules/order/) for any conflicting settings. ## Compatibility flags The override behavior is controlled by [compatibility flags](/workers/configuration/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](/workers/runtime-apis/fetch/) (`fetch()` with `cf` properties): `request_cf_overrides_cache_rules` - For the [Cache API](/workers/runtime-apis/cache/) (`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](/workers/configuration/compatibility-dates/) 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. | Flag | Enabled by default | Prerequisite | | --- | --- | --- | | `request_cf_overrides_cache_rules` (Fetch API) | Compatibility dates on or after `2025-04-02` | None | | `cache_api_compat_flags` | Compatibility dates on or after `2025-04-19` | None | | `cache_api_request_cf_overrides_cache_rules` (Cache API) | Compatibility dates on or after `2025-05-19` | Requires `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`. # Customize cache behavior with Workers You can use [Workers](/workers/) to customize cache behavior on Cloudflare's network. Workers run as middleware in the request lifecycle — a single Worker handles both the request and response phases. When a request arrives, it hits the Worker before the cache is checked. The Worker can modify the incoming request (for example, rewrite the URL or add headers), then call `fetch()` to continue the request through the cache. When the response comes back — whether from cache or from the origin server — the Worker can also modify the response before it is sent to the visitor. :::note This page describes how Workers interact with a zone's Cloudflare Cache. You can also enable **[Workers Cache](/workers/cache/)** for your Worker — a cache that sits in front of the Worker itself, so that Cloudflare returns a cached response without running the Worker. Use Workers Caching to cache the output of a Worker's logic directly, independent of any zone configuration. ::: The diagram below illustrates a common interaction flow between Workers and Cache. ![Workers and cache flow example flow diagram.](~/assets/images/cache/workers-cache-flow.png) 1. A visitor (a) requests a URL, and this request is directed to a Worker. The Worker can then interact with the request, either requesting the content from the origin server using (b) `fetch()` or sending a (f) response back to the visitor. 2. If the content is cached, the cache sends a (e) response back to the Worker, which can modify the response before sending a (f) response back to the visitor. 3. When using [cache rules](/cache/how-to/cache-rules/) with Workers, the cache rule must match the properties of the URL in the `fetch()` (b) request — such as headers, hostname, or URL path — not the original visitor URL/host (a). Otherwise, the rule will not be applied. Here are a few examples of how Workers can be used to customize cache behavior: - **Modify Response**: Adjust or enhance content after it is retrieved from the cache, ensuring that responses are up-to-date or tailored to specific needs. - **Signed URLs**: Generate time-limited signed URLs to control access and enhance security. - **Personalized Response**: Deliver personalized content based on user data while using cached resources to reduce the load on the origin server. - **Reduce Latency**: Serve content from a data center close to the visitor, decreasing load times and improving the user experience. You can also use [Snippets](/rules/snippets/) for lightweight modifications like header changes, redirects, and JWT validation without deploying a full Worker script. Snippets are included at no additional cost on all paid plans but have stricter resource limits (5 ms execution time, 32 KB package size). :::note When using Workers and [O2O](/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/how-it-works/) (a traffic routing configuration where requests pass through two Cloudflare zones), some caveats and limitations may apply. ::: ## Cache features in Workers Workers offer two ways to interact with the cache. Use `fetch()` when your Worker makes subrequests to an origin. Use the Cache API when your Worker generates responses without a backend origin. - **fetch()**: When a Worker calls `fetch()`, the request passes through Cloudflare's cache and [Tiered Cache](/cache/how-to/tiered-cache/) (if enabled). You can control caching behavior by setting properties on the request's [`cf` object](/workers/runtime-apis/request/#the-cf-property-requestinitcfproperties) — including time-to-live (TTL) values, custom cache keys, and cache headers. For more details, refer to [Cache using fetch](/workers/examples/cache-using-fetch/). - **Cache API**: Allows you to programmatically store, retrieve, and delete responses in Cloudflare's cache using `caches.default` or `caches.open()`. Unlike `fetch()`, the Cache API only operates on the cache in the data center handling the current request — it does not interact with Tiered Cache. Use the Cache API when you need to cache responses that did not come from an origin. For more details, refer to [Using the Cache API](/workers/examples/cache-api/). To understand more about how Cache and Workers interact, refer to [Cache in Workers](/workers/reference/how-the-cache-works/). # Cache Analytics import { DashButton } from "~/components" Cache Analytics shows how much of your site's traffic is served from Cloudflare's cache versus your origin server. When content is served from cache, visitors get faster page loads and your origin web server handles less traffic. Use Cache Analytics to identify resources that are [missing from cache](/cache/concepts/cache-responses/#miss), [expired](/cache/concepts/cache-responses/#expired) (cached copy is outdated), or [ineligible for caching](/cache/concepts/cache-responses/#noneunknown) (not eligible for caching). You can filter by hostname, review the top URLs that miss cache, and query up to three days of data. ## Availability | | Free | Pro | Business | Enterprise | | - | - | - | - | - | | Availability | No | Yes | Yes | Yes | | Retention period | N/A | 7 days | 30 days | 30 days | ## Access Cache Analytics In the Cloudflare dashboard, go to the **Caching** page. ## Requests vs Data Transfer You can decide whether to focus on **Requests** or **Data Transfer**: - **Requests** (default view) helps assess performance. Each cache [MISS](/cache/concepts/cache-responses/#miss) means the request must go to your origin server instead of being served from Cloudflare's cache, which adds latency. - **Data Transfer** is useful for cost analysis, since most hosting providers charge for data sent from their servers (egress bandwidth). You can switch between these views while keeping other analytics filters applied. For best practices related to Cache Analytics, refer to [Cache performance](/cache/performance-review/cache-performance/). ## Add filters Create filters to narrow the data to specific traffic segments. Example filters include **Cache status**, **Host**, **Path**, or **Content type**. To add filters, under **Cache Performance**, select **Add filter**. Select **Apply** when you are done. ## Review cache status The **Requests summary** graph shows how your traffic changes over time, such as in response to a high-traffic event or a recent configuration change. The Requests summary is based on a sample of requests, not the full dataset. Totals are extrapolated from the sample to represent overall traffic. For more information on how sampling works, refer to [Understanding sampling in Cloudflare Analytics](/analytics/sampling/). **Served by Cloudflare** indicates content served by Cloudflare that did not require contacting your origin web server. **Served by Origin** indicates traffic served from the origin web server. :::tip In Cache Analytics, **Served by Cloudflare** reflects cache hits. For the broader definition — which also covers Workers responses, [URL forwarding](/rules/url-forwarding/) redirects, and `/cdn-cgi/` endpoints — refer to [Security Analytics — Request activity](/waf/analytics/security-analytics/#request-activity). ::: Revalidated requests — where Cloudflare checks with your origin to confirm cached content is still current — are counted differently depending on the view. In the **Data Transfer** view, revalidated requests count as **Served by Cloudflare** because the response body is served from cache, not re-downloaded from the origin. In the **Requests** view, revalidated requests count as **Served by Origin** because Cloudflare still contacts the origin server to verify the content. **Cache status** graphs break down why traffic is served from Cloudflare versus the origin web server, organized by content type. For a breakdown of cache statuses and their descriptions, refer to [Cloudflare cache responses](/cache/concepts/cache-responses/). ## Review requests by source Cache Analytics shows the most frequent values (top N) for several request attributes. Apply filters before reviewing these metrics to focus on specific traffic. For example, filtering to only view traffic with an Expired or Revalidated cache status shows which URLs were primarily responsible for those statuses. ### Empty content types Finding an **empty** content type in your analytics is common. Responses to redirect status codes (`301`/`302`) typically do not include content, so they have no content type. Similarly, many HTTP error responses, such as `403`, do not return `text/html` and are also reported as empty. # Cache performance Your cache ratio measures how often Cloudflare serves content from cache instead of contacting your origin server. A higher ratio means faster responses for visitors and less traffic to your origin. Depending on the [cache status](/cache/concepts/cache-responses/) you receive, you can make modifications to improve your cache ratio. - **Dynamic**: The resource was not eligible for caching. This is the default response for many file types including HTML. To cache additional content, refer to [Cache Rules](/cache/how-to/cache-rules/). - **Revalidated**: The resource was in cache but Cloudflare confirmed with your origin that it was still current before serving it. To address an atypical quantity of revalidated content, consider [increasing your Edge Cache TTLs](/cache/how-to/cache-rules/settings/#edge-ttl) (how long Cloudflare considers cached content fresh before checking your origin). - **Expired**: The cached resource's TTL elapsed before it was requested again. Consider [extending Edge Cache TTLs](/cache/how-to/cache-rules/settings/#edge-ttl) for these resources via a Cache Rule, or configure your origin to return [revalidation headers](/cache/concepts/cache-control/) (`Last-Modified` or `ETag`) so Cloudflare can confirm content is still current without downloading it again. - **Miss**: The resource was not found in cache and was served from your origin. Although tricky to optimize, there are a few potential remedies: - [Enable Tiered Cache](/cache/how-to/tiered-cache/#enable-tiered-cache) to check an upper-tier Cloudflare data center before contacting your origin server. - [Create a custom cache key](/cache/how-to/cache-rules/examples/custom-cache-key/) so that multiple URLs match the same cached resource, for example by ignoring the query string. ## Troubleshoot cache performance with example reports Use [Cache Analytics](/cache/performance-review/cache-analytics/) to identify cache performance issues. The following examples show how to filter for common problems and resolve them. - Not caching HTML. - Identify the issue: Select **Add filter** and select **Cache status equals Dynamic**. - Resolution: Set a Cloudflare Cache Rule to [cache dynamic content](/cache/how-to/cache-rules/examples/cache-everything/). :::caution This option caches all HTML regardless of the presence of dynamic content (content that changes per visitor, such as time of visit, location, or device). If you use this approach to cache pages containing dynamic content, visitors may receive information not intended for them. To avoid caching dynamic content, add a condition to the rule's matching criteria to exclude it. Some examples include: - Checking for the presence of a cookie. - Excluding requests that match known dynamic content file paths. - Excluding requests with dynamic content extensions (or no extension). ::: - Short cache expiration TTL. - Identify the issue: Select **Add filter** and select **Cache status equals Revalidated**. - Resolution: [Increase Cloudflare's Edge Cache TTL via a Cache Rule](/cache/how-to/cache-rules/examples/edge-ttl/). - Need to enable Tiered Cache or custom cache key. - Identify the issue: Select **Add filter** and select **Cache status equals Miss**. - Resolution: [Enable Tiered Cache](/cache/how-to/tiered-cache/#enable-tiered-cache) or [create a custom cache key](/cache/how-to/cache-rules/examples/custom-cache-key/). # Performance review import { DirectoryListing } from "~/components" Use Cache Analytics to understand how effectively Cloudflare caches your content, and apply optimization techniques to improve your cache hit ratio and reduce origin server load. # CSAM Scanning Tool The Child Sexual Abuse Material (CSAM) Scanning Tool allows website owners to proactively identify and take action on CSAM located on their website. By enabling this tool, Cloudflare will compare content served for your website through the Cloudflare cache to known lists of CSAM. These lists are provided to Cloudflare by leading child safety advocacy groups such as the National Center for Missing and Exploited Children (NCMEC). Remember, by enabling the Service, you agree to the [Service-Specific Terms](https://www.cloudflare.com/service-specific-terms-application-services/#csam-scanning-tool-terms) for the CSAM Scanning Tool. You agree to use this tool solely for the purposes of preventing the spread of CSAM. --- ## Why would a URL be blocked? Because knowingly distributing or viewing CSAM is illegal, the owner of the website has enabled Cloudflare's CSAM scanning tool to proactively identify and block images identified as CSAM located on their website. --- ## Configure the CSAM scanning tool To enable the tool: 1. Log into the [Cloudflare dashboard](https://dash.cloudflare.com/). 2. Select your account and zone. 3. Go to **Caching** > **Configuration**. 4. For **CSAM Scanning Tool**, select **Configure**. You must provide an email address, which will be used to notify you in the event Cloudflare detects a positive match. --- ## What happens when a match is detected? When a potential match is detected with the tool: 1. An email is sent to you once per day to inform you of any detections made in the past 24 hours. This email will include the file paths of any content that was matched. 2. If possible, a block is placed to prevent further serving of the matched content. If a block fails, we will indicate that the content has not been blocked in the email. --- ## What action should I take when a match is detected? You are responsible for understanding and complying with any legal obligations you have as a website owner when made aware of any potential CSAM. Although legal obligations vary based on the provider and the jurisdiction, website owners often have obligations to report apparent CSAM, to remove content, and to preserve records. Some of those possible obligations are as follows: - You likely have an obligation to report apparent CSAM to the appropriate authorities. You can file a report to NCMEC with additional information via NCMEC's CyberTip reporting form or find the preferred reporting portal for your jurisdiction via the INHOPE website.
- You may need to preserve and securely store a copy of the content and related data in the case NCMEC or law enforcement reach out for additional details. - You likely have an obligation to securely preserve certain information related to your report for one year in the case of an investigation. To ensure that access to the content is limited, take care not to store this information anywhere accessible to anyone but those within your organization responsible for legal requests.
- You should remove the content and notify Cloudflare of the removal. - Once any preservation obligations have been fulfilled, you should remove the content from your website. This is especially important if Cloudflare's notice to you indicates that our block was unsuccessful. --- ## How do I have a block removed from my website? To disable a block, either because you have determined that the blocked content is not CSAM (a false positive) or because you have taken down the blocked content, view [Blocked Content in the Security Center](/fundamentals/reference/report-abuse/blocked-content/) in the Cloudflare Dashboard and request reviews on the relevant blocks. A request to remove a block must be accompanied by a representation from you confirming that the blocked content is not CSAM or has been removed. These actions are available to users with the following roles: - Admin - Super Admin - Trust & Safety --- ## Additional Resources [CSAM Scanning Tool Supplemental Terms](https://www.cloudflare.com/supplemental-terms/) [National Center for Missing and Exploited Children (NCMEC)](https://www.missingkids.org/) [NCMEC CyberTipline](https://www.missingkids.org/gethelpnow/cybertipline) [INHOPE](https://www.inhope.org/) # Development Mode import { DashButton } from "~/components" Development Mode temporarily suspends Cloudflare's edge caching and [Polish](/images/polish/) features for three hours unless disabled beforehand. Development Mode allows customers to immediately observe changes to their [cacheable content](/cache/concepts/default-cache-behavior/#default-cached-file-extensions) like images, CSS, or JavaScript. :::note To bypass cache for longer than three hours, use bypass cache in [Cache Rules](/cache/how-to/cache-rules/settings/#bypass-cache). ::: ## Enable Development Mode Development Mode temporarily bypasses Cloudflare's cache and does not purge cached files. To instantly purge your Cloudflare cache, refer to [purge cache](/cache/how-to/purge-cache/). 1. In the Cloudflare dashboard, go to the **Configuration** page. 2. Toggle **Development Mode** to **On**. # Using ETag Headers with Cloudflare ETag headers identify whether the version of a resource cached in the browser is the same as the resource at the origin web server. A visitor's browser stores ETags. When a visitor revisits a site, the browser compares each ETag to the one it stored. Matching values cause a `304 Not-Modified HTTP` response that indicates the cached resource version is current. Cloudflare supports both strong and weak ETags configured at your origin web server. ## Weak ETags Weak ETag headers indicate a cached resource is semantically equivalent to the version on the web server but not necessarily byte-for-byte identical. :::note When using weak ETag headers, it is necessary to disable certain features such as [Email Obfuscation](/waf/tools/scrape-shield/email-address-obfuscation/), [Automatic HTTPS Rewrites](/ssl/edge-certificates/additional-options/automatic-https-rewrites/), and [Replace insecure JavaScript libraries](/waf/tools/replace-insecure-js-libraries/) to prevent Cloudflare from removing the ETag headers set by your origin web server. For a comprehensive list of the features you need to disable, refer to the [Notes about end-to-end compression](/speed/optimization/content/compression/#notes-about-end-to-end-compression). ::: ## Strong ETags Strong ETag headers ensure the resource in browser cache and on the web server are byte-for-byte identical. Use [Cache Rules](/cache/how-to/cache-rules/) to enable strong ETag headers. ### Behavior with Respect Strong ETags enabled When you enable **Respect Strong ETags** in a cache rule, Cloudflare will use strong ETag header validation to ensure that resources in the Cloudflare cache and on the origin server are byte-for-byte identical. However, in some situations Cloudflare will convert strong ETags to weak ETags. For example, given the following conditions: * **Respect Strong ETags** is enabled * [Brotli compression](/speed/optimization/content/compression/) is enabled * The origin server's response includes an `etag: "foobar"` strong ETag header The Cloudflare network will take the following actions, depending on the visitor's `accept-encoding` header and the compression used in the origin server's response: | `accept-encoding`
header from visitor | Compression used in origin server response | Cloudflare actions | | ----------------------------------------- | ------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | `gzip, br` | GZIP | Return GZIP-compressed response to visitor with strong ETag header: `etag: "foobar"`. | | `gzip, br` | Brotli | Return Brotli-compressed response to visitor with strong ETag header: `etag: "foobar"`. | | `br` | GZIP | Decompress GZIP and return uncompressed response to visitor with weak ETag header: `etag: W/"foobar"`. | | `gzip` | Brotli | Decompress Brotli and return uncompressed response to visitor with weak ETag header: `etag: W/"foobar"`. | | `gzip` | (none) | Return uncompressed response to visitor with strong ETag header: `etag: "foobar"`. | | `gzip, br, zstd` | Zstandard | Return zstd-compressed response to visitor with strong ETag header: `etag: "foobar"`. | `gzip, br` | Zstandard | Decompress zstd and return br response to visitor with weak ETag header: `etag: W/"foobar"`. | `zstd` | Brotli/GZIP | Decompress zstd and return zstd response to visitor with weak ETag header: `etag: W/"foobar"`. | Enabling **Respect Strong ETags** in Cloudflare automatically disables Rocket Loader, Email Obfuscation, and Automatic HTTPS Rewrites. ### Behavior with Respect Strong ETags disabled When **Respect Strong ETags** is disabled, Cloudflare will preserve strong ETag headers set by the origin web server if all the following conditions apply: * The origin server sends a response compressed using GZIP or Brotli, or an uncompressed response. * If the origin server sends a compressed response, the visitor accepts the same compression (GZIP, Brotli), according to the `accept-encoding` header. * [Rocket Loader](/speed/optimization/content/rocket-loader/), [Email Obfuscation](/waf/tools/scrape-shield/email-address-obfuscation/), and [Replace insecure JavaScript libraries](/waf/tools/replace-insecure-js-libraries/) features are disabled. In all other situations, Cloudflare will either convert strong ETag headers to weak ETag headers or remove the strong ETag. For example, given the following conditions: * **Respect Strong ETags** is disabled * [Brotli compression](/speed/optimization/content/compression/) is enabled * The origin server's response includes an `etag: "foobar"` strong ETag header The Cloudflare network will take the following actions, depending on the visitor's `accept-encoding` header and the compression used in the origin server's response: | `accept-encoding`
header from visitor | Compression used in origin server response | Cloudflare actions | | ----------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | | `gzip, br` | GZIP | Decompress GZIP and return Brotli-compressed response to visitor (since Brotli compression is enabled) with weak ETag header: `etag: W/"foobar"`. | | `gzip, br` | Brotli | Return Brotli-compressed response to visitor with strong ETag header: `etag: "foobar"`. | | `br` | GZIP | Decompress GZIP and return Brotli-compressed response to visitor with weak ETag header: `etag: W/"foobar"`. | | `gzip` | Brotli | Decompress Brotli and return GZIP-compressed response to visitor with weak ETag header: `etag: W/"foobar"`. | | `gzip` | (none) | Compress origin response using GZIP and return it to visitor with weak ETag header: `etag: W/"foobar"`. | | `gzip, br, zstd` | Zstandard | Return zstd-compressed response to visitor with strong ETag header: `etag: "foobar"`. | | `gzip, br` | Zstandard | Decompress zstd and return uncompressed response to visitor with weak ETag header: `etag: W/"foobar"`. | | `zstd` | Brotli | Decompress zstd and return uncompressed response to visitor with weak ETag header: `etag: W/"foobar"`. | Refer to [Content compression](/speed/optimization/content/compression/) for more information. ## Important remarks * You must set the value in a strong ETag header using double quotes (for example, `etag: "foobar"`). If you use an incorrect format, Cloudflare will remove the ETag header instead of converting it to a weak ETag.  * If a resource is cacheable and there is a cache miss, Cloudflare does not send ETag headers to the origin server. This is because Cloudflare requires the full response body to fill its cache. * If your origin (or R2) applies compression based on `accept-encoding`, the first compression type will be cached. Consider whether strong ETags fit your use case, or use cache key rules to handle different compression types. # Reference import { DirectoryListing } from "~/components" Review the reference content to learn more about specific caching functionality. # Range request behavior Cloudflare can serve HTTP range requests from complete or partial cached files. [Origin Range Requests](/cache/how-to/cache-rules/settings/#origin-range-requests) let Cloudflare fetch eligible files from your origin in cache-aligned byte ranges. ## Request eligibility Cloudflare uses the partial-file path only for a `GET` request that is eligible for caching when the request arrives. The origin response may later prove uncacheable. In that case, Cloudflare can still use origin range fetching, but does not store the response bytes. `HEAD` requests and other methods do not use this path. ### HEAD requests A `HEAD` request containing `Range` can return `200 OK`, `206 Partial Content`, `304 Not Modified`, or `416 Range Not Satisfiable`. A `HEAD` response never has a body. A `206 Partial Content` response includes `Content-Range`. When Cloudflare serves a complete cached file without Origin Range Requests, a matching `If-Range` validator can preserve a `206 Partial Content` response, while a mismatch returns `200 OK`. Cloudflare ignores `If-Range` for other `HEAD` request paths. ## Client response behavior ### Requests without Range A successful, unconditional `GET` without `Range` returns the complete file as `200 OK`. On a cold cache miss, the first origin request also omits `Range`. If only part of the file is cached, Cloudflare may request the missing bytes from the origin. The client still receives one complete `200 OK` response. ### One valid range The following requests return `206 Partial Content` when successful: - `Range: bytes=100-199` - `Range: bytes=100-` - `Range: bytes=-100` Cloudflare shortens an end position that exceeds the file size. A suffix range larger than the file returns the complete file as `206 Partial Content`. ### Unsatisfiable ranges Cloudflare returns `416 Range Not Satisfiable` for: - An empty range, such as `bytes=` - A zero-length suffix, such as `bytes=-0` - Inverted range bounds - A range starting at or beyond the end of the file - A range against an empty, uncompressed file - Overlapping or out-of-order ranges when Origin Range Requests applies A Cloudflare-generated `416 Range Not Satisfiable` response has an empty body. It includes `Content-Range: bytes */`. When Cloudflare serves a complete cached file without Origin Range Requests, it ignores overlapping or out-of-order ranges and normally returns the complete file as `200 OK`. ### Ignored Range headers Cloudflare processes the request as a non-range request when: - The range syntax cannot be parsed - The range unit is not `bytes` - A number is too large to parse - The header contains more than 300 ranges, or exactly 300 ranges when Cloudflare serves a complete cached file without Origin Range Requests This normally returns the complete file as `200 OK`. Conditional requests can return `304 Not Modified`, and origin errors still apply. ### Multiple ranges When Origin Range Requests applies, between two and 300 valid, ascending, non-overlapping ranges return a multipart `206 Partial Content` response. Cloudflare omits individual ranges that cannot be satisfied. The response remains multipart if only one range remains. If no ranges remain, Cloudflare returns `416 Range Not Satisfiable`. When Cloudflare serves a complete cached file without Origin Range Requests, one remaining satisfiable range produces a single-range `206 Partial Content` response. ### Conditional requests `If-None-Match` and `If-Modified-Since` take precedence over `Range`. They can produce a `304 Not Modified` response. Otherwise, an `If-Range` value that exactly matches the cached `ETag` or `Last-Modified` value preserves range behavior. A mismatch causes Cloudflare to ignore `Range` and use the complete-response path. ### Decompression If Cloudflare must decompress a complete encoded response, it ignores `Range`. Cloudflare sends the complete, uncompressed body as `200 OK`. This applies to cached responses and responses received from the origin. A range request for an empty, encoded response returns an empty `200 OK`, not `416 Range Not Satisfiable`. ## Origin request behavior Cloudflare aligns origin range requests to 1 MiB cache boundaries. For example, if a client requests a 1 KiB range, Cloudflare may fetch a 1 MiB range from your origin and return only the requested 1 KiB to the client. Cloudflare may also split one client request into several single-range origin requests. The `Range` values seen by your origin can differ from the client's header. Consider this behavior when configuring origin logs, request limits, rate limits, or request signing. Cloudflare adds `Accept-Encoding: identity` to every origin request generated by Origin Range Requests. This includes a complete-file `GET` handled by the feature. It does not disable normal compression between Cloudflare and the client. ### Partial response requirements For Cloudflare to cache an origin `206 Partial Content` response, the response must meet these requirements: | Response field | Requirement | | --- | --- | | `Content-Encoding` | The response must be unencoded. | | `Content-Range` | Include a concrete range. Its start must match Cloudflare's request. Its end must match the requested end or the end of the file, whichever comes first. Include the complete file size. | | `Content-Length` | Include a numeric value equal to the returned interval length. | | `Transfer-Encoding` | Omit this header. | | `ETag` | Optional. If present, its presence and exact value must remain consistent across responses for the same cached representation. | The complete file size must also remain consistent across responses. Violations can prevent caching or end responses served to the client early. ### Origin responses that do not honor Range If the origin ignores a Cloudflare-generated `Range` header and returns a complete `200 OK`, Cloudflare can use the response. Cloudflare must download the complete file and may then return the requested range to the client. If the origin returns an encoded `206 Partial Content` response, Cloudflare does not cache it. Before the client response starts, Cloudflare may send that single response without caching. After the response starts, Cloudflare ends it early, and the client receives fewer bytes than promised. Other incompatible origin responses during a response assembled from several requests can also end the client response early. ## Caching limitations Origin Range Requests do not make an otherwise ineligible request or response cacheable. Cloudflare checks the [maximum cacheable file size](/cache/concepts/default-cache-behavior/#cacheable-size-limits) against the complete size from `Content-Range`. Requesting a small range does not bypass this limit. Origin Range Requests are not supported with [Cache Reserve](/cache/advanced-configuration/cache-reserve/#limits). # Always Online Observe the following best practices when enabling Always Online with Internet Archive integration. - **Allow requests from the Internet Archive IP addresses.** Origin servers receive requests from the Internet Archive IPs. Make sure you are not blocking requests from the Internet Archive IP range: `207.241.224.0/20` and `208.70.24.0/21`. - **The Internet Archive does not consider your origin server's cache-control header.** When the Internet Archive is crawling sites, it will crawl sites regardless of their cache-control, since the Internet Archive does not cache assets, but archives them. - **Consider potential conflicts with Cloudflare features that transform URIs.** Always Online with Internet Archive integration may cause issues with Cache Rules and other Cloudflare features that transform URIs due to the way the Internet Archive crawls pages to archive. Specifically, some redirects that take place at the edge may cause the Internet Archive's crawler not to archive the target URL. Before enabling Origin Cache Control, review [how Cloudflare caches resources by default](/cache/concepts/default-cache-behavior/) as well as any Cache Rules you have configured so that you can avoid these issues. If you experience problems, disable Always Online. - **Do not block Known Bots or Verified Bots via a WAF custom rule.** If you block either of these bot lists, the Internet Archive will not be able to crawl. Do not use Always Online with: - API traffic. - An [IP Access rule](/waf/tools/ip-access-rules/) or a [WAF custom rule](/waf/custom-rules/) that blocks the United States or - Bypass Cache cache rules. Always Online ignores Bypass Cache cache rules and serves Always Online cached assets. ## Limitations There are limitations with the Always Online functionality: 1. Always Online is not immediately active for sites recently added due to: - DNS record propagation, which can take 24-72 hours - Always Online has not initially crawled the website 2. Cloudflare cannot show private content behind logins or handle form submission (POSTs) if your origin web server is offline. Always Online does not trigger for HTTP response codes such as [404](/support/troubleshooting/http-status-codes/4xx-client-error/error-404/), [503](/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-503/), or [500](/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-500/) errors such as database connection errors or internal server errors. This is because these status codes indicate the origin is reachable and responding — Always Online only activates when Cloudflare cannot connect to your origin at all (resulting in Cloudflare-generated [520–527](/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-520/) status codes). If your origin returns a 5xx error, the origin is online by definition and Always Online will not intervene. ## Frequently asked questions 1. How can I know if a page has been crawled? - You can go to the [Internet Archive](https://web.archive.org/) and search for the page URL to see if it has been crawled or not. - You can also check this via the [Internet Archive Availability API](https://archive.org/help/wayback_api.php). 2. Why were not pages x, y, and z crawled? - Since Cloudflare only requests to crawl the most popular pages on the site, it is possible that there will be missing pages. If you really want to archive a page, then you can visit the [Internet Archive](https://web.archive.org/save) save page and ask them to crawl a particular page. 3. What IP addresses do we need to allowlist to make sure crawling works? - IP Range: `207.241.224.0/20` and `208.70.24.0/21`. Note that this ip range belongs to Internet Archive and NOT Cloudflare, since it is the Internet Archive that does the crawling. 4. What user agent should the origin expect to see? - Currently the Internet Archive uses: `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/605.1.15 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/605.1.15`. # Bot Management cookie causes cache bypass in O2O setups In [Orange-to-Orange (O2O)](/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/how-it-works/) setups — where a SaaS provider uses [Cloudflare for SaaS](/cloudflare-for-platforms/cloudflare-for-saas/) and their customer also has their own Cloudflare zone — the `__cf_bm` Bot Management cookie returned from the origin-facing Cloudflare zone can cause the eyeball-facing zone to bypass cache. This occurs because the `Set-Cookie` header in the response triggers Cloudflare's default behavior of not caching responses with `Set-Cookie`. If you are seeing unexpectedly low cache hit rates in an O2O setup with Bot Management enabled, this may be the cause. # Dynamic content and login issues Dynamic pages such as login forms, checkout flows, and authenticated application routes can break when they are cached too aggressively. Common symptoms include: - Users can load the login page, but the sign-in form fails after submission. - Sessions do not persist after a successful sign-in. - The origin sends a `Set-Cookie` header, but the browser never stores the cookie. - A challenge page appears, but after solving it the user returns to the login page or loses form state. ## Cached login page strips session cookies One common cause is a [Cache Rule](/cache/how-to/cache-rules/) or legacy Page Rule configured to cache dynamic HTML. This usually happens when all of the following are true: - The page is configured as **Eligible for cache** or **Cache Everything**. - The response is dynamic HTML such as `/login` or `/account`. - The origin sends a `Set-Cookie` header. - An [Edge TTL](/cache/how-to/cache-rules/settings/#edge-ttl) or status-code TTL overrides origin cache directives. In this configuration, Cloudflare can cache the response and remove the `Set-Cookie` header before the response is stored at the edge. As a result, the browser receives the login page but never gets the session cookie required for the next request. ### How to confirm Check the response for the login page or other dynamic route. If you see both of the following, the page is probably cached when it should not be: - `CF-Cache-Status: HIT` or `CF-Cache-Status: EXPIRED` - No `Set-Cookie` header in the response, even though your origin usually sets one You may also see framework-specific failures after form submission, for example: - A redirect back to the login page - A `403` or `500` after sign-in - CSRF validation errors - Missing server-side session state This issue is common with frameworks that rely on a session or CSRF cookie on the first page load, including JavaServer Faces, ASP.NET, PHP session handlers, Django, Rails, and Laravel. ### Resolution Do not cache login pages or other authenticated HTML. Instead: 1. Restrict **Eligible for cache** or **Cache Everything** to static paths only. 2. Add a more specific Cache Rule that bypasses or disables caching for routes such as `/login`, `/account`, `/cart`, `/checkout`, and application API paths. 3. If the origin must control caching, remove any Edge TTL override that forces the page to be cached. 4. Verify the fixed response now returns `CF-Cache-Status: DYNAMIC`, `MISS`, or `BYPASS`, and preserves `Set-Cookie`. For more information on cookie behavior, refer to [Interaction of Set-Cookie response header with Cache](/cache/concepts/cache-behavior/#interaction-of-set-cookie-response-header-with-cache). ## Challenge loops on login or form flows Security challenges can also interrupt dynamic flows. Two common patterns are: - A challenge is triggered on the initial `GET` request for the login page. The user solves the challenge, but the application loses the original session or CSRF context. - A challenge is triggered on the `POST` request that submits the login form or other sensitive action. The browser may have to repeat the request after the challenge, which can break the original form submission. ### How to confirm Check whether a [WAF custom rule](/waf/custom-rules/), [managed rule](/waf/managed-rules/), or [rate limiting rule](/waf/rate-limiting-rules/) applies to the login path. If the issue only affects routes such as `/login`, `/signin`, `/checkout`, or `/api/auth/*`, and the application works when the challenge is disabled for those paths, the challenge is likely interrupting the flow. ### Resolution Use one of the following approaches: 1. Exclude the login or form submission path from the challenge rule. 2. Narrow the rule expression so it applies to suspicious traffic only. 3. If you must protect the route, use a less disruptive control on the page load and apply stronger actions elsewhere in the flow. When debugging, also verify that rules are not matching Cloudflare-generated paths such as `/cdn-cgi/*`. For more information on challenge-related behavior, refer to [Rules troubleshooting](/rules/reference/troubleshooting/) and [Cloudflare WAF troubleshooting](/waf/troubleshooting/). # edgeResponseBytes and cacheResponseBytes discrepancy In [HTTP request logs](/logs/logpush/logpush-job/datasets/zone/http_requests/), `cacheResponseBytes` reflects the uncompressed response size from cache or origin. `edgeResponseBytes` reflects the final compressed response size sent to the client. Because Cloudflare applies compression (gzip, Brotli) before delivering to the client, `edgeResponseBytes` is typically smaller than `cacheResponseBytes`. # Troubleshooting import { DirectoryListing } from "~/components" The following topics are useful for troubleshooting Cache issues. # Investigate latency on tiered requests Some requests for the same URL are slow while others are fast. If the slow requests have a `cf-cache-status` of `MISS` or `EXPIRED` and the fast requests have `HIT`, the difference may be explained by Tiered Cache: slow requests miss in the lower-tier data center and fetch through an upper-tier data center before reaching your origin. Fast requests are served directly from the lower-tier cache. This page describes how to use Log Explorer to confirm whether Tiered Cache is involved and how to collect the data needed before contacting Support. ## Confirm Tiered Cache routing with Log Explorer The [HTTP Requests](/logs/logpush/logpush-job/datasets/zone/http_requests/) dataset exposes fields that show whether a request was routed through an upper tier: - **`CacheTieredFill`**: `true` when the lower-tier data center fetched from an upper-tier data center for this request. - **`EdgeColoCode`**: the IATA airport code for the lower-tier data center that received the request. - **`UpperTierColoID`**: the internal ID of the upper-tier data center used for the fill. - **`CacheCacheStatus`**: the cache outcome (`HIT`, `MISS`, `EXPIRED`, `BYPASS`, and so on). - **`OriginResponseDurationMs`**: the total time from when the lower-tier sent a request upstream until it received the full response. When `CacheTieredFill` is `true`, this duration includes the upper-tier lookup, any transit to your origin (also includes Argo Smart Routing transit time, if enabled), origin processing, and the response back. It is a measure of correlation, not isolation of a specific network hop. ## Correlate slow requests with upper-tier usage To check whether the slow requests are the ones going through Tiered Cache: 1. Open [Log Explorer](/logs/) for the zone. 2. Filter by the affected URL or path and set a time window that includes both slow and fast samples. 3. Group by `CacheTieredFill` and compare `OriginResponseDurationMs` between the two groups. If requests where `CacheTieredFill` is `true` show significantly higher `OriginResponseDurationMs` than those where it is `false`, Tiered Cache routing is correlated with the slowness. 4. Note the `EdgeColoCode` values for the slow requests and the `UpperTierColoID` values. These identify which lower-tier and upper-tier pair is involved. :::note `OriginResponseDurationMs` captures total upstream response time across all hops. It does not isolate a specific segment, such as transit between the upper tier and your origin, and does not prove congestion on a particular path. Use it to establish whether Tiered Cache routing correlates with the slow samples before escalating. ::: ## What to bring to Support When you contact Cloudflare Support, include: - The zone ID and affected URL or path. - A Log Explorer export or screenshot showing slow samples (`CacheTieredFill: true`) and fast samples (`CacheTieredFill: false`), with `OriginResponseDurationMs`, `EdgeColoCode`, `UpperTierColoID`, and `CacheCacheStatus` visible. - The time window in UTC during which you observed the issue. Cloudflare Support and network engineering use this data to assess whether a routing change between the upper-tier data center and your origin is needed. ## Why turning off Tiered Cache does not fix the underlying cause Turning off Tiered Cache routes all cache misses from every lower-tier data center directly to your origin. If the underlying issue is a congested or slow path from a specific upper-tier data center to your origin, turning off Tiered Cache may redistribute traffic rather than resolve the congestion, and removes the cache-fill efficiency benefits for the rest of your traffic. If a specific upper-tier data center consistently produces high `OriginResponseDurationMs`, the appropriate fix is a routing or topology change. Consider: - **[Smart Tiered Cache](/cache/how-to/tiered-cache/#smart-tiered-cache)**: selects upper tiers using origin-latency data, which can route around a slow upper-tier-to-origin path automatically. - **[Custom Tiered Cache](/cache/how-to/tiered-cache/#custom-tiered-cache)**: lets you work with your account team to design a topology that avoids specific upper-tier data centers. ## Related resources - [Investigate uncached responses](/cache/troubleshooting/investigating-uncached-responses/) - [Tiered Cache](/cache/how-to/tiered-cache/) - [HTTP Requests log fields](/logs/logpush/logpush-job/datasets/zone/http_requests/) # Investigate uncached responses If a URL you expected to be cached is served from the origin every time, the `cf-cache-status` response header identifies which cache decision Cloudflare made. Fetch the URL, inspect the header, and follow the section that matches the value you see: - `DYNAMIC` — Cloudflare decided the request was not eligible for cache before it looked in the cache. Refer to [DYNAMIC — request not eligible for cache](#dynamic--request-not-eligible-for-cache). - `BYPASS` — Cloudflare was ready to cache the response, but the origin response or configuration prevented it. Refer to [BYPASS — origin response is not cacheable](#bypass--origin-response-is-not-cacheable). - `MISS` on multiple consecutive requests from the same client — the response is cacheable but keeps missing the cache. Refer to [Repeated MISS — cacheable but not in cache](#repeated-miss--cacheable-but-not-in-cache). For any other status, refer to [Cache responses](/cache/concepts/cache-responses/) for the full list. :::note Cloudflare returns `BYPASS` — not `MISS` — for responses it chooses not to cache. `MISS` is reserved for cacheable responses that were not in cache at request time. Refer to the [BYPASS status changelog](/changelog/post/2026-05-26-bypass-status-for-uncacheable-responses/) for context. ::: ## Before you start A recent [Purge Everything](/cache/how-to/purge-cache/purge-everything/), [purge by URL](/cache/how-to/purge-cache/purge-by-single-file/), [purge by prefix](/cache/how-to/purge-cache/purge_by_prefix/), [purge by tag](/cache/how-to/purge-cache/purge-by-tags/), or [purge by hostname](/cache/how-to/purge-cache/purge-by-hostname/) clears the cache. The next request in each data center repopulates cache and returns `MISS` before subsequent requests return `HIT`. If a purge ran recently, wait for the cache to repopulate before continuing. ## DYNAMIC — request not eligible for cache Cloudflare made the "do not cache" decision at request time, before looking in the cache. Common causes: - **The file extension is not in the [default cached file extensions](/cache/concepts/default-cache-behavior/#default-cached-file-extensions) list** — for example, `.html` or a JSON API response — and no rule enables caching for it. Add a [Cache Rule](/cache/how-to/cache-rules/) with **Eligible for cache** set to *Yes*. - **A rule instructs Cloudflare to bypass cache.** Check whether a Cache Rule with the [Bypass cache](/cache/how-to/cache-rules/settings/#bypass-cache) setting, or a legacy `Cache Level: Bypass` [Configuration Rule](/rules/configuration-rules/) or [Page Rule](/rules/page-rules/), matches the URL. Use [Rules simulator](/rules/simulator/) to confirm which rules apply. - **The request method is not `GET` or `HEAD`.** Cloudflare only caches these two methods. - **[Development Mode](/cache/reference/development-mode/) is enabled on the zone.** Development Mode suspends cache for three hours and returns `DYNAMIC` for every response. Once the request is eligible, subsequent responses reflect the response-time decision (`HIT`, `MISS`, `BYPASS`, and so on). ## BYPASS — origin response is not cacheable The request was eligible for cache, but the origin response or configuration prevented Cloudflare from storing it. Common causes: - **The response exceeds the [cacheable size limit](/cache/concepts/default-cache-behavior/#cacheable-size-limits) for your plan.** Split the object into smaller assets, or move to a plan with a higher limit. [R2](/r2/) is an origin storage alternative — it does not raise the CDN cacheable size limit. - **The origin returned `no-store` or bare `private` in a `Cloudflare-CDN-Cache-Control` or `CDN-Cache-Control` header.** Cloudflare evaluates these headers ahead of `Cache-Control`, in the precedence `Cloudflare-CDN-Cache-Control` > `CDN-Cache-Control` > `Cache-Control`. An origin returning `Cache-Control: public, max-age=3600` together with `CDN-Cache-Control: no-store` produces `BYPASS`. Cloudflare does not forward `Cloudflare-CDN-Cache-Control` to the client, so it is not visible in the response — if you see `BYPASS` without a `CDN-Cache-Control` header, check what the origin actually sent, or have the origin drop the header and retest. A [Cache Rule](/cache/how-to/cache-rules/) with an [Edge Cache TTL](/cache/how-to/cache-rules/settings/#edge-ttl) setting that ignores origin cache-control overrides both directives. Refer to [CDN-Cache-Control](/cache/concepts/cdn-cache-control/) for the precedence rules. - **`no-cache`, `max-age=0`, or `s-maxage=0` in `Cloudflare-CDN-Cache-Control` or `CDN-Cache-Control` do not produce `BYPASS`.** They produce `MISS` on the first request, then [`REVALIDATED`](/cache/concepts/cache-responses/#revalidated) or [`EXPIRED`](/cache/concepts/cache-responses/#expired) on subsequent requests. - **The origin returned `Cache-Control: no-store` or bare `private`.** These directives block caching in either [Origin Cache Control](/cache/concepts/cache-control/) mode by default. Two exceptions: `Cache-Control: private="
"` with field names remains cacheable — Cloudflare drops only the named headers. And a [Cache Rule](/cache/how-to/cache-rules/) with an Edge TTL that ignores origin cache-control (**Edge TTL → Ignore cache-control header and use this TTL** or **Status code TTL**) overrides both directives, so a response with `no-store` plus that Edge TTL setting is cached. - **The origin returned `Cache-Control: no-cache`, `max-age=0`, or `s-maxage=0`, and [Origin Cache Control](/cache/concepts/cache-control/) is disabled** (the default on Enterprise plans). With Origin Cache Control enabled (the default on Free, Pro, and Business plans), these directives cause Cloudflare to cache and revalidate the response instead, producing [`REVALIDATED`](/cache/concepts/cache-responses/#revalidated) or [`EXPIRED`](/cache/concepts/cache-responses/#expired). Refer to [Understand `no-store` and `no-cache` directives](/cache/concepts/cache-control/#understand-no-store-and-no-cache-directives) and the [Conditions](/cache/concepts/cache-control/#conditions) table. - **The origin returned a `Set-Cookie` header.** By default, Cloudflare does not cache responses that include `Set-Cookie`. To cache the response, use one of the following: - Set an explicit Edge TTL on a [Cache Rule](/cache/how-to/cache-rules/) using **Edge TTL → Ignore cache-control header and use this TTL** or **Status code TTL**. Cloudflare ignores the origin's directives, strips `Set-Cookie`, and caches the response. - Have the origin return `Cache-Control: private="Set-Cookie"` or `no-cache="Set-Cookie"`. Cloudflare drops the named header and caches the rest. - Strip `Set-Cookie` before the cache decision, using a [Response Header Modification Transform Rule](/rules/transform/response-header-modification/). - On Enterprise plans with [Origin Cache Control](/cache/concepts/cache-control/) disabled, Cloudflare strips `Set-Cookie` and caches the response under the default cache level. A `Cache Level: Cache Everything` [Page Rule](/rules/page-rules/) or a Cache Rule with **Eligible for cache** set to *Yes* — either without an explicit Edge TTL — overrides this and returns `BYPASS`. Refer to [Interaction of `Set-Cookie` response header with Cache](/cache/concepts/cache-behavior/#interaction-of-set-cookie-response-header-with-cache) for the full matrix. - **The origin returned `Vary: *`.** This value always bypasses cache, regardless of other configuration. - **The request included an `Authorization` header and [Origin Cache Control](/cache/concepts/cache-control/) is enabled** (the default on Free, Pro, and Business plans). In that mode, the response is cacheable only if `Cache-Control` also includes `public`, `s-maxage`, or `must-revalidate`. On Enterprise plans with Origin Cache Control disabled, `Authorization` does not by itself prevent caching. If [Tiered Cache](/cache/how-to/tiered-cache/) is enabled, an eligible request may be routed through an upper-tier data center before Cloudflare receives the origin response. Origin headers that produce `BYPASS` act after this upper-tier fetch has already happened, so they do not prevent it. To prevent requests from reaching the upper tier, use a request-time bypass rule — a [Cache Rule](/cache/how-to/cache-rules/settings/#bypass-cache) with **Bypass cache**, or a legacy `Cache Level: Bypass` [Configuration Rule](/rules/configuration-rules/) or [Page Rule](/rules/page-rules/). Refer to [BYPASS](/cache/concepts/cache-responses/#bypass) for the reference definition of this status. ## Repeated MISS — cacheable but not in cache `MISS` on the first request in each data center is expected — that request populates the cache. If the same URL keeps returning `MISS` across consecutive requests, one of the following is happening. ### Cache key variance Cloudflare builds the cache key from the origin scheme, host, path, and query string by default. Cookies, headers, and device type can also contribute when configured. The scheme in the cache key is the scheme Cloudflare uses to reach the origin, not the scheme the client used — a zone with a single origin scheme serves HTTP and HTTPS client requests from the same cache entry. If each real client request produces a different key, the cache never sees a repeat and every request is a `MISS`. Common patterns: - **Query parameters that change per request** — session IDs, timestamps, or marketing tags such as `utm_*`. By default, every unique query string is a separate cache entry. Configure [Cache Rules](/cache/how-to/cache-rules/) or [Cache Key Settings](/cache/how-to/cache-keys/#cache-key-settings) to exclude or ignore parameters whose value changes per request. Sorting only canonicalizes parameter order — use it when requests differ only in the order of parameters, not when the values differ. - **A [custom cache key](/cache/how-to/cache-keys/) includes a cookie or header with a value that changes per user.** The [Create custom cache keys](/cache/how-to/cache-keys/#create-custom-cache-keys) section warns that custom keys "may reduce your cache hit rate and result in cache sharding" — this is the same behavior. - **[Cache by device type](/cache/how-to/cache-rules/examples/cache-device-type/) classifies clients differently than expected**, particularly for bots or clients with unusual `User-Agent` values. - **[Vary in Cache Rules](/cache/how-to/cache-rules/settings/#vary) is configured** for a header, the origin lists that header in its `Vary` response header, and the action is `normalize` or `passthrough`. Each response variant is stored under a separate key. When the header has high cardinality — for example, an unnormalized `Accept-Language` value or a per-user header — the practical hit rate drops. The `bypass` action prevents caching entirely. Two identical requests produce the same cache key and cannot reveal variance. To diagnose, use [Rules simulator](/rules/simulator/) to see the applied cache-key configuration and Vary action for the URL, then compare that against the request attributes (query string, cookies, headers, device type) that differ between real client requests. ### Eviction and low-traffic assets Low-traffic assets can be evicted from the cache before the next request arrives. If two consecutive requests to the same URL from the same data center both return `MISS`, enable [Tiered Cache](/cache/how-to/tiered-cache/) or [Cache Reserve](/cache/advanced-configuration/cache-reserve/) to retain long-tail content longer. If your requests reach different Cloudflare data centers, each produces its own first-request `MISS`. Compare the data center code — the last three characters of the `cf-ray` header — to confirm two responses came from the same data center. Different client networks can still reach the same data center, so a network change does not guarantee a different location. ## Confirm the response reaches cache After adjusting configuration, request the URL twice from the same client and verify the expected outcome for your configuration: - **Fresh, positive Edge TTL:** `cf-cache-status: HIT` and an `Age` header that increases on subsequent requests. `Age` is absent on the first request that fills the local data center's cache from an upper tier via [Tiered Cache](/cache/how-to/tiered-cache/) — the `HIT` reflects the upper tier, but the local data center has not served it from cache yet. Subsequent requests include `Age`, and with Tiered Cache the value can already be large because it reflects the object's age in Cloudflare's network-wide cache. - **Origin returns `Cache-Control: no-cache` with [Origin Cache Control](/cache/concepts/cache-control/) enabled:** `cf-cache-status: REVALIDATED` when the origin confirms the cached copy is unchanged, or [`EXPIRED`](/cache/concepts/cache-responses/#expired) when the origin returns new content. Both indicate the response is cached. `must-revalidate` on its own does not force revalidation on every request — it only prevents serving stale content after the freshness TTL expires. If the response is still `MISS` or `BYPASS` after these checks, capture two full responses (request and response headers, including `cf-ray` values) and open a support case. The `cf-ray` values are required to trace the request through the Cloudflare network. ## Related resources - [Cache responses](/cache/concepts/cache-responses/) — reference for every `cf-cache-status` value. - [Default cache behavior](/cache/concepts/default-cache-behavior/) — when Cloudflare caches successfully by default. - [Cache Rules](/cache/how-to/cache-rules/) — configure Edge TTL, eligibility, and cache key. - [Cache Analytics](/cache/performance-review/cache-analytics/) — measure hit rate and identify low-performing URLs. ## Related resources - [Tiered Cache](/cache/how-to/tiered-cache/) - [Investigate latency on tiered requests](/cache/troubleshooting/investigating-tiered-cache-latency/) # Issues with MP4 videos on iOS and Safari import { DashButton } from "~/components"; When traffic is proxied through Cloudflare, Safari on macOS and iOS devices may fail to load MP4 video files. This issue occurs because Safari handles HTTP range requests differently than other browsers, particularly in how it processes ETags during video streaming. Safari and iOS devices rely on HTTP range requests to support video features such as seeking to specific timestamps and resuming interrupted downloads. When Cloudflare's caching layer processes these range requests with weak ETags, Safari may reject the cached response entirely, resulting in videos that fail to load or display as black screens. To resolve this issue, configure two cache rules in the following order. ## 1. Create the strong ETags rule Create a [cache rule](/cache/how-to/cache-rules/create-dashboard/) that applies to all MP4 files, marks them as eligible for cache, and turns on the Respect Strong ETags setting. 1. In the Cloudflare dashboard, go to the **Cache Rules** page. 2. Select **Create rule** > **Cache rules**. 3. Enter a descriptive name for the rule in **Rule name**. 4. In the **When incoming requests match…** section, create a filter that applies to all MP4 files, for example `URI Full` `Wildcard` `*.mp4`. 5. Select **Eligible for cache** in the **Cache eligibility** section. 6. Select **+ Add Setting** for **Respect strong ETags** and turn on the toggle. 7. Select **Last** as **Place at**. ## 2. Create the bypass cache rule Create another cache rule that applies to all MP4 files and bypasses cache entirely. 1. In the Cloudflare dashboard, go to the **Cache Rules** page. 2. Select **Create rule** > **Cache rules**. 3. Enter a descriptive name for the rule in **Rule name**. 4. In the **When incoming requests match…** section, create the same filter for MP4 files, for example `URI Full` `Wildcard` `*.mp4`. 5. Select **Bypass cache** in the **Cache eligibility** section. 6. Select **Last** as **Place at**. ## Why this order matters The first rule preserves strong ETags for MP4 files, which satisfies Safari's requirements for range request handling. The second rule bypasses cache so that Cloudflare forwards range requests to the origin server instead of serving cached responses with potentially mismatched ETags. The first rule must appear above the second rule in the Cache Rules list.