排障
排障：为什么 CF-Cache-Status 不是 HIT
从响应头出发区分 DYNAMIC、BYPASS、MISS，并用只读步骤定位缓存问题。
编辑与核验：橙宝书编辑团队 ·
TROUBLESHOOTING · 只读优先症状 → 证据 → 修复核验：2026-08-26
症状
你预期资源被缓存，但响应头反复不是 CF-Cache-Status: HIT。先不要清全站缓存或修改生产规则。
第一步：保留原始证据
curl -sS -D - -o /dev/null https://example.com/assets/app.css记录状态码、CF-Cache-Status、Cache-Control、Set-Cookie、Age 和请求 URL。对同一 URL 连续请求两次，不要在两次之间改配置。
第二步：按状态分流
Cloudflare 在查缓存之前判定该响应不具备缓存资格。先检查资源类型、Cache Rule 与 Development Mode。
请求原本可以进入缓存判断，但源站响应或规则阻止缓存。检查 Cache-Control、Set-Cookie 与绕过规则。
响应具备缓存资格，但当次未找到对象。相同客户端连续 MISS 才值得继续调查填充、逐出或缓存键。
响应可能由 Worker、WAF 或重定向在缓存之外生成；先确定哪个组件直接产生了响应。
不要只看 Age
Age 在某些缓存状态出现，但源站也可能发送自己的 Age。先用 CF-Cache-Status 判断路径，再把 Age 当辅助证据。
第三步：最小修复
| 证据 | 先做的最小动作 | 不要先做 |
|---|---|---|
DYNAMIC | 核对目标 URL 是否应缓存，以及 Cache Rule 是否匹配 | 盲目 Purge Everything |
BYPASS + Set-Cookie | 确认 Cookie 是否必要，并检查源站响应 | 直接删除所有 Cookie |
BYPASS + private/no-store | 与数据所有者确认隐私和新鲜度要求 | 强制缓存私人内容 |
连续 MISS | 固定 URL、客户端与缓存键条件后复测 | 同时改多个规则 |
验证修复
重复完全相同的只读请求，比较修复前后的完整响应头。只有目标公共资源稳定出现预期状态，并且没有越过隐私或鉴权边界，修复才算完成。
防止复发
- 为关键资源保留一条可重复的 header 检查。
- Cache Rule 变更一次只改一个条件，并记录变更前后证据。
- 私有响应、鉴权响应和健康检查默认不要为追求
HIT而强行缓存。
准备修改规则时先看不破坏登录与 API 的 Cache Rules 配方，再返回请求链路架构。
官方来源
这篇内容帮你完成目标了吗？
内测反馈只在当前浏览器生成，不会自动上传。