CF-Cache-Status 标头输出指示资源是否已缓存。要调查此标头返回的缓存响应，请使用 Redbot ↗、webpagetest.org ↗ 或 Cloudflare Optics 插件 ↗等可视化工具。
以下是对 Cloudflare 缓存响应状态的全面说明。
在 Cloudflare 缓存中找到资源。
在 Cloudflare 缓存中未找到资源，从源站 Web 服务器提供。
Cloudflare 生成了表示资源不符合缓存条件的响应。这可能是因为：
-
Worker 生成响应而未发送任何子请求。在这种情况下，响应不是来自缓存，因此缓存状态为
none/unknown。 -
Worker 请求发出子请求（
fetch）。在这种情况下，子请求会记录缓存状态，而主请求记录为none/unknown状态（主请求未命中缓存，因为 Workers 位于 cache 之前）。 -
WAF 自定义规则被触发以阻止请求。响应来自 Cloudflare 全球网络，在到达 cache 之前。由于没有缓存状态，Cloudflare 记录为
none/unknown。 -
重定向规则或 Always Use HTTPS 导致全球网络响应重定向到另一个资源/URL。此重定向响应在请求到达 cache 之前发生，因此缓存状态为
none/unknown。
在 Cloudflare 缓存中找到资源但已过期，从源站 Web 服务器提供。
从 Cloudflare 缓存提供资源但已过期。Cloudflare 无法联系源站 Web 服务器获取更新的资源。
Cloudflare 在请求时认为资源符合缓存条件——要么因为它匹配默认缓存的文件扩展名，要么因为 Cache Rule 为其启用了缓存——但源站响应最终不可缓存。
源站响应被视为不可缓存的常见原因包括：
- 源站 Web 服务器返回设置为
no-cache、no-store或private的Cache-Control标头。源站Cache-Control指令仅在启用 Origin Cache Control 时生效，特定指令可能导致不同的缓存状态（例如，启用 Origin Cache Control 时max-age=0会缓存并重新验证）。有关完整行为，请参阅 Conditions。 - 源站 Web 服务器返回
Set-Cookie标头。 - 对源站 Web 服务器的请求包含
Authorization标头（在某些情况下）。
BYPASS 表示不缓存的决定是在响应时做出的——请求最初符合缓存条件，但源站响应或响应标头指示 Cloudflare 不要缓存。例如，设置 "cache": true 的 Cache Rule 在请求时启用缓存，但如果源站返回 Cache-Control: no-store，响应将为 BYPASS。
源站通过条件请求（If-Modified-Since 或 If-None-Match）确认缓存资源未更改，响应从 Cloudflare 缓存提供。此状态反映同步验证路径——请求在提供之前等待源站响应。
使用异步 stale-while-revalidate 时，大多数重新验证现在返回 UPDATING 或 HIT。在以下情况下会看到 REVALIDATED：未设置 stale-while-revalidate；或 must-revalidate 或 no-cache（启用 Origin Cache Control 时）等指令阻止提供 stale 内容。
资源已过期但从 Cloudflare 缓存提供，同时源站在后台更新它。UPDATING 是异步 stale-while-revalidate 重新验证期间的预期状态——重新验证窗口内的所有请求接收 UPDATING 或 HIT，而非等待源站。
Cloudflare 在请求时确定资源不符合缓存条件，因此请求直接前往源站 Web 服务器，未进行缓存查找。
这通常发生在：
- 请求的资源不是默认缓存的文件扩展名之一（例如 HTML 或 JSON），且没有规则指示 Cloudflare 缓存它。
- 具有 Bypass cache 设置的 Cache Rule 匹配请求。Configuration Rules 或 Page Rules 中的旧版
Cache Level: Bypass选项行为相同。
使用 Cache Rules 更改 Cloudflare 缓存的内容。一旦请求被视为符合缓存条件，CF-Cache-Status 标头将反映响应时的缓存决定（HIT、MISS、EXPIRED、REVALIDATED、BYPASS 等）——有关源站响应最终不可缓存的情况，请参阅 BYPASS。