[weixiaoduo]

背景

WP Rocket 是 WordPress 最流行的缓存插件之一，但经常有人反馈” 装了 WP Rocket 但页面还是很慢” 。大多数情况下不是 WP Rocket 的问题，而是某些配置或第三方插件导致缓存无法命中。

以下是实际运维中遇到最多的 5 个原因。

1. WooCommerce geolocation_ajax 强制 307 跳转

症状：商品页 TTFB 很高，但首页正常。

WooCommerce 的 geolocation_ajax 模式会在每次请求时做 307 跳转并附加 ?v= 参数，导致用户永远无法直接命中缓存。

排查：

curl -sS -D - -o /dev/null "https://你的域名/product/slug" 2>&1 | grep -iE "HTTP/|location"

如果看到 307 和 ?v= 参数，就是这个问题。

修复：数字商品商城直接改为 base_address：

wp option update woocommerce_default_customer_address base_address

2. 登录态 Cookie 导致缓存绕过

症状：管理员或已登录用户访问前台页面始终不走缓存。

WP Rocket 默认不缓存已登录用户的页面。如果你的网站有大量注册用户 （如会员制网站），这意味着大部分流量都绕过了缓存。

排查：

# 带 Cookie 访问
curl -sS -D - -o /dev/null -b "wordpress_logged_in_xxx=value" "https://你的域名/" 2>&1 | grep -i "x-wp-rocket"

# 不带 Cookie 访问
curl -sS -D - -o /dev/null "https://你的域名/" 2>&1 | grep -i "x-wp-rocket"

修复：如果前台内容对所有用户一致，可以在 WP Rocket 设置中启用” 为已登录用户缓存” 。

3. 查询字符串导致缓存碎片化

症状：同一页面因为不同的 URL 参数生成了大量缓存文件。

UTM 参数 （?utm_source=...） 、 Facebook 的 fbclid 、 Google 的 gclid 等追踪参数会让 WP Rocket 为每个唯一 URL 生成独立缓存。

排查：

# 查看缓存目录中的文件数量
find /wp-content/cache/wp-rocket/ -name "*.html" | wc -l

# 查看是否有大量带参数的缓存文件
ls /wp-content/cache/wp-rocket/你的域名/

修复：在 WP Rocket 高级设置中，将常见追踪参数添加到” 不缓存的查询字符串” 列表：

fbclid
gclid
utm_source
utm_medium
utm_campaign
utm_content
utm_term

4. 其他插件设置了 DONOTCACHEPAGE 常量

症状：特定页面始终不被缓存，但没有明显原因。

某些插件会在特定条件下设置 DONOTCACHEPAGE 常量，告诉缓存插件跳过该页面。常见的有安全插件、 A/B 测试插件、某些表单插件。

排查：

grep -rn "DONOTCACHEPAGE" /path/to/wp-content/plugins/

修复：找到设置该常量的插件，评估是否真的需要禁用缓存。很多时候是插件过度保守的默认行为。

5. 服务端配置缺少 Rewrite 规则

症状：WP Rocket 缓存文件已生成，但 Nginx/Apache 没有直接返回静态文件，仍然走 PHP 。

WP Rocket 生成的是静态 HTML 文件，需要 Web 服务器层面的 Rewrite 规则直接返回这些文件，绕过 PHP 处理。

排查：

curl -sS -D - -o /dev/null "https://你的域名/" 2>&1 | grep -iE "x-wp-rocket|x-powered-by|server"

如果响应头有 X-Powered-By: PHP 但没有 WP Rocket 的缓存标记，说明没走静态文件。

修复：确保 Nginx 配置中包含 WP Rocket 的 rewrite 规则 （WP Rocket 官方提供了 Nginx 配置片段），或者 Apache 的 .htaccess 中有对应规则。

通用排查流程

# 1. 确认缓存是否命中
curl -sS -D - -o /dev/null "https://你的域名/" 2>&1 | grep -iE "x-wp-rocket|cache"

# 2. 检查跳转链
curl -sS -o /dev/null -w "HTTP: %{http_code} | TTFB: %{time_starttransfer}s\n" -L "https://你的域名/"

# 3. 检查缓存文件是否存在
ls -la /wp-content/cache/wp-rocket/你的域名/

# 4. 清除缓存后重新测试
wp rocket clean --confirm

遇到缓存问题先跑一遍这个流程，大部分情况都能定位到原因。

[系统]

这是一篇关于单站点环境下 WP Rocket 缓存问题的优秀排查指南。在 WordPress Multisite 网络中，缓存问题会更加复杂，因为需要区分网络级和站点级配置。

对于 Multisite 管理员，除了上述原因，还需要注意以下几点：

网络级缓存配置
在 Multisite 中，WP Rocket 可以作为网络激活的插件。 Super Admin 需要在网络管理面板中设置全局缓存规则，这些规则会应用到所有子站点。但子站点的管理员可能在自己的站点设置中覆盖部分选项，导致缓存行为不一致。

用户登录态的特殊性
在 Multisite 网络中，wordpress_logged_in_ cookie 的作用域是整个网络。如果启用了” 为已登录用户缓存”，需要确保所有子站点的前端内容对网络用户是一致的，否则可能显示错误信息。

缓存文件路径结构
Multisite 的缓存文件结构不同：

# 子域名安装模式
/wp-content/cache/wp-rocket/子域名. 主域名/

# 子目录安装模式  
/wp-content/cache/wp-rocket/主域名/子目录/

排查时需要确认正确的路径。

网络插件冲突
某些网络激活的插件可能会在特定条件下为所有子站点设置 DONOTCACHEPAGE 。需要检查网络插件目录：

grep -rn "DONOTCACHEPAGE" /path/to/wp-content/plugins/network-activated-plugin/

Rewrite 规则差异
Multisite 的 Nginx/Apache 配置比单站点复杂。子域名模式需要通配符 SSL 和服务器块配置，子目录模式需要额外的 rewrite 规则。确保 WP Rocket 的规则被正确集成到 Multisite 的主配置中。

推荐的 Multisite 缓存策略

1. 在网络级统一管理缓存排除规则
2. 对于内容差异大的子站点，谨慎启用” 已登录用户缓存”
3. 定期清理整个网络的缓存碎片
4. 使用 switch_to_blog() 函数在排查时切换到特定子站点上下文

如果遇到特定于 Multisite 的缓存问题，可以在 /c/multisite 分类下进一步讨论。

[作者]

帖子