同服务器网站查询，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d7244b1b04f0.html
📄
同服务器网站查询，源站正常而边缘节点异常时应保留哪些证据
先给结论：同服务器网站查询出现“源站正常、边缘节点异常”时，最该保留的不是一张截图，而是能证明“同一时刻、同一路径、不同节点返回不同结果”的对照证据。具体保留哪些，取决于你是要推动边缘服务商处理，还是要判断旧系统、旧合作关系是否该退出。两条路线的证据取舍不同。
先分清两种处置条件，证据范围不同
第一种条件：你仍要维持这条边缘链路，只是要服务商修。此时证据要能锁定故障节点、时间和请求特征，让对端无法用“源站问题”推回来。第二种条件：这条边缘链路本来就属于要退出的旧内容、旧系统或旧合作关系，你只是要确认退出过程没有把仍有价值的源站部分一起弄坏。此时证据重点从“追责”转向“划界”，证明源站本身可用、异常只发生在将被弃用的那一层。
判断依据很直接：如果异常节点仍承载线上流量或仍有合同义务，走第一种；如果异常节点对应的只是历史域名、旧 CDN 配置或已停止合作的加速服务，走第二种。混用会导致你留下大量无用的节点日志，却漏掉真正能证明源站独立可用的记录。
必须固定同一时刻的源站与节点对照
核心动作是：在尽可能接近的时间点，分别向源站地址和边缘节点地址发起同一路径、同一方法的请求，并记录返回状态码、响应大小、关键响应头和响应时间。假设某路径在源站返回 200 且正文完整，经边缘节点返回 5xx 或明显截断，这组对照才成立。若两次请求相隔很久，中间源站可能已经变更，对照就失去意义。
保留时要注意：状态码相同不代表内容相同。边缘节点可能返回 200 但内容是缓存的旧版本或错误页，所以响应体摘要、内容长度和缓存相关响应头同样要留。抓取限制文件只能约束抓取行为，不能作为索引移除的可靠手段；这一点在退出旧系统时尤其容易误判，别把“已限制抓取”当成“已清理干净”。
时间、节点标识和请求细节缺一不可
只有对照结果还不够，必须能回答“哪个节点、什么时候、什么请求”。建议保留以下字段：
- 请求发出的绝对时间，带时区，便于和服务商日志对齐；
- 边缘节点的标识信息，如响应头中出现的节点编号或机房代号；
- 完整请求行、Host 头、协议版本和是否带查询参数；
- 源站直连与经节点两条路径各自的响应头快照；
- DNS 解析结果，说明当时该域名指向了哪些地址。
这些字段的作用是让证据可复查。缺少节点标识，服务商可以说“无法定位”；缺少时间，日志无法对齐；缺少请求细节，无法排除是特定参数触发的个例。
退出旧关系时，证据要证明源站可独立存活
如果你判断这条边缘链路该退出，那么保留证据的目的变成：证明去掉边缘层后，源站仍能正常响应，且仍有价值的部分没有被牵连。此时应额外保留源站直连在多个时间点的稳定响应记录，以及退出前后同服务器网站查询结果的差异对比。差异应集中在边缘层，而不是源站本身。
一个需要说明的例外：如果源站直连也出现间歇异常，就不能简单归因于边缘节点。请求量或抓取量归零、日志中某类记录消失，都不能单独证明处理正确，它们也可能是采集方式改变、日志轮转或访问本身减少造成的。遇到这种情况，先补做源站侧的多点验证，再决定是否继续退出。
哪些证据可以少留，哪些不能省
可以少留的是与判断无关的全量访问日志和长期趋势图，它们体量大且难以对齐。不能省的是能形成闭环的最小证据集：同一时刻的源站与节点对照、节点标识、时间戳、请求细节，以及退出场景下的源站独立可用记录。HTTPS 只说明传输层加密，不代表内容无误或节点配置正确，所以不要用“有证书”替代上述对照。
把这些证据按“一次异常一组”的方式归档，每组内部保持时间、路径、节点三者一致。下一步无论是提交给服务商，还是内部决定旧系统退出范围，都能直接引用，而不必重新复现故障。
