同ip网站：源站正常而边缘节点异常时应保留哪些证据，先固定源站侧的原始响应证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /fae73f16f799.html
📄
同ip网站：源站正常而边缘节点异常时应保留哪些证据，先固定源站侧的原始响应证据
先给结论：当同IP网站中源站响应正常、边缘节点却返回错误时，应优先保留能区分“源站内容正确”与“边缘缓存或回源链路异常”的证据，而不是只留一张报错截图。适用条件是你能分别触达源站与边缘节点；一旦无法绕过边缘直连源站，这套证据链就会失效，需要换用回源日志或缓存状态来间接判断。
先固定源站侧的原始响应证据
源站正常是这套判断的前提，所以第一步不是看边缘报错，而是把源站的原始输出固定下来。保留源站直接响应的状态码、响应头中的内容长度与缓存相关字段、以及页面主体中一段可唯一识别的文本。这样做的目的是让后续边缘结果有一个可对照的基准，否则你无法证明问题出在边缘而不是内容本身。
具体动作：用命令行工具带 Host 头直连源站，把完整响应头与正文摘要保存到独立文件，并在文件名里写明时间与请求的 Host。结果影响下一步——如果源站响应头里带有较长的缓存有效期或强缓存标记，边缘节点的旧结果就更可能是缓存未过期，而不是回源失败，排查方向应从“链路”转向“缓存刷新”。
边缘侧要留下可对比的请求与响应
边缘节点的证据必须能和源站一一对应，否则只是孤立的报错。至少保留三项：请求的完整 URL 与查询串、边缘返回的状态码与响应头、以及响应头中标识缓存命中或回源的字段。很多边缘异常表现为部分 URL 报错、其余正常，这时逐条记录比笼统描述“网站打不开”有用得多。
- 同一条 URL 分别记录源站与边缘的状态码，差异本身就是证据。
- 保留边缘响应头里的缓存状态、回源标识和节点标识（若存在）。
- 记录请求时间与时区，便于和日志对齐。
这些字段能帮你区分两种原因：一是边缘缓存了旧内容，二是边缘回源时拿到错误结果。前者刷新缓存后通常恢复，后者需要继续查回源链路。
用一组对照样本判断是个例还是规模化例外
个别样本成立不代表整体成立，这是本篇要特别提醒的边界。假设你抽查同IP下的五个站点，其中四个边缘正常、一个异常，就不能直接推断“该IP被封”。更合理的解释可能是那一个站点的缓存键配置不同，或它的某条 URL 命中了特殊规则。
可区分原因的证据来自对照：把异常的 URL 与同站点正常的 URL 对比，再把异常站点与同IP下正常站点对比。如果异常只跟着某条 URL 走，问题在缓存键或规则；如果异常跟着某个站点走，问题在该站点的边缘配置；如果异常跟着整个IP走，才需要考虑共享面。缺少对照时，任何“IP 被牵连”的结论都只是猜测。
会使结论失效的反例
有一个反例会让上述方法直接失效：当你无法绕过边缘、只能通过边缘访问源站时，“源站正常”这个前提就无法独立验证。此时你看到的所谓源站响应，其实已经过边缘处理，源站与边缘的证据不再相互独立。
遇到这种情况，应改用回源日志、缓存状态字段或源站访问日志来间接确认源站是否被正常请求。如果这些日志也拿不到，就只能把结论降级为“边缘结果异常”，不要断言源站正常。同理，robots.txt 的抓取限制不等于可靠的索引移除，边缘返回 200 也不等于内容正确，状态码需要和正文对照才有意义。
下一步动作与留存格式
把上述证据按“时间—URL—源站结果—边缘结果—缓存状态”整理成一份对照记录，再决定动作：若差异集中在缓存状态，先刷新缓存并复测同一 URL；若差异集中在回源标识，检查回源链路与源站对该边缘节点的响应；若差异跟着整个IP扩散，再评估共享面影响。
留存时避免只存截图，截图无法检索也无法对比。用文本保存响应头与正文摘要，配合时间戳，才能在问题复现或交接时被复查。完成一次刷新或调整后，务必用同一组 URL 复测，否则你无法知道动作是否真正改变了结果。
