WordPress 使用 Cloudflare 后，如何配置缓存规则（Cache Rules，免费版 10 条）

接入 Cloudflare 并点亮小云朵之后，网站就已经通过 Cloudflare 的节点中转。默认情况下，Cloudflare 会缓存图片、JS、CSS 等静态文件，但 HTML 页面默认不缓存 —— 访客打开页面时，请求仍然会回到你的源服务器。

这篇文章讲的是：如何用 Cloudflare 的 Cache Rules（缓存规则） 把 HTML 也缓存起来，让访客拿到的页面直接由 Cloudflare 提供，源站甚至收不到这个 GET 请求。好处是显著降低源站负载，让站点能承受更多访客与流量。

1、先认识一个词：HIT（命中）

判断一个页面有没有被 Cloudflare 缓存，最直接的办法是看响应头里的 cf-cache-status。用 Chrome 演示：

1. 打开已接入 Cloudflare 的网站页面
2. 按 F12 打开开发者工具，切到 Network（网络） 面板
3. 按 Ctrl + F5 强制刷新（macOS 用 Command + Shift + R）
4. 点开第一个文档请求（也就是网址本身），在 Response Headers 里找 cf-cache-status

看到 304 Not Modified 是正常的。它说明浏览器本地已经存了这份资源，这次只是向 Cloudflare 确认「内容没变」；真正判断有没有走 CDN，看的是响应头里的 Cf-Cache-Status —— 显示 HIT，就代表这一次的页面是由 Cloudflare 直接返回的，源站没有参与。

常见取值：

• HIT —— 命中，整页由 Cloudflare 直接提供
• MISS —— 未命中，Cloudflare 这次回源取了内容（首次访问通常是这样，之后就会变 HIT）
• EXPIRED —— 缓存过期，正在回源重新取
• REVALIDATED —— 回源确认内容没变，继续用缓存
• DYNAMIC —— 动态内容，按规则不缓存（只开了小云朵、没配缓存规则时，HTML 基本都是这个状态）
• BYPASS —— 明确绕过缓存

在 Cloudflare 后台的 Caching → Analytics（缓存分析） 里，也能看到过去 24 小时所有请求按「命中 / 未命中 / 动态 / 绕过」的分布。没配缓存规则时，绝大多数请求都会落在 动态。

2、缓存是怎么工作的

假设站点有两个页面：fshier.com/1.html 和 fshier.com/2.html。

访客 A 访问 1.html：请求先到 Cloudflare，缓存规则命中，Cloudflare 回源取到内容后既转发给 A，也存进自己的缓存。

访客 B 在缓存过期之前再访问 1.html：Cloudflare 发现缓存里有，直接把页面给 B，源站完全不知道 B 来过。

而 2.html 如果没人访问过，Cloudflare 并不知道它存在，自然也不会缓存 —— 直到第一个访客访问，它才会被存下来。这就是所谓「命中率」：越多人访问过的页面，越容易被完整命中。

3、重要变化：Page Rules 已迁移到 Cache Rules

老教程里教的是「页面规则（Page Rules）」，但现在 Cloudflare 已经把这类配置统一放到了 Caching → Cache Rules 下（左侧菜单「Caching」展开后就能看到），Page Rules 属于历史功能，新站点不建议再用。

几个必须知道的变化：

• 数量：Cache Rules 免费版 10 条（Pro 25 条、Business 50 条、Enterprise 300 条），不再是页面规则时代的 3 条。
• 行为差异：新建一条 Cache Rule 并选择 Eligible for cache 时，相当于默认开启了 Cache Everything；而页面规则时代需要额外勾选这个选项。
• 叠加与顺序：多条 Cache Rules 可以同时匹配并叠加生效，越靠后的规则优先级越高；页面规则时代是「先匹配先生效」，语义不同，迁移时最容易在这里出事。

Page Rules 现在还在菜单里，要不要管？

很多人会发现在左侧 Rules → Page Rules 里，页面规则仍然存在，旧规则还是「启用」状态 —— 这不是错觉，Cloudflare 并没有把入口拿掉，只是把缓存这块的能力迭代到了 Cache Rules。

