URL安全扫描，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3b542a664c78.html
📄
URL安全扫描，源站正常而边缘节点异常时应保留哪些证据
先给结论：当同一 URL 在源站请求正常、经边缘节点返回异常时，最该保留的不是“异常截图”本身，而是能证明请求走了哪条链路、边缘返回了什么、源站实际回了什么这三类证据。只保存一张报错页面，后续既无法区分是边缘缓存了旧响应，还是边缘到源站的回源链路被改写，也无法判断影响范围是单个节点还是整片区域。
先分清两种解释：缓存副本问题，还是回源链路问题
这个矛盾现象通常有两种成立条件不同的解释。
第一种是边缘缓存或边缘规则问题。源站内容已经更新或本来正常，但边缘节点仍持有旧副本，或者边缘上的重写、跳转、拦截规则只对特定路径生效。它的特征是：异常与 URL 路径、查询串、请求头高度相关，同一节点上换一个参数可能就正常。
第二种是回源链路问题。边缘拿不到源站的真实响应，于是返回自己的错误页、超时页或安全拦截页。它的特征是：异常与节点位置、回源出口、源站对该来源的响应策略相关，同一 URL 在不同节点表现不同，而源站日志里可能根本没有这次请求，或请求特征与边缘记录不一致。
两种解释对应的处置动作完全不同。前者要清缓存、核对边缘规则；后者要查回源地址、回源协议和源站对边缘来源的放行策略。证据不足时贸然清缓存，可能把唯一能复现的现场抹掉。
能区分两种解释的证据：三份记录要同时留
判断的关键是让“边缘看到的”和“源站收到的”能对上。建议在复现异常时同时保留以下三份记录，并注明采集时间、所用节点或出口、请求方法、完整 URL（含查询串）和请求头中的关键字段。
- 边缘侧响应记录：状态码、响应头（尤其是缓存命中相关字段、内容类型、跳转位置）、响应体前若干字节，以及边缘自身产生的错误标识（如有）。
- 源站侧访问记录：同一时间窗口内该 URL 的请求是否到达、来源地址、请求方法与路径、返回状态码。
- 链路对照记录：用同一 URL 分别直连源站和经边缘请求，保存两次的完整响应头做逐字段对比。
区分方法很直接：如果源站访问记录里没有这次请求，问题更可能在边缘到源站之间，属于回源链路；如果源站有请求且返回正常，而边缘返回不同，问题更可能在边缘缓存或边缘规则。这里要注意一个边界：源站日志缺失也可能是日志采样、日志延迟或日志未覆盖该入口造成的，不能仅凭“没看到记录”就断定回源失败，需要换一个时间窗口或换一个已知会打日志的路径做对照。
一个注明假设的短例子
假设某站点在三个边缘节点上抽测：节点 A 返回旧版本页面，节点 B 返回 403，节点 C 正常。直连源站三次都返回新版本。此时若只保留节点 B 的 403 截图，很容易误判为源站拒绝了边缘。但若同时保留三份记录，可能看到：节点 A 的响应头显示缓存命中且时间戳较早，节点 B 的源站访问记录为空，节点 C 的响应头与源站一致。这样就能把 A 归入缓存副本问题、B 归入回源链路问题，而不是当成同一个故障处理。
这个例子的数字仅用于说明比较方法，不代表任何真实站点的表现。实际抽测时，节点选择和样本量要按你的业务覆盖范围决定，样本太少时“个别节点正常”不能推出“整体正常”。
保留证据之后，下一步动作怎么被证据决定
证据决定动作，而不是反过来。
- 若对照显示边缘响应头带缓存命中标记、且源站返回正常，先核对边缘缓存键与缓存规则，再决定是否针对该路径清理，而不是全站清理。
- 若源站访问记录为空且边缘返回自身错误页，先核对回源地址、回源协议与源站对该来源的放行策略，再决定是否调整回源配置。
- 若两者都正常但仅特定查询串异常，优先检查边缘规则对参数的处理，而不是改动源站内容。
还要说明适用条件：以上判断适用于你能同时取得边缘侧和源站侧记录的场景。若边缘侧日志不可得，只能退而求其次，用可复现的请求头组合和响应头快照来缩小范围，此时结论强度会下降，不宜据此做全量变更。另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名，这些与边缘异常的证据判断是不同层面的问题，不要混在一起下结论。
把这三类证据按时间戳对齐保存，你才能在“改边缘”还是“改源站”之间做出有依据的选择，并在改动后复测同一组样本，确认异常是消失还是转移到了别的节点。
