301跳转设置，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eb189eb5061b.html
📄
301跳转设置，源站正常而边缘节点异常时应保留哪些证据
核心判断是：源站返回的301只能证明回源这一层正确，边缘节点是否把301正确传给访客，需要另一套证据。假设一次整站迁移后，你在源站直接请求旧地址，看到301指向新地址，但部分地区的访客仍拿到旧页面或200状态。此时应优先保留能区分“边缘缓存了旧响应”“边缘改写了状态码”“DNS把请求导向了未更新节点”这三类原因的原始记录，而不是先改跳转规则。
先固定请求链路，别让证据互相覆盖
源站正常而边缘异常，最常见的取证失误是只测一次最终URL。最终URL的响应可能是边缘节点缓存、回源后二次加工或旧节点直接返回的结果，无法反推哪一层出错。应分别保留三类请求的完整响应：直连源站IP并带Host头、经边缘节点请求旧地址、经边缘节点请求新地址。三类请求都要记录请求时间、客户端出口地区、请求方法、完整响应头中的status、location、cache-control、age、via或等效的节点标识字段，以及响应体的前若干字节。
这样做的实际结果是：如果直连源站是301，经边缘是200且age大于0，问题更可能在边缘缓存了跳转生效前的旧响应；如果经边缘是301但location指向旧域名，问题更可能在边缘配置或回源改写；如果不同出口地区结果不一致，问题更可能在DNS或节点分发，而非跳转规则本身。
边缘异常时，哪些证据比截图更有用
截图只能证明某一刻你看到了什么，不能证明边缘节点当时返回了什么。可复查的证据应满足“原始、带时间、可对照”三个条件。优先保留以下内容：
- 边缘节点访问日志中该请求的完整记录，包括节点IP或节点编号、请求时间、上游状态、返回给客户端的状态、缓存命中标记。
- 源站访问日志中同一时间窗口的回源记录，用来确认边缘是否回源、回源时源站返回了什么。
- 带时间戳的原始响应头文本，而不是只保留状态码数字。
- DNS解析记录在异常时段的结果，至少包含解析到的节点地址和TTL。
- 边缘缓存规则或跳转规则的当前配置快照，以及最近一次变更时间。
这些材料能支撑一个关键判断：边缘返回的200是“自己生成的”还是“回源拿到的”。前者指向边缘配置或缓存，后者指向源站对特定回源请求的响应差异。缺少回源日志时，只能看到客户端侧结果，无法排除源站对边缘回源请求返回了不同内容。
两个合理做法之间的取舍：先清缓存还是先改规则
面对边缘异常，常见两种做法：先刷新边缘缓存再观察，或先改跳转规则再验证。两者都成立，但适用条件不同。
如果证据显示源站301正确、边缘返回旧响应且age较大、回源日志显示边缘近期没有回源，那么先刷新缓存更合理。代价是刷新可能只影响部分节点，若缓存键包含地区或协议差异，刷新后仍可能残留旧响应，需要按缓存键维度逐一核对。
如果证据显示边缘返回的location与源站不一致，或边缘对旧地址直接返回200且没有回源记录，那么先改规则更合理。代价是规则变更会引入新的变量，若不同时保留变更前后的响应头，后续很难判断问题是原有还是新引入。
取舍依据不是哪种做法更快，而是证据指向哪一层。动作之后要立即重复同一组请求并保存响应，用变更前后的差异确认影响面是缩小、不变还是扩大。如果变更后异常范围没有变化，说明原判断不成立，应回到日志层重新区分缓存、规则和DNS三类原因。
假设情境：一次迁移后的边缘异常取证
假设某站点把旧域名整体301到新域名，源站直连测试正常。随后发现部分访客仍看到旧域名页面，状态为200。按以下顺序取证：
- 从异常出口请求旧地址，保存完整响应头和响应体片段，记录
status、location、age、节点标识。 - 同一时刻直连源站请求旧地址，保存响应头，确认源站是否稳定返回301及正确的
location。 - 调取边缘节点日志和源站回源日志，对齐同一时间窗口，确认异常请求是否回源、回源响应是什么。
- 核查该时段的DNS解析结果，确认异常出口是否解析到已更新节点。
若第1步显示200且age较大、第3步显示无回源记录，则问题在边缘缓存，先按缓存键刷新并复测。若第1步显示301但location错误、第3步显示回源正常，则问题在边缘改写，先改规则并保留变更前后响应头。若第4步显示解析到未更新节点，则问题在节点分发，改跳转规则不会解决，应处理节点同步或解析范围。
保留证据时的边界与常见误判
请求量、抓取量或某类状态码统计下降，不能单独证明301已被正确处理。它也可能来自抓取节奏变化、日志采样、节点切换或访问来源结构变化。同理，边缘返回301也不等于访客一定到达新地址，后续请求仍可能被新地址上的其他规则改写。
证据保留要覆盖足够长的时间窗口，至少包含异常出现前的一次正常请求和异常出现后的多次请求，否则无法判断是持续状态还是瞬时抖动。若涉及多个搜索引擎或平台，应分别核查其抓取或访问记录，不同来源对跳转的跟随和缓存行为可能不同，不能用单一来源的结果推断全部。最后，任何刷新缓存或修改规则的动作都应记录时间点和操作范围，否则后续日志中的变化无法归因，下一步判断也会失去基准。