两者不会打架。官方在 Cache Rules 执行顺序文档 里写得很明确：同一个路径上如果同时配了 Page Rules 和 Cache Rules，Cache Rules 优先。也就是说，旧页面规则里那些和缓存有关的设置（Cache Level、Cache Everything、Edge Cache TTL），现在实际上已经被 Cache Rules 盖掉了 —— 它们还显示「启用」，不代表还在左右缓存。

但 Page Rules 并非只剩缓存功能，它还能做这些缓存以外的事，而且仍然独立生效：

• 重定向（Forwarding URL）—— 对应的新产品是 Redirect Rules；
• Always Online、SSL、HSTS、Browser Cache TTL 等站点级设置 —— 对应 Configuration Rules 与 SSL/TLS 面板。

所以正确的处理方式是：

1. 不要新建 Page Rules —— Cloudflare 已把重心放到 Cache Rules，现在新建等于给自己留技术债；
2. 先逐条看旧规则在做什么，别直接删：只涉及缓存的（Cache Level / Cache Everything / Edge TTL），已被 Cache Rules 覆盖，可以关停后删除；涉及重定向或 Always Online / SSL 的，先迁到 Redirect Rules / Configuration Rules，再删；
3. 按官方推荐的顺序操作：关掉旧规则 → 验证行为 → 确认无误后再删除，不要一步到位。

还有一个容易迁移出错的细节：Page Rules 是「每个 URL 只触发第一条」，而 Cache Rules 是「多条叠加、越靠后越优先」。所以老规则的排序习惯不能照搬 —— 这也是下面「几个容易踩的坑」里特别提到的点。

