网站URL提交：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3b53f9fc8895.html
📄
网站URL提交：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站正常、边缘节点异常时，最该保留的不是“提交成功”的截图，而是能证明同一URL在源站与边缘返回不一致的成对证据——完整响应头、响应体摘要、请求时间与节点标识。只有拿到这组对照，你才能判断异常是缓存层、CDN回源、WAF拦截还是节点局部故障，进而决定是刷新缓存、切换节点还是回源排查，而不是盲目重提URL。
第一步：把单个URL固定为可对比对象
选一个你已提交、源站确认返回200的URL作为样本，不要一次抓十个页面，否则证据会互相污染。对同一URL分别发起两次请求：一次直连源站IP并带Host头，一次走边缘节点域名。两次都加上-D headers.txt -o body.txt保存响应头与响应体，记录请求的UTC时间。
判断依据是：源站返回的Content-Length、ETag或Last-Modified与边缘节点返回的对应字段是否一致。如果源站是200而边缘返回206、304或带x-cache: HIT的旧内容，说明差异发生在缓存或回源环节，而不是源站本身。这个动作的结果直接决定下一步：字段不一致就进入缓存与回源排查，字段一致但状态码不同则转向WAF或节点健康检查。
第二步：保留边缘异常的最小证据集
边缘节点异常的表现往往是一个状态码或一段错误页，但单张截图无法复查。至少要保存以下四类内容：
- 完整响应头：包括
server、via、x-cache、age、cf-ray或同类节点标识字段，它们能定位请求经过了哪一层。 - 响应体前若干字节：错误页常包含节点ID或错误码，比状态码更有区分度。
- 请求时间与客户端出口IP：用于判断是持续异常还是某个时间窗内的抖动。
- 同一URL在源站的对照响应：这是证明“源站正常”的唯一凭据，缺了它，边缘异常就无法成立。
如果边缘返回的是HTML错误页，把关键行以<div>形式摘录即可，不必保存整页。重点是让第二个人能凭这些字段复现你的判断。
第三步：两种做法的取舍条件
面对边缘异常，常见两种做法：立即刷新该URL的缓存，或先冻结证据再操作。两者都合理，但成立条件不同。
先刷新缓存适用于：你已保存了异常响应头与响应体，且异常只出现在单个URL、源站对照正常。此时刷新是低成本的验证手段，刷新后重新抓取，如果字段恢复一致，说明是缓存层问题，下一步应检查缓存规则与TTL，而不是继续重提URL。
先冻结证据适用于：异常覆盖多个URL、或边缘返回5xx、或响应头里出现WAF拦截标识。这时刷新可能覆盖现场，导致你无法判断是节点故障还是规则误杀。代价是处理时间变长，但换来的是可向服务方复现的完整证据链。选择依据很简单：异常是否可稳定复现、是否涉及多个路径。可复现且单点，先刷新；不可复现或多点，先冻结。
第四步：用假设例子校准判断
假设某URL在源站返回200且ETag: "abc"，边缘节点返回200但ETag: "xyz"且age: 86400。这组证据指向缓存存有旧版本，而不是节点不可用。此时刷新缓存并重新抓取，若ETag变为"abc"，则问题收敛到缓存策略；若仍为"xyz"，则需检查回源配置或节点同步。
再假设边缘返回403且响应头含WAF规则编号，源站返回200。这属于规则层拦截，刷新缓存无效，应保留该403响应头与规则编号，转向WAF日志核查。两种假设的差别在于：前者靠缓存字段区分，后者靠拦截标识区分，证据类型不同，后续动作也不同。
第五步：把证据转成可执行的处理顺序
拿到上述证据后，按以下顺序推进：先确认异常URL范围是单点还是批量；单点且缓存字段异常，先刷新再复查；批量或含5xx、403，先冻结证据并核对节点状态与规则日志；若源站与边缘在多次抓取中始终不一致，且刷新与规则核查都无解，再考虑向服务方提交带时间戳与节点标识的复现记录。每一步的结果都应回写到同一份证据文件里，避免用记忆替代记录。
需要提醒的是，robots.txt的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些与边缘异常无关，不要把它们混进本次证据集。真正决定下一步的，始终是源站与边缘那组成对响应之间的差异。
