301重定向设置：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a7883be05465.html
📄
301重定向设置：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站返回 301 只能证明源站配置生效，不能证明用户和爬虫实际收到 301。此时最该保留的不是“重定向成功”的截图，而是能证明差异发生在哪一跳的证据——同一 URL 在源站直连与边缘节点上的完整响应头、状态码、跳转链和带时间戳的对照记录。没有这组对照，后续任何修改都只是猜测。
先分清两类“正常”，否则证据方向就错了
源站正常指直连源站 IP 或用回源方式请求时，目标 URL 返回预期的 301 和正确的 Location。边缘节点异常指经过 CDN、负载均衡或反向代理后，同一 URL 返回 200、302、404，或 301 指向了错误目标。这两件事可以同时成立，因为边缘层可能缓存了旧规则、改写了响应头，或根本没把请求回源。
判断方向的关键证据是同一时刻、同一 URL、两种路径的响应头对照。如果源站直连返回 301，而边缘节点返回 200，差异就在边缘层；如果两边都返回 301 但 Location 不同，问题可能出在边缘改写规则或配置同步。
必须保留的五类证据
- 完整响应头：包括状态行、Location、Cache-Control、Age、Via、X-Cache 一类由边缘层添加的字段。只留状态码不够，Location 的具体值往往才是冲突点。
- 请求路径标记：记录请求是直连源站、经边缘节点还是带特定 Host 头，否则事后无法复现对照条件。
- 时间戳与节点标识：边缘节点可能多地部署，不同节点结果不同。保留请求时间、返回的节点或 POP 标识，才能判断是个别节点还是全局问题。
- 跳转链：用能显示每一跳的工具记录完整链路。若出现 301 到 301 再到 200，中间多出的一跳通常就是边缘层插入的。
- 变更记录：边缘规则、缓存刷新、源站配置各自的最后修改时间。这组时间与异常出现时间的先后关系，是区分“新配置没生效”和“旧缓存没清掉”的主要依据。
这五类里，响应头和跳转链是核心，其余三类是让核心证据可被复查的上下文。
用一个假设情境走一遍决策过程
假设某站点把旧栏目整体迁移，源站配置了旧路径到新路径的 301。运维直连源站测试，返回 301 且 Location 正确，于是认为完成。但随后发现部分用户仍能打开旧页面，内容还是旧的。
此时不要立刻改配置或刷新全部缓存。第一步，对同一旧 URL 分别发直连源站和经边缘节点的请求，保存两份完整响应头。假设结果是：直连返回 301，边缘返回 200 且带较大的 Age 值。这个组合指向边缘缓存了旧页面的 200 响应。
第二步，检查该 URL 的 Cache-Control 和边缘缓存规则。如果旧页面当初被设为可长期缓存，且迁移时没有主动失效，那么边缘继续返回旧 200 就成立。此时的动作是针对这批 URL 做定向缓存失效，而不是改 301 规则——改规则不会让已缓存的旧响应消失。
第三步，失效后重新采集同一组对照证据。若边缘开始返回 301，说明判断成立；若仍返回 200，则要转向检查边缘改写规则或回源配置，因为缓存已不是解释。这个动作的结果直接决定下一步查缓存还是查规则。
哪些现象不能单独证明处理正确
缓存失效后请求量或抓取量短暂归零，不能证明重定向已经正确，它也可能只是爬虫降低了访问频率、日志延迟，或边缘节点切换导致的统计断档。同理，源站日志里出现 301 记录，只说明源站发过 301，不说明边缘把它透传给了用户。
要区分这些解释，需要把边缘侧观测和源站侧日志按时间对齐：如果源站有 301 记录而边缘侧仍是 200，差异就在边缘；如果两边都无请求记录，问题可能在更前置的解析或路由层。
复查时把证据固定成可对比的形式
建议为每个争议 URL 建立一行对照记录，字段至少包含：URL、请求路径、状态码、Location、关键缓存头、时间、节点标识。这样当有人问“到底修好没有”，回答依据是两组可比对的记录，而不是一次测试的观感。
需要提醒的是，边缘层的行为受缓存策略、回源规则和配置下发速度共同影响，任何单次测试都可能落在配置尚未同步的窗口内。因此复查应在变更后间隔取样，并保留每次取样的原始响应头，而不是只留一句结论。
把源站与边缘的证据分开保存、对齐时间，才能在下一次异常出现时快速判断该动缓存、动规则还是动源站配置。