举个真实例子：上图是一个老站点的 3 条页面规则 —— 第 1 条 *fshier.com/* 设了 Cache Everything，第 2、3 条分别对 /wp-admin* 和 /wp-login* 设 Bypass。这 3 条全部只涉及缓存，没有一个在做重定向或 SSL 之类的事，而对应的效果已经被 Cache Rules 里的兜底规则与后台/登录页规则完整覆盖 —— 所以它们可以安全删除。

顺带还能看到一个经典错误：把 *fshier.com/* 放在第 1 条。因为页面规则是「先匹配先生效」，这条通配规则会把所有请求都吃掉，后面两条 Bypass 其实从来没机会触发过 —— 真正该排第一的应该是更具体的例外规则，通配兜底放最后。迁移到 Cache Rules 时正好把这个顺序问题一并修正了。

所以下面推荐的结构是：一条兜底规则放在前面 + 若干例外规则放在后面。

4、实战：Cache Rules 的推荐配法

入口：Cloudflare 后台 → Caching → Cache Rules → Create rule。编辑器只有两部分：If incoming requests match…（条件）和 Then…（动作）。

规则 1｜兜底：让 HTML 也进缓存

• If：http.host equals fshier.com（只服务一个站就这样写；想全站生效可选 All incoming requests）
• Then → Cache eligibility：Eligible for cache
• Edge TTL：Use cache-control header if present, cache request with Cloudflare's default TTL for the response status if not（有 Cache-Control 就跟随源站，没有就按状态码用 CF 默认值）
• Browser TTL：Respect origin TTL（或按需覆盖）

效果：源站如果返回 Cache-Control: public, max-age=14400，Cloudflare 就会缓存 4 小时。

规则 2｜已登录用户和评论者一律不缓存

• If：Cookie contains wordpress_logged_in，或 Cookie contains comment_author
• Then → Cache eligibility：Bypass cache

这条非常关键。老教程教的是「去主题里关掉登录条」，其实那是因为整页缓存把登录状态也缓存下来了。正确做法是从缓存层就把登录态请求排除掉 —— 这样既保留了登录条，也不会把你的用户名、后台入口缓存给陌生人。

规则 3｜后台与动态 PHP 不缓存

• If 任一满足：URI Path contains /wp-admin/、/wp-login.php，或 URI Path contains .php
• Then → Bypass cache

把带 .php 的请求全部排除，是最省心的保险 —— 曾经确实出现过登录页被整页缓存、账号密码跟着一起被缓存的事故。

规则 4｜预览页不缓存

• If：Query String contains preview=true
• Then → Bypass cache

规则 5｜（可选）搜索页、REST、xmlrpc 不缓存

• If 任一满足：URI Path contains /wp-json/、/xmlrpc.php、/feed/，或 Query String contains s=
• Then → Bypass cache

站内搜索在 WordPress 里很吃数据库，属于最容易被拿来做 CC 的入口，不要让它的结果进缓存。

顺序与验证

1. 把兜底规则（规则 1）放最前，例外规则依次放后面 —— 因为越靠后优先级越高。
2. 改完用无痕窗口打开首页，看 cf-cache-status 应是 MISS，再刷一次变 HIT。
3. 登录 WordPress 后台后再访问前台，cf-cache-status 应该是 BYPASS（会看到登录条），这才是对的。

5、免费版能打的 CC 防护

Cloudflare 免费版并不是「只能挨打」—— 至少有三样东西可以直接用上。

① 速率限制（Rate Limiting）

路径：Security → Security rules → Rate limiting rules。免费额度足够配一条很实用的规则，例如：

• If：http.host eq "fshier.com"
• 计数特征：IP（还可以叠加 cf.colo.id）
• 当速率超过：60 次 / 10 秒
• 动作：Block，持续 10 秒

这个阈值对正常访客毫无影响（真人几乎不可能 10 秒打开 60 个页面），但对单 IP 的 CC 很有效。如果你的站访问量很低，甚至可以把阈值压得更小。

② 免费版自带的托管规则集

路径：Security → Settings，在 API abuse 分组下能看到 Cloudflare managed ruleset。

它是 Always active 的，不需要你配置，免费版也会覆盖三类攻击面：Web application exploits（Log4j、Shellshock、各类 WordPress 插件 CVE）、DDoS attacks、Bot traffic。看到它默认开着不用惊讶，这是免费版就带的。

③ 异常请求的挑战（Managed Challenge）

如果日志里发现某类请求明显异常（比如某个 UA、某个路径被反复扫描），可以在 Security → Security rules → Custom rules 里加一条规则，动作选 Managed Challenge（托管质询）。

比起整站开「5 秒盾」，这种按条件质询更精准，不会误伤正常用户和搜索引擎爬虫。

④ 被大规模攻击时：I'm Under Attack

路径：Security → Settings → Web application exploits → Security level，把安全级别临时改成 I'm Under Attack（我受到攻击）。

开启后 Cloudflare 会对所有访问者发起额外的 JavaScript 质询，验证通过才能访问，用于缓解第 7 层 DDoS。注意三点：

• 所有访客会先看到短暂的验证页面，会影响体验 —— 攻击缓解后要及时调回；
• 它对正常访客同样生效，不要长期开着；
• 可能影响 SSL 证书的 DCV 验证 —— 如果证书正处于 pending_validation 状态，先别开。

6、其他常用功能的新位置

7、几个容易踩的坑

• 缓存 HTML 之后，改内容要清缓存：发布新文章、改价格、改标题之后，最好清一次对应 URL 和首页；能写代码的话，用 API 在发布时自动清最省心。
• 别长期开着 Development Mode：它会让所有缓存绕过，看起来「怎么不生效了」，一下就白配了。
• 别把 Purge Everything 当日常操作：全清之后命中率归零，源站会被瞬间打满。
• 注意 www 与非 www：条件里用 http.host eq 时，别忘了 www 子域。
• Page Rules 时代的排序习惯不能照搬：Cache Rules 越靠后越优先，配置顺序反了就会出现「明明写了 bypass 还在缓存」。

按上面的结构配完，你的 WordPress 站就能做到：HTML 由 Cloudflare 缓存、静态资源照旧缓存、登录态与后台完全不受影响，源站负载会明显下降。

最后更新：2026-10-21，按 Cloudflare 新版界面（Cache Rules）重写；图示为作者自绘示意，非 Cloudflare 后台截图。