📍 WDQWDWQD987AAAAA:216.73.216.70
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e7adce64f63b.html
📄

WordPress更换服务器，怎样排除缓存造成的假象

要排除缓存造成的假象，核心做法是让“你看到的页面”和“服务器实际返回的内容”分开验证：先绕过浏览器、CDN、插件和本机DNS缓存，直接向新服务器的源站发请求，再逐层恢复缓存对比结果。如果只有开启某一层缓存后页面才变旧，问题就在那一层，而不是迁移本身失败。

先区分四种缓存，别混在一起排查

WordPress更换服务器后出现的“没生效”“样式错乱”“还是旧内容”，可能来自四个不同位置，处理方式完全不同：

• 浏览器缓存：本机保存的旧HTML、CSS、JS。换设备或无痕窗口访问即可初步判断。
• 页面缓存插件：在WordPress内部生成静态HTML。清插件缓存后重新生成。
• CDN或反向代理缓存：边缘节点保存的副本。需要在CDN侧刷新，而不是只清WordPress。
• DNS与本地解析缓存：域名仍指向旧IP。用公共DNS查询工具核对当前解析结果。

这四层里任何一层没清，都会制造“迁移失败”的假象。判断顺序建议从最外层往内：先确认DNS解析到新IP，再绕过CDN直连源站，最后才看浏览器和插件。

一个假设例子：清完插件缓存页面还是旧的

假设你把WordPress从A服务器迁到B服务器，已经导入数据库、改好wp-config.php，后台也能登录。前台首页却仍显示旧文章，你清了页面缓存插件，刷新后还是旧内容。这时按下面步骤走：

1. 用无痕窗口打开首页，仍旧。说明不是单纯浏览器缓存。
2. 查询域名当前解析IP，若仍指向A服务器，问题在DNS，不在缓存插件。
3. 若解析已指向B服务器，但站点套了CDN，则用带随机参数的URL访问，例如 https://example.com/?nocache=20240101，绕开部分边缘缓存看源站返回什么。
4. 若带参数后是新内容，说明源站正常，假象来自CDN缓存，应在CDN控制台做刷新。
5. 若带参数后仍是旧内容，再停用页面缓存插件，直接访问。若此时变新，问题在插件缓存生成规则或对象缓存。

常见错误是：一发现页面旧就反复清浏览器缓存，却忽略了CDN和DNS；或者只清插件缓存，却没有让缓存重新生成。另一个错误是迁移后立刻开启所有缓存，导致旧副本被重新固化，反而更难判断。

用响应头判断内容来自哪一层

比起反复刷新页面，查看HTTP响应头更可靠。用浏览器开发者工具的“网络”面板或命令行工具请求首页，重点看这些字段：

• cache-control、expires：告诉浏览器和中间层能缓存多久。
• age：数值大于0通常表示命中了中间缓存。
• x-cache、cf-cache-status、x-cache-status等：不同CDN或代理自定义的命中标识，字段名因服务而异，需要按实际响应判断。
• server：可辅助判断请求落在哪台服务器或哪类代理上。

如果同一URL多次请求，age持续增大而内容不变，基本可以判定命中了中间缓存。此时清浏览器缓存没有意义。

时间有限时，最先做这三件事

人手和时间都紧张时，不要全面排查，按影响面排序：

1. 核对DNS解析：确认域名已指向新服务器IP。这一步不做，后面全是白费。
2. 直连源站验证：临时用hosts指向新IP，或通过服务器IP加Host头请求，确认新服务器本身返回正确内容。
3. 刷新CDN并清插件缓存：确认源站无误后，再刷新CDN、清WordPress缓存插件，最后才处理浏览器缓存。

这个顺序的逻辑是：源站正确是前提，缓存只是副本。源站不对，清多少层缓存都没用；源站对了，再逐层放行缓存即可。

验证完成的标准与下一步

判断缓存假象是否排除，可以看三点：无痕窗口、直连源站、带随机参数访问，三者返回内容一致；响应头中不再出现异常大的age；不同网络环境下访问结果相同。满足这些，说明当前看到的页面基本反映服务器真实状态。

下一步建议在迁移完成后先保持缓存关闭或短时间缓存，确认前台、后台、固定链接、图片和表单都正常，再逐层开启浏览器缓存、插件缓存和CDN，每开一层就复测一次。这样一旦再出现旧内容，你能立刻知道是哪一层引入的。