Cloudflare CDN 与缓存策略
开启橙色云朵后，用户请求会先到 Cloudflare 边缘节点。如果每次都回源站拉数据，CDN 的意义就没了。缓存策略决定哪些内容在边缘节点存多久、什么时候更新，是 CDN 加速效果的关键。这一篇讲 CDN 的工作原理、缓存规则、Tiered Cache、Page Rules 和 Configuration Rules 怎么用。
CDN 工作原理
CDN（Content Delivery Network，内容分发网络）的核心思路是把内容复制到离用户近的节点，用户访问时直接由近处节点返回，不再绕回源站。Cloudflare 的 CDN 工作流程可以拆成四步。
| 步骤 | 节点角色 | 行为 |
|---|---|---|
| 1 | 边缘节点 | 收到用户请求，查本地缓存 |
| 2 | 边缘节点 | 命中缓存则直接返回，未命中则向上层请求 |
| 3 | 上层或源站 | 返回内容，并附 Cache-Control 头 |
| 4 | 边缘节点 | 存一份缓存，再返回给用户 |
第二次再有用户访问同一资源时，边缘节点直接命中缓存返回，整个过程不经过源站。这就是 CDN 降低延迟、减轻源站压力的原理。
缓存什么内容
不是所有内容都该缓存。判断标准是这条内容对不同用户是否一样。
| 内容类型 | 是否缓存 | 原因 |
|---|---|---|
| 图片、CSS、JS | 是 | 对所有用户相同，缓存收益最大 |
| 字体、视频 | 是 | 大文件，缓存能省大量回源带宽 |
| HTML 首页 | 看场景 | 静态站可缓存，动态站不缓存 |
| API 响应 | 看场景 | 公共数据可缓存，用户私有数据不缓存 |
| Set-Cookie 响应 | 默认不缓存 | 含用户身份，不能给他人复用 |
默认行为下，Cloudflare 只缓存静态资源扩展名，例如 css、js、png、jpg、gif、webp、woff2 等。HTML 和 API 默认不缓存，除非主动配置规则。
缓存规则
Cache Rules 是当前主推的缓存配置方式，比旧的 Page Rules 更细粒度、更灵活。在域名的 Caching 分区进入 Cache Rules，可以新建规则。每条规则由匹配条件和动作两部分组成。
常见匹配条件如下。
| 匹配字段 | 示例 |
|---|---|
| URI 路径 | /assets/* |
| 文件扩展名 | jpg, png, webp |
| 主机名 | cdn.example.com |
| 请求头 | User-Agent 包含某关键词 |
| 查询参数 | ?version=2 |
动作部分可以指定是否缓存、缓存多久、是否绕过浏览器缓存等。
| 动作字段 | 作用 |
|---|---|
| Eligible for cache | 是否允许缓存这条响应 |
| Edge TTL | 边缘节点缓存时长，例如 1 天 |
| Browser TTL | 浏览器缓存时长 |
| Cache key | 自定义缓存键，例如忽略查询参数 |
一个典型场景是给某个路径下的图片缓存 30 天。匹配条件设为 URI 路径 /images/*，动作里 Eligible for cache 开启，Edge TTL 填 30 天。配置后，该路径下的图片首次回源后会在边缘节点保留 30 天，期间不再请求源站。
Tiered Cache
Cloudflare 在全球有 300 多个节点，如果每个节点未命中缓存都直接回源站，源站会承受大量重复请求。Tiered Cache（分层缓存）解决了这个问题。
它把节点分成层级。边缘节点未命中时，先去问上层节点，上层没有再问更上一层，最后才回源站。这样源站只接到少量请求，绝大部分回源在 Cloudflare 内部就消化掉了。
| 配置 | 说明 |
|---|---|
| Tiered Cache | 免费计划可用，开启即生效 |
| 分层结构 | 按地理区域划分上层节点 |
| 效果 | 回源请求减少 50% 以上 |
在 Caching 分区找到 Tiered Cache，开启即可，免费计划也支持。开启前后源站请求量对比通常很明显，热点资源的回源能减少一半以上。
Page Rules
Page Rules 是 Cloudflare 早期的配置方式，用一个 URL 匹配模式触发一组动作。它的缺点是一条规则只能匹配一个 URL 模式，且规则上限有限。官方建议新项目用 Cache Rules 和 Configuration Rules 替代，但 Page Rules 仍然可用。
| 项目 | Page Rules | Cache Rules / Configuration Rules |
|---|---|---|
| 配置维度 | 单个 URL 模式 | 多条件组合 |
| 规则上限 | 免费计划 3 条 | 免费计划 10 条起 |
| 灵活度 | 低 | 高 |
| 官方建议 | 逐步迁移 | 推荐使用 |
如果你的站点已有 Page Rules，可以保留，新需求优先用 Cache Rules。两边同时配置时，Cache Rules 的优先级高于 Page Rules。
Configuration Rules
Configuration Rules 是新一代的通用规则，用来按条件改写请求和响应的多种设置。它和 Cache Rules 的区别是定位不同，Cache Rules 专管缓存，Configuration Rules 管其他设置。
| 规则类型 | 控制范围 |
|---|---|
| Cache Rules | 是否缓存、缓存多久、缓存键 |
| Configuration Rules | TLS、自动 HTTPS、浏览器完整性检查等开关 |
| Page Rules | 旧版综合规则，逐步废弃 |
一个典型用法是给某个路径单独开启或关闭自动 HTTPS 跳转。匹配条件设为 URI 路径，动作里调整 Automatic HTTPS Rewrites 的开关。这种细粒度控制是 Page Rules 做不到的。
清除缓存
修改源站内容后，旧缓存可能还在边缘节点，用户看到的是旧版本。这时需要手动清缓存。Caching 分区的 Purge Cache 提供两种粒度。
| 清除方式 | 范围 | 适用场景 |
|---|---|---|
| Purge Everything | 全站所有缓存 | 大改版、紧急回滚 |
| Custom Purge | 按文件 URL 或主机名 | 单文件更新 |
日常更新单篇文章或一张图片，用 Custom Purge 输入对应 URL 即可，不必清全站。全站清缓存会让短时间内大量请求回源，源站压力骤增，慎用。
小结
CDN 的价值在于边缘缓存，缓存策略决定缓存命中率和源站压力。新规则系统 Cache Rules 和 Configuration Rules 比 Page Rules 更细粒度，是当前主推配置方式。Tiered Cache 免费可用，能显著降低回源量。下一篇进入另一个基础模块，HTTPS 加密模式。