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

WordPress主机迁移怎样排除缓存造成的假象

迁移后看到旧页面、旧样式或旧IP，先不要判断迁移失败。最可能的情况是你看到的是某一层缓存的副本，而不是新主机上的真实结果。排除假象的核心方法是：用带随机参数的URL绕过页面缓存，用无缓存请求头绕过CDN，再直接查询新主机的源站响应，最后逐层对比。只有源站返回的内容才是迁移是否成功的可靠依据。

先分清迁移后可能存在的四层缓存

WordPress主机迁移后，一个请求可能经过多个缓存层，每层都可能返回旧内容：

• 浏览器缓存：本地保存的HTML、CSS、JS、图片，最容易被忽略。
• CDN或反向代理缓存：边缘节点保存的整页副本，常按URL缓存。
• 主机层缓存：新主机上的Nginx FastCGI Cache、Varnish、LiteSpeed Cache等。
• WordPress插件缓存：页面缓存、对象缓存、数据库查询缓存。

判断顺序应从最外层往最内层走：先排除浏览器，再排除CDN，再排除主机，最后排除WordPress插件。任何一层没排除，后面的结论都不可靠。

用无缓存请求直接看源站真实响应

这是最关键的一步。在命令行执行：

curl -I -H "Cache-Control: no-cache" -H "Pragma: no-cache" https://你的域名/

如果要绕过CDN直接访问新主机源站，把域名换成新主机的IP，并带上Host头：

curl -I -H "Host: 你的域名" http://新主机IP/

看返回头里的几个信号：

• X-Cache: HIT或cf-cache-status: HIT说明命中了CDN缓存，这条响应不能代表源站。
• X-Cache: MISS或BYPASS说明请求到了源站或回源了，可信度更高。
• 响应头里出现旧主机商的特征头，说明DNS或CDN还指向旧环境。
• 源站IP直接返回的页面内容，才是新主机实际输出的内容。

适用条件：你需要知道新主机的源站IP，并且源站允许直接访问。如果源站只允许CDN回源，就改用CDN提供的缓存刷新功能，再重复上面的curl检查。

用随机参数区分页面缓存和真实内容

在浏览器打开：

https://你的域名/?nocache=20240101a

每次换一个不同的随机值。如果带参数时显示新内容，不带参数时显示旧内容，说明页面缓存层在按URL缓存，问题出在缓存，不是迁移。如果带参数仍然显示旧内容，继续检查CDN和主机层缓存。

验收信号：同一页面在带随机参数和不带参数两种情况下返回一致的内容，且与源站curl结果一致，才算排除页面缓存假象。

检查数据库和对象缓存是否残留旧数据

页面缓存清掉后仍显示旧标题、旧菜单或旧小工具，可能是对象缓存或数据库里还存着旧值。检查项：

• WordPress后台是否启用了Redis或Memcached对象缓存，迁移后是否清空过。
• wp_options表中的siteurl和home是否已改为新域名。
• 是否残留旧主机的临时选项，例如重定向插件写入的规则。

多人协作时，建议在交付说明里写清楚：谁负责清CDN、谁负责清主机缓存、谁负责清WordPress插件缓存，以及每一步完成后用什么命令验证。这样能减少“我这边看是新的，你那边看是旧的”这类返工。

验收清单与判断结果

按顺序执行并记录结果：

1. 浏览器无痕窗口打开首页，仍显示旧内容则继续。
2. 带随机参数访问，显示新内容说明是页面缓存，去清对应缓存层。
3. curl源站IP，返回新内容说明迁移本身成功，问题只在缓存。
4. curl源站IP仍返回旧内容，检查新主机上的文件是否完整、数据库是否导入正确。
5. 所有层清理后，用同一URL在无痕窗口和普通窗口各访问一次，结果一致即通过。

判断结果：源站返回新内容、缓存层清理后前端一致，迁移才算真正完成。任何一层仍返回旧内容，都不能下迁移成功的结论。

下一步：把上面的curl命令和随机参数检查写成一份交付前的验证记录，每次迁移后由同一人执行并留档，避免多人协作时重复排查同一层缓存。