URL提交，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6e79e0d7ae60.html
📄
URL提交，源站正常而边缘节点异常时应保留哪些证据
先给结论：源站返回正常、边缘节点异常时，URL提交相关判断最怕“只看一眼首页就下结论”。应保留的证据要能同时证明三件事——你提交的是哪个URL、边缘节点当时返回了什么、源站当时返回了什么。证据链不完整时，后续无论重提、回滚还是等恢复，都缺少可复查依据。
先固定提交对象，避免把边缘异常当成源站问题
URL提交的对象通常是一个具体地址，而不是整站。边缘节点异常时，第一步不是急着重新提交，而是把对象固定下来：完整URL、协议、是否带参数、是否经过重定向、提交时间点。若提交的是带参数的地址，而边缘节点对参数做了归一化或丢弃，源站正常也可能表现为提交结果异常。
可执行动作：对同一URL分别记录源站直连响应与边缘节点响应。结果如何影响下一步——若两者状态码一致但内容不同，问题更可能在缓存或回源策略；若源站正常而边缘持续返回异常，才需要进入证据留存与上报流程。
边缘侧证据要覆盖状态码、响应头与时间点
边缘节点异常不一定表现为5xx。有时是200但内容为空、返回旧版本、或跳转到错误地址。因此证据至少要包含：
- 边缘节点返回的状态码与响应头，尤其是缓存相关字段和回源标识；
- 请求时间与响应时间，最好精确到分钟，便于与源站日志对齐；
- 响应体摘要或首屏关键内容，证明返回的是错误页、旧页还是空页；
- 同一URL在不同网络或不同节点上的对比结果，用于判断是个别节点还是全局。
这些证据的作用是区分“边缘节点没拿到正确内容”和“边缘节点拿到了但返回给用户时出错”。前者要查回源，后者要查边缘处理逻辑。
源站侧证据要能证明“正常”不是偶然
源站正常不能只凭一次访问。应保留源站日志中对应时间段的请求记录，包括状态码、响应大小、处理耗时和请求来源标识。若源站有多个实例，还要确认是否所有实例都正常。假设一个场景：边缘节点在10:00到10:05持续异常，而源站日志显示同一时间段只有零星请求到达，那么“源站正常”这个结论本身就需要补充——可能边缘根本没有正确回源。
可执行动作：把源站日志与边缘日志按时间对齐，标出边缘异常期间源站是否收到对应请求。结果如何影响下一步——若源站未收到请求，问题在边缘回源链路；若源站收到且返回正常，问题在边缘缓存或响应处理。
URL提交记录本身也是证据的一部分
提交记录能说明你何时、以什么方式提交了哪个URL。边缘异常期间，提交动作可能成功也可能失败，但提交成功不等于边缘节点已能正常提供内容。需要保留：提交时间、提交的完整URL、提交时的返回信息。若提交接口本身经过边缘节点，还要记录提交请求是否也受影响。
这里要避免一个常见误判：提交成功只代表提交动作被接收，不代表抓取或索引状态已改变。边缘异常时，提交记录的价值在于证明“你做过什么”，而不是证明“结果已经正确”。
证据整理成可复查的最小集合
面向旧内容或旧系统的退出场景，保留证据的目的是决定哪些部分值得继续维护。可按以下最小集合整理：
- URL清单：完整地址、参数、重定向链；
- 边缘响应：状态码、响应头、时间点、响应体摘要；
- 源站响应：日志记录、状态码、响应大小、实例范围；
- 提交记录：提交时间、提交方式、提交返回信息；
- 对比结论：边缘与源站差异点，以及可排除的原因。
整理完成后，再决定动作：若证据指向边缘缓存问题，优先处理缓存与回源；若指向提交对象本身已失效，则考虑退出或替换。证据不足时不要用“重新提交一次”代替排查，因为重复提交不会修复边缘节点返回错误内容的问题。
