同ip网站查询，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /70fd8da02c9d.html
📄
同ip网站查询，源站正常而边缘节点异常时应保留哪些证据
先给结论：同ip网站查询只能确认“解析结果指向哪些地址”，不能直接证明源站与边缘节点的健康差异。当源站回源正常、边缘节点却返回错误或旧内容时，应保留能区分“源站内容、回源链路、边缘缓存、客户端所见”四层状态的证据。至少包括：带时间戳的源站直连响应、边缘节点响应头、缓存命中状态、请求URL与Host、以及同IP下其他站点的对照结果。缺少其中任何一层，后续判断都可能被误导。
先分清源站正常与边缘节点异常是两件事
源站正常，通常指直接访问源站IP或回源地址时，返回的状态码、响应体和关键响应头符合预期。边缘节点异常，则指用户或测试点经过CDN、反向代理、负载均衡后拿到的结果与源站不一致。两者可以同时成立，因为边缘节点可能缓存了旧版本、回源失败后返回了旧缓存，或对特定Host、路径、查询串做了错误分流。
同ip网站查询在这里的作用是缩小范围：如果多个域名解析到同一组边缘IP，而只有其中一个域名异常，问题更可能在域名配置、Host校验或该域名的缓存规则；如果同IP下多个域名同时异常，则更可能是边缘节点、回源链路或共享配置的问题。这个判断只是缩小范围，不是定责。
需要保留的证据清单
证据要能回答三个问题：源站当时返回了什么、边缘节点当时返回了什么、客户端当时实际收到了什么。建议按以下顺序保存：
- 源站直连响应：用源站IP加Host头请求同一URL，记录状态码、响应体摘要、
Last-Modified、ETag、Cache-Control和响应时间。 - 边缘节点响应：请求边缘IP或域名，记录状态码、响应体摘要，以及
Age、X-Cache、Via、CF-Cache-Status一类缓存标识（若存在）。 - 请求上下文：完整URL、查询串、请求方法、Host、User-Agent、测试时间与时区。
- 同IP对照：同ip网站查询结果中同一IP上的其他域名，分别请求同一路径或首页，记录是否同样异常。
- 变化证据：异常出现前后的响应体差异，尤其是旧内容与新内容同时存在时，保留两份完整快照。
这些证据的价值在于可对照。只保存边缘节点的错误截图，无法证明源站当时正常；只保存源站日志，也无法证明用户侧收到了旧内容。两边都有时间戳，才能判断是缓存未刷新、回源失败，还是节点本身返回了错误。
一个会让结论失效的反例
假设源站直连返回200且内容为新版本，边缘节点返回200但内容为旧版本，缓存标识显示命中。此时容易得出“边缘缓存未刷新”的结论。但如果源站直连时使用了不同的Host、路径或查询串，而边缘节点请求的URL带有额外参数，源站可能按另一套规则返回了旧内容。这种情况下，异常并不在边缘缓存，而在URL规范化或参数处理。
因此，源站直连测试必须与边缘请求使用完全相同的URL、Host和方法。只要其中一项不同，源站正常这个前提就不成立，后续保留的证据也无法支撑边缘节点异常的判断。另一个反例是：同IP下其他域名也异常，但异常时间点不同，可能是共享节点在某一时段回源失败，而不是该域名配置问题。
保存证据后的下一步动作
拿到上述证据后，先做一次最小化复现：用同一URL分别请求源站和边缘节点，间隔尽量短，记录两次响应。如果边缘响应中的Age较大且内容与源站旧版本一致，可以优先检查该路径的缓存规则和刷新记录；如果边缘返回5xx而源站正常，应检查回源链路、回源Host和边缘节点日志；如果同IP下多个域名同时异常，应把范围扩大到节点或共享配置，而不是只改单个域名。
动作的结果会直接影响下一步：若刷新缓存后边缘响应与源站一致，问题可能只是缓存生命周期；若刷新后仍返回旧内容，则需要检查边缘节点是否有独立缓存层、多层代理或本地DNS缓存。若源站直连也开始异常，则原先“源站正常”的判断需要撤回，重新从源站侧排查。保留证据的意义不是证明谁对谁错，而是让每一步排查都有可回溯的对照点。
