WordPress网站CDN缓存一直不生效的排查思路

在WordPress网站优化过程中，CDN缓存配置是提升访问速度的关键一环。然而，有时即使CDN的各项设置看起来都正确，缓存却始终不生效，这确实让人头疼。主题铺最近就遇到了这样一个棘手的问题，经过一番深入排查，终于找到了症结所在——PHP的session.cache_limiter设置。因为PHP的session.cache_limiter设置为nocache导致CDN一直不缓存，修改后即解决了本问题。那为什么这个参数会影响CDN缓存呢？

CDN不缓存之谜：session.cache_limiter 的幕后影响

为什么session.cache_limiter这个PHP设置会影响CDN缓存呢？其实，它直接控制着PHP在开启会话（Session）时，自动发送的HTTP响应头。这些头部信息，特别是Cache-Control，是浏览器和所有中间代理（包括CDN）判断一份内容是否缓存以及如何缓存的最高指令。

当CDN（比如我们常用的EdgeOne）的缓存策略设置为“遵循源站Cache-Control”时（这通常是很多CDN的默认或常见设置），源站PHP发送的这些“不缓存”指令，就会拥有对CDN的最高否决权。

🧠 核心原理：HTTP缓存控制头

要理解这一点，我们需要先了解几个关键的HTTP响应头：

• Cache-Control：这是现代Web缓存控制的核心指令。它的值有很多，比如public（允许缓存）、private（仅允许浏览器缓存）、no-cache（可缓存但必须向服务器验证）、no-store（绝对禁止任何缓存）、max-age=秒数（缓存有效期）。
• Pragma: no-cache：这是HTTP 1.0时代的遗留头，作用类似于Cache-Control: no-cache，主要为了兼容性而存在。
• Expires：指定一个绝对的过期时间。如果设置为过去的时间（如Thu, 19 Nov 1981 08:52:00 GMT），则表示内容已经过期。

⚙️ session.cache_limiter 各值及其发送的头部

PHP的session.cache_limiter配置，就是为你预先组合好了一套上述的头部指令。下表清晰地展示了不同设置的行为：

🔗 如何作用于主题铺遇到的案例

回顾我们遇到的问题，排查链条是这样的：

1. 默认设置：我们的php.ini中session.cache_limiter = nocache。
2. 自动发头：每当用户访问一个启用了Session的WordPress页面（几乎所有页面），PHP在输出内容前，都会自动、强制地加上Cache-Control: no-cache, max-age=0等头部。
3. CDN遵从：我们EdgeOne的初始设置是“遵循源站Cache-Control”。当它从服务器收到这些头部指令时，即使在CDN端配置了缓存规则，也必须遵守这个更高级别的“不缓存”指令。
4. 导致结果：所有动态页面都无法被CDN缓存，EO-Cache-Status始终为MISS。我们后来在EdgeOne、.htaccess中设置的所有缓存时间，都是在和这个源头指令“对抗”，自然无效。

✅ 解决方案的验证

这就是为什么当我们把php.ini中的session.cache_limiter设置为none并重启PHP服务后，问题就迎刃而解了：

• session.cache_limiter = none告诉PHP：不要自动发送任何缓存限制头。
• 这样，缓存的控制权就完全交还给我们，由我们在WordPress（通过插件或代码）、服务器配置（.htaccess）或CDN规则中精确、主动地设置。我们为未登录用户设置的Cache-Control: public, max-age=604800指令才得以生效。

💡 如何验证和调试

如果你以后怀疑遇到类似的问题，可以尝试以下方法：

1. 使用curl -I [你的网址]命令查看响应头，重点关注Cache-Control、Pragma、Expires这几个字段。
2. 检查php.ini中的session.cache_limiter设置。
3. 创建一个最简单的PHP测试文件test.php，内容仅为<?php session_start(); ?>，访问它并查看响应头。这样可以纯粹地看到session.cache_limiter的效果。

简单来说，session.cache_limiter是PHP在会话层面一个“简单粗暴”的缓存开关。对于需要精细控制缓存的现代网站（尤其是使用了CDN的），将其设为none并把控制权拿到自己手里，是最佳实践。通过修复这个问题，主题铺正好实践了这一点，也希望能为遇到类似困扰的朋友提供一个有效的排查思路。