Cloudflare 配置 WordPress 全站缓存完整教程：Cache Rules 实现 HTML 页面加速

一、为什么要给 WordPress 配置 Cloudflare 全站缓存？

WordPress 是基于 PHP 和 MySQL 的动态内容管理系统。当访客访问网站首页、文章页或分类页面时，服务器通常需要执行以下操作：

1. Nginx 接收访客请求。
2. PHP-FPM 执行 WordPress 程序。
3. WordPress 加载主题、插件和相关配置。
4. WordPress 查询 MySQL 数据库。
5. PHP 生成 HTML 页面并返回给访客。

如果网站访问量较大，或者 VPS 配置较低，大量动态请求会持续占用 CPU、内存和 PHP-FPM 进程。

尤其是使用 2GB 内存 VPS 的 WordPress 网站，如果同时遭遇搜索引擎爬虫、恶意扫描程序或异常 PHP 请求，很容易出现 PHP-FPM 进程占满、网站响应缓慢甚至 502/504 错误。

Cloudflare 全站缓存的核心思路，就是让 Cloudflare 直接向访客返回已经生成的 HTML 页面，减少源站重复执行 PHP 和查询数据库的次数。

默认情况下，Cloudflare 主要缓存符合条件的静态资源，例如 CSS、JavaScript、图片和字体文件。HTML 页面通常不会自动进入 CDN 缓存。

因此，我们需要通过 Cloudflare 的 Cache Rules 配置页面缓存规则，让普通 WordPress 前台页面也能够进入 Cloudflare 边缘缓存。

配置完成后的访问流程

普通访问请求：

访客
  |
  v
Cloudflare CDN
  |
  | 缓存命中（HIT）
  v
直接返回 HTML 页面

首次访问或缓存过期：

访客
  |
  v
Cloudflare CDN
  |
  | 缓存未命中（MISS）
  v
Nginx + PHP-FPM
  |
  v
WordPress + MySQL
  |
  v
生成 HTML 页面
  |
  v
Cloudflare 缓存页面
  |
  v
返回给访客

当页面已经缓存后，后续符合缓存条件的访客可以直接从 Cloudflare 节点获取 HTML，不必每次都让源站执行 WordPress。

二、配置前需要准备什么？

本教程适用于以下环境：

项目	推荐环境
网站程序	WordPress
Web 服务器	Nginx
PHP	PHP-FPM
数据库	MySQL / MariaDB
CDN	Cloudflare
服务器	VPS / 云服务器
缓存方式	Cloudflare HTML 全站缓存
WordPress 缓存插件	非必需

开始配置前，请确认：

1. 域名已经接入 Cloudflare。
2. 网站 DNS 记录已经开启 Cloudflare 代理（橙色云朵）。
3. 网站可以通过 HTTPS 正常访问。
4. 网站主要展示公开内容，例如企业官网、博客、新闻资讯或产品介绍。
5. 网站没有需要向不同访客展示个性化内容的前台页面，或者已经明确排除这些页面。

特别提醒：全站 HTML 缓存不等于所有页面都可以无差别缓存。如果网站有会员中心、用户登录、购物车、订单、预约或个性化内容，必须针对这些功能设置缓存排除规则。

三、*步：进入 Cloudflare Cache Rules

登录 Cloudflare 后，选择需要配置的网站。

进入：

Caching → Cache Rules → Create rule

创建一条新的缓存规则。

建议规则名称：

WordPress - Full Page Cache

本教程采用一条规则完成主要配置：通过请求路径、查询参数和 Cookie 条件排除动态请求，其余符合条件的前台请求进入缓存。

这样可以避免多条规则相互覆盖造成的配置问题。

四、第二步：设置 WordPress 全站缓存规则

在创建规则页面中，找到：

When incoming requests match

选择：

Custom filter expression

将下面的表达式复制到编辑框中。

1. 完整缓存规则表达式

请将 example.com 替换为你自己的域名。

