WordPress更换服务器源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /438a850bcd7a.html
📄
WordPress更换服务器源站正常而边缘节点异常时应保留哪些证据
先给有条件的结论：如果源站直连响应正常、而经过CDN或反向代理后出现异常，应优先保留“同一请求在两条路径上的成对证据”，而不是只截图边缘节点的报错页面。成对证据能把问题定位到边缘缓存、回源链路或节点本身；只留单边证据，事后几乎无法判断是源站输出变了，还是边缘节点没拿到或没更新。这个结论成立的前提是你能同时触发源站直连和边缘访问，且两者请求的是同一URL、同一方法、同一关键请求头。
为什么“边缘报错截图”单独保留几乎没有用
边缘节点返回5xx、旧页面或空内容时，截图只能证明“此刻这个节点这样返回”，无法说明源站当时返回了什么。WordPress更换服务器后，源站IP、回源Host、TLS证书或缓存键都可能变化，边缘节点报错可能来自：回源连不上新IP、回源Host写成了旧域名、证书校验失败、缓存仍指向旧内容、或节点自身故障。这些原因的修复动作完全不同，而截图对它们没有区分能力。
反例：如果源站直连也不稳定，只是你测试时恰好成功，那么“源站正常”这个前提就不成立，成对证据会误导你把问题全部推给边缘。判断前提是否可靠，需要在一段时间内多次直连采样，而不是一次成功就下结论。
应保留的第一组证据：同一请求的源站与边缘成对响应
对同一个URL，分别记录源站直连和边缘访问的响应，重点保留以下字段，而不是只看状态码：
- 请求的完整URL、HTTP方法、是否带查询串
- 响应状态码与响应体前若干字节（用于判断是否为空或旧内容）
- 响应头中的缓存相关字段、回源相关字段、时间戳字段
- 请求发出时间，两条路径尽量控制在同一分钟内
实际操作：用 curl -I 或浏览器开发者工具的“网络”面板，对源站直连地址和边缘域名各发一次相同请求，把两次的响应头完整复制保存。这个动作的结果直接决定下一步：如果边缘响应头里显示命中缓存而源站是新内容，下一步应查缓存刷新与缓存键；如果边缘响应头显示回源失败，下一步应查回源配置而非缓存。
应保留的第二组证据：回源链路的配置快照
边缘异常常出在“边缘怎么找到源站”这一步。需要保留的是当时的配置状态，而不是事后回忆：
- 边缘侧配置的回源地址与回源Host
- 回源使用的协议与端口
- 证书校验相关设置
- 缓存规则与缓存键的构成
这些配置在WordPress更换服务器时最容易被遗漏更新。保留快照的意义在于：当源站直连正常而边缘异常时，可以逐项比对回源Host是否仍指向旧域名、回源IP是否还是旧服务器。若配置快照显示回源地址未更新，下一步动作就是更新回源配置并重新触发一次成对请求验证，而不是先去翻WordPress插件。
应保留的第三组证据：时间线与变更记录
边缘节点异常有时是延迟生效造成的。需要保留一条带时间戳的变更线：
- 源站切换完成的时间
- DNS或回源配置修改的时间
- 第一次发现边缘异常的时间
- 每次缓存刷新或配置调整的时间及之后的表现
这条线能帮你区分“配置还没生效”和“配置本身错了”。如果异常出现在变更后很短的时间内，且成对证据显示边缘仍返回旧内容，更可能是缓存或传播延迟；如果过了较长时间仍异常，且回源配置快照显示地址正确，则应转向节点侧排查。注意，请求量或抓取量归零不能单独证明某次处理正确，它也可能只是采样窗口太短或访问路径改变。
什么情况下这套证据方法会失效
当边缘节点异常是间歇性的，单次成对采样可能正好落在正常窗口，得出“两边都正常”的错误结论。此时应改为定时多次采样，保留每次的时间戳与结果，用出现频率而非单次结果判断。另一个失效条件是：你无法控制请求头，边缘按不同请求头返回不同缓存版本，那么不成对的采样会互相矛盾。此时需要固定请求头后再采样。
下一步动作：先确认源站直连在多次采样下稳定，再补齐上述三组证据。若成对证据指向缓存，先刷新缓存并复测；若指向回源配置，先更新配置再复测。每一步调整后都重新采一次成对响应，用新的成对结果决定是否继续深入，而不是凭印象判断已经修好。
