同IP网站：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /55807d7db219.html
📄
同IP网站：源站正常而边缘节点异常时应保留哪些证据
结论先给：当同IP网站里源站回源正常、但边缘节点返回异常时，优先保留“能区分源站与边缘”的对照证据，而不是只保存一张报错截图。最小可执行动作是用同一URL分别请求源站地址和边缘地址，记录响应状态、响应头、响应体哈希与时间戳；如果缺少完整日志或CDN后台权限，这一步仍能完成。但要注意一个反例：若异常只出现在你本地网络，或者边缘节点对特定地区做了差异化返回，那么上面这组对照只能说明“两条路径结果不同”，不能直接推出“边缘节点故障”。
先分清哪类证据能定位到边缘，哪类只能证明现象
边缘节点异常和源站异常在外观上可能完全一样，都是5xx、空响应、旧内容或跳转错误。要作决定，证据必须能回答“同一请求在两条路径上是否得到不同结果”。
- 能定位的证据：同一URL在源站地址与边缘地址上的状态码对照、响应头差异（如缓存命中状态、回源标记、节点标识）、响应体字节数或哈希差异、请求时间与响应时间。
- 只能证明现象的证据：单张浏览器报错截图、单一地区的一次curl结果、用户口述“打不开”。这些能触发排查，但不足以判断问题在边缘还是源站。
- 容易被误读的证据：边缘返回旧内容，不一定代表源站没更新，也可能是缓存未过期或回源被跳过；边缘返回403，也不一定是源站拒绝，可能是边缘侧规则先拦截。
如果只有浏览器权限、没有服务器权限，仍可做最小动作：用浏览器开发者工具记录请求的响应状态、响应头和响应时间，再对比同一URL带随机查询参数后的结果。带随机参数后仍异常，说明不是单纯命中旧缓存；带随机参数后恢复正常，说明缓存层值得优先检查。这个结果会直接决定下一步是查缓存规则，还是查回源链路。
缺少日志和后台权限时，仍可保留的最小证据集
权限不足时不要等“完整数据”再动手，先固定可复查的对照样本。假设你管理一个同IP网站，某天边缘地址返回502，而源站地址返回200。你可以保留以下内容：
- 记录请求时间，精确到分钟，并注明时区。
- 保存同一URL两次请求的完整响应头，重点看状态码、缓存相关字段、回源相关字段和节点相关字段。
- 保存两次响应体的长度和哈希值，而不是只保存页面截图。
- 记录请求使用的DNS解析结果或边缘地址，避免事后无法确认请求打到了哪里。
- 如果异常可复现，间隔数分钟重复一次，观察是持续异常还是间歇异常。
这些证据的作用是缩小范围：源站200而边缘502，且响应头显示边缘未成功回源，下一步就应查边缘到源站的连通性和回源配置；如果源站也出现相同状态码，则问题更可能在源站或源站前置层，而不是边缘节点。注意，响应头字段名称因服务商和配置而异，缺少后台权限时不要强行解释不认识的字段，先原样保存。
哪些证据看似有用，实际上会把判断带偏
第一类误导是“只保留最终页面”。页面截图无法区分是源站返回了旧内容，还是边缘缓存了旧内容。第二类误导是“只看状态码”。边缘返回200但内容为空、内容被截断或被替换，同样属于异常，状态码正常不能排除问题。第三类误导是“把一次成功请求当作恢复”。边缘节点通常有多个，一次成功可能只是命中了另一个节点，不能证明异常已消除。
还有一个常见反例：你从本地请求边缘地址异常，但从另一网络请求正常。这时不能直接断定边缘节点故障，因为差异可能来自本地DNS、运营商链路、地区调度或边缘侧的访问控制。此时应保留两地请求的响应头和时间戳，并注明网络环境；下一步动作是扩大请求来源，而不是立即要求回源侧改配置。
把证据转成下一步动作的判断规则
可以用一个简单规则决定先查哪边：
- 源站正常、边缘异常、带随机参数后仍异常：优先查边缘回源链路和边缘侧规则。
- 源站正常、边缘异常、带随机参数后恢复正常：优先查缓存策略和缓存刷新机制。
- 源站与边缘都异常：优先查源站本身及其前置层，不要先动边缘配置。
- 只有单一网络或单一地区异常：先扩大样本，不要据此修改全站配置。
执行这个规则后，你会得到一个新的可验证问题，例如“边缘到源站的回源请求是否成功”。这个问题比“网站是不是坏了”更具体，也更容易在权限有限时继续推进。若最终只能拿到部分证据，应在交接记录中明确写出已确认事实、未确认假设和下一步验证方式，避免把推测当成结论。