(http.host eq "example.com"
 and not starts_with(http.request.uri.path, "/wp-admin")
 and http.request.uri.path ne "/wp-login.php"
 and not starts_with(http.request.uri.path, "/wp-json")
 and http.request.uri.path ne "/wp-cron.php"
 and http.request.uri.path ne "/xmlrpc.php"
 and http.request.uri.path ne "/wp-comments-post.php"
 and http.request.uri.path ne "/wp-admin/admin-ajax.php"
 and http.request.uri.query eq ""
 and not (http.cookie contains "wordpress_logged_in")
 and not (http.cookie contains "wordpress_sec")
 and not (http.cookie contains "wp-postpass")
 and not (http.cookie contains "comment_author")
 and not (http.cookie contains "woocommerce_items_in_cart")
 and not (http.cookie contains "woocommerce_cart_hash")
 and not (http.cookie contains "wp_woocommerce_session"))

2. 为什么要排除这些请求？

排除条件	排除原因
/wp-admin	WordPress 后台属于动态管理页面
/wp-login.php	登录页面不能作为普通公共页面缓存
/wp-json	WordPress REST API 可能返回动态数据
/wp-cron.php	WordPress 定时任务入口
/xmlrpc.php	XML-RPC 接口，不需要作为普通页面缓存
/wp-comments-post.php	评论提交接口
/wp-admin/admin-ajax.php	WordPress AJAX 请求入口
URL 查询参数	排除搜索、预览及其他带参数的动态请求
wordpress_logged_in	登录用户 Cookie
wordpress_sec	WordPress 安全登录 Cookie
wp-postpass	受密码保护的文章
comment_author	评论用户相关 Cookie
WooCommerce Cookie	排除购物车及会话相关请求

这一步非常重要。

Cloudflare 全站缓存会缓存 HTML。如果不排除登录状态和动态请求，可能导致访客看到不属于自己的页面内容。

关于查询参数： 本教程为了降低配置风险，直接排除所有带查询字符串的请求。这意味着 ?s=keyword 搜索、文章预览等请求不会进入缓存。如果以后希望缓存某些带参数的公开页面，需要单独设计缓存策略，而不是直接删除这项限制。

3. 配置缓存资格

在规则下方找到：

Then → Cache eligibility

选择：

Eligible for cache

这表示符合上面表达式的请求可以进入 Cloudflare 缓存处理流程。

注意：Eligible for cache 并不代表所有响应一定会被缓存。源站响应头、Cookie 和其他缓存条件仍可能影响*终结果。

五、第三步：设置 HTML 页面缓存时间

继续在同一条 Cache Rule 中配置：

Edge TTL

选择：

Ignore cache-control header and use this TTL

然后设置：

1 hour

也就是缓存 1 小时。

为什么建议先设置 1 小时？

对于企业官网、博客和资讯网站，页面内容通常不会每分钟发生变化。

设置 1 小时有以下优点：

• 减少源站重复处理 HTML 请求。
• 降低 PHP-FPM 和 MySQL 的负载。
• 避免缓存过期时间过长导致内容更新不及时。
• 适合每周更新几篇文章的网站。

如果网站内容更新频率较低，也可以根据实际情况调整为 2 小时、4 小时或更长时间。

初次配置建议先使用 1 小时，确认缓存运行正常后再调整。

Browser TTL 设置

如果页面中还有 Browser TTL 选项，建议选择：

Respect origin

这样浏览器端仍然遵循源站响应头，不必强制让访客浏览器长期保存 HTML。

这里需要区分：

• Edge TTL： Cloudflare 边缘节点保存页面的时间。
• Browser TTL： 访客浏览器本地缓存资源的时间。

两者不是同一个概念。

完成设置后，点击：

Deploy

至此，Cloudflare 全站 HTML 缓存规则已经创建。

六、第四步：检查规则是否正确生效

规则部署后，不要只看网站能否正常打开，还需要验证 Cloudflare 是否真的缓存了 HTML。

可以使用浏览器开发者工具，也可以通过 SSH 命令检查。

