07 · 用白名单思维配置 Cache Rules
先识别身份与写路径，再只允许明确的公开资源进入缓存，并用规则顺序、Trace 与双客户端验证正确性。
编辑与核验：橙宝书编辑团队 ·
完成结果
你会得到一组范围清晰、顺序可解释的规则：指纹静态资源可长缓存，选定的公开内容可短缓存，而登录、账号、管理、预览、支付、Webhook 与写请求不会进入共享缓存。
从内容矩阵开始，不从 Cache Everything 开始
| 内容类别 | 典型路径 | 初始策略 | 发布证据 |
|---|---|---|---|
| 指纹静态资源 | /assets/app.abc123.js | Eligible，遵循源站头或长 TTL | MISS → HIT，版本 URL 可切换 |
| 公开内容 | /blog/*、/docs/* | 仅明确路径 Eligible，短 TTL 起步 | 匿名客户端内容一致，可精准刷新 |
| 身份页面 | /login、/account/* | Bypass | Cookie、CSRF、登录退出完整 |
| 写接口 | 非 GET/HEAD、/api/private/* | Bypass | 请求始终到应用，响应不串用户 |
| 管理与预览 | /admin/*、/preview/* | Bypass | 草稿与管理数据不会匿名命中 |
| 支付与回调 | /checkout/*、/webhooks/* | Bypass | 签名、幂等和状态更新不受缓存影响 |
Cache Rules 只作用于 Proxied 主机名。Eligible for cache 表示允许 Cloudflare 尝试缓存，并不保证响应一定存储；源站的 Cache-Control、Set-Cookie、状态码和其他设置仍参与判断。
规则可以叠加，冲突时最后匹配项胜出
flowchart TD
A[请求进入 Cache Rules 阶段] --> B[规则按顺序匹配]
B --> C{多个规则命中?}
C -- 否 --> D[应用唯一匹配结果]
C -- 是 --> E[不同设置可组合]
E --> F[同一设置冲突时最后匹配规则胜出]
F --> G[用 Cloudflare Trace 确认实际结果]最稳妥的设计是让公开与敏感条件尽量互斥。确实有重叠时，把宽泛的公开 Eligible 规则放在前面，把更具体的敏感 Bypass 放在后面，使最后匹配结果保持绕过。规则移动后必须重新跑 Trace，因为 Cache Rules 会覆盖相同路径上的旧 Page Rules 缓存设置。
在控制台创建最小策略
保存路径与响应头清单
从路由表、前端 Network、服务端日志和站点地图列出公开、身份、写入、预览和静态资源。不要让 AI 仅根据文件名猜路径性质。
建立公开静态资源规则
在目标 Zone 的 Caching → Cache Rules 选择 Create rule。使用 Hostname 与 URI Path 或 File extension 将范围限制在已确认的静态目录，选择 Eligible for cache。第一版尊重源站缓存头，不要同时改缓存键、查询参数和全部状态码 TTL。
建立敏感绕过规则
为身份、账号、支付、管理、预览、私有 API 和写请求建立 Bypass cache。若它可能与公开规则同时匹配，将其放在后面；更好的做法是在公开规则中排除这些路径，让意图不依赖隐藏顺序。
保存草稿并用 Trace 检查
控制台允许先保存 Draft。对首页、静态资源、登录页、账号页、公开 API 与一个写接口分别使用 Cloudflare Trace，记录命中的规则、最终 Cache eligibility 与规则顺序，再部署到测试主机名。
用匿名与两个账号验证
curl -sS -D - -o /dev/null https://www.example.com/assets/app.abc123.js
curl -sS -D - -o /dev/null https://www.example.com/login命令只负责无 Cookie 基线。浏览器还要使用匿名会话和两个独立测试账号，验证登录、退出、账号页、表单提交与 CSRF；账号 A 不能看到账号 B 的任何内容。
Bypass 可能显示 DYNAMIC
自定义 Bypass 规则会让请求在请求阶段变为不具备缓存资格，因此响应头可能是 CF-Cache-Status: DYNAMIC，而不是字面上的 BYPASS。以 Trace、规则命中和完整响应头共同判断。
发布门禁
- 新规则只覆盖列入矩阵的 Hostname 与 URI 范围。
- 多规则同时匹配时，已确认最后匹配规则不会把敏感路径重新设为 Eligible。
- 静态资源出现可解释的
MISS → HIT，身份与写路径保持DYNAMIC或BYPASS。 - 两个账号分别完成登录、退出、查看与写操作，没有 Cookie、CSRF 或跨用户数据问题。
- 回滚动作是停用本次规则，而不是删除源站安全头或执行全站清缓存。
已有站点可同时参考更短的登录与 API 安全配方。下一篇将拆开 Edge TTL、Browser TTL 与响应头。
官方来源
这篇内容帮你完成目标了吗？
内测反馈只在当前浏览器生成，不会自动上传。