---
canonical: https://meta.cyberforums.com/t/wp-rocket-5/2464
webpage: https://wpcy.com/community/t/2464-wp-rocket-5
language: zh-Hans
---

# WP Rocket 页面缓存未命中的 5 个常见原因及排查方法

> 文派叶子支持论坛的只读副本，本页不能回复。
> 讨论原文：https://meta.cyberforums.com/t/wp-rocket-5/2464
> 网页版：https://wpcy.com/community/t/2464-wp-rocket-5

## 1 · weixiaoduo

- 发布时间：2026年2月26日 16:23

背景
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

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

## 2 · system

- 发布时间：2026年2月26日 16:23

这是一篇关于单站点环境下 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 缓存策略

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

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