方法一：使用 curl 命令

在终端执行：

curl -I https://example.com/

重点查看响应头：

CF-Cache-Status

*次访问通常可能返回：

CF-Cache-Status: MISS

这表示 Cloudflare 缓存中没有对应页面，需要向源站请求内容。

再次执行：

curl -I https://example.com/

如果规则和源站响应均允许缓存，可能返回：

CF-Cache-Status: HIT

<badge color=”success”>HIT</badge> 表示本次请求命中了 Cloudflare 缓存。

也可以检查其他响应头：

HTTP/2 200
content-type: text/html
cf-cache-status: HIT

注意：实际响应头可能包含其他字段，且不同节点的首次访问和缓存状态可能不同。

方法二：使用浏览器开发者工具

1. 打开网站首页。
2. 按 F12 打开开发者工具。
3. 进入 Network（网络）。
4. 刷新页面。
5. 点击网站首页对应的 Document 请求。
6. 查看 Response Headers（响应头）。
7. 找到 cf-cache-status。

如果看到：

cf-cache-status: HIT

说明当前请求已经命中 Cloudflare 缓存。

建议分别检查：

• 网站首页
• 普通文章页面
• 普通内容页面
• 分类归档页面

不要只验证首页。

七、第五步：WordPress 发布文章后如何清理缓存？

启用 HTML 缓存后，有一个需要特别注意的问题：

WordPress 发布新文章或修改旧文章后，Cloudflare 可能仍然向访客返回缓存中的旧页面。

例如：

• 发布了一篇新文章。
• 修改了首页内容。
• 更新了文章标题或正文。
• 修改了网站导航。
• 修改了某个产品页面。

这时就需要清理对应缓存。

方法一：手动清理 Cloudflare 缓存

登录 Cloudflare，进入：

Caching → Configuration → Purge Cache

可以选择：

• Purge by URL：清理指定页面。
• Purge Everything：清理整个网站的缓存。

例如，只修改了某篇文章，建议优先清理该文章 URL。

如果修改了首页，可以清理首页 URL。

如果进行了大量页面调整，可以考虑清理整个网站缓存。

需要注意，Purge Everything 会清空整个站点的 CDN 缓存，清理后大量首次访问会重新请求源站。因此，不建议每次发布文章都清理全部缓存。

方法二：通过 API 自动清理

如果希望 WordPress 每次发布文章后自动清理 Cloudflare 缓存，可以使用 Cloudflare API。

基本流程：

1. 在 Cloudflare 创建 API Token。
2. 授予对应 Zone 的缓存清理权限。
3. 获取网站 Zone ID。
4. 在 WordPress 中编写发布文章触发函数。
5. 通过 API 清理文章 URL、首页及相关归档页面。

Cloudflare API 的缓存清理接口：

POST https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/purge_cache

清理指定 URL 的请求示例：

curl "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/purge_cache" \
  -X POST \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "files": [
      "https://example.com/example-post/"
    ]
  }'

请注意：

• YOUR_ZONE_ID 替换为实际 Zone ID。
• YOUR_API_TOKEN 替换为 API Token。
• URL 必须使用网站实际的规范地址。
• API Token 不要放在前端 JavaScript 或公开代码中。

如果网站文章数量较多，后续还可以进一步实现自动清理文章 URL、首页和相关分类页面的机制。

八、常见问题与解决方案

1. 为什么 CF-Cache-Status 一直显示 DYNAMIC？

常见原因：

• 当前请求没有匹配缓存规则。
• 域名没有开启 Cloudflare 代理。
• 请求被其他 Cache Rule 设置为绕过缓存。
• Cloudflare 判断该请求不属于可缓存请求。

建议检查规则表达式、域名和缓存资格设置。

2. 为什么 CF-Cache-Status 显示 BYPASS？

BYPASS 通常表示请求原本符合缓存资格，但响应阶段存在不允许缓存的条件。

常见原因：

• 源站返回了 Cache-Control: private。
• 源站返回了 Cache-Control: no-store。
• 源站设置了 Cookie。
• 源站或插件明确要求不缓存。

检查响应头：

curl -I https://example.com/

重点查看：

Cache-Control
Set-Cookie
Vary
CF-Cache-Status

特别注意：如果源站或插件会为匿名访客动态设置 Cookie，不要简单地通过强制缓存忽略所有响应头来解决问题。应先确认 Cookie 是否包含个性化数据，再调整插件行为或缓存规则。

3. 为什么*次访问是 MISS，第二次还是 MISS？

可能原因：

• 页面响应包含 Set-Cookie。
• 源站响应头禁止缓存。
• 请求实际使用了不同的 Cookie 或缓存键。
• 页面有动态参数。
• 不同请求落在不同 Cloudflare 缓存节点。

可以先使用不携带登录 Cookie 的普通匿名请求进行测试，再检查源站响应头。

4. Cloudflare 全站缓存会不会影响 WordPress 后台？

正常配置下不会。

本教程已经排除了：

/wp-admin/
/wp-login.php
/wp-json/
/wp-cron.php
/xmlrpc.php

同时排除了登录 Cookie，因此正常后台管理请求不会进入公共页面缓存。

5. 是否还需要安装 WordPress 缓存插件？

不一定。

如果你的目标主要是降低源站 PHP 和 MySQL 的请求压力，那么 Cloudflare HTML 缓存已经可以承担重要的页面缓存工作。

但需要区分：

• Cloudflare：负责 CDN 边缘缓存。
• WordPress 缓存插件：可能负责生成静态页面、对象缓存或其他优化。
• Nginx FastCGI Cache：负责在源站 Web 服务器层缓存动态请求的响应。

三者可以组合使用，但不建议在没有明确缓存架构的情况下同时启用多套 HTML 缓存，以免出现缓存冲突和内容更新不及时的问题。

九、Cloudflare 全站缓存适合哪些 WordPress 网站？

网站类型	推荐程度	注意事项
企业官网	非常适合	主要是公开内容
WordPress 博客	非常适合	文章更新后清理相关缓存
新闻资讯网站	适合	注意首页和分类页更新
外贸 B2B 独立站	非常适合	产品页面通常适合缓存
WooCommerce 商城	需要谨慎	排除购物车、结账、账户和会话页面
会员网站	不建议直接全站缓存	必须排除会员及个性化页面
在线预约网站	需要谨慎	排除预约提交和实时可用性页面

十、总结：推荐的 WordPress + Cloudflare 缓存架构

对于普通企业官网、博客和外贸 B2B 网站，可以采用下面的架构：

访客
  |
  v
Cloudflare CDN
  |
  +---- HTML 页面缓存
  |
  +---- CSS / JS / 图片缓存
  |
  +---- 后台及动态请求绕过缓存
  |
  v
Nginx
  |
  v
PHP-FPM
  |
  v
WordPress
  |
  v
MySQL

对于配置较低的 VPS，尤其是只有 2GB 内存的服务器，优先让 Cloudflare 承担公开 HTML 页面缓存，可以有效减少重复动态请求，降低 PHP-FPM 和 MySQL 的工作压力。

*后强调：Cloudflare 全站缓存不能替代源站安全防护。恶意请求如果直接访问 VPS IP，仍可能绕过 Cloudflare。因此，还应结合 Nginx 请求限制、PHP-FPM 进程限制、防火墙以及源站 IP 访问控制进行保护。

推荐配置汇总：

配置项目	推荐值
缓存方式	Cloudflare Cache Rules
缓存内容	公共 HTML 页面
Edge TTL	1 小时
Browser TTL	Respect origin
WordPress 后台	Bypass
登录用户	Bypass
REST API	Bypass
查询参数	Bypass
WooCommerce 会话	Bypass
缓存清理	优先按 URL 清理

通过以上配置，就可以让 WordPress 普通前台页面进入 Cloudflare 边缘缓存，而将后台、登录和动态请求保留在源站处理。