📍 WDQWDWQD987AAAAA:216.73.216.70
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7448b02f95cc.html
📄

301重定向：源站正常而边缘节点异常时应保留哪些证据

先给结论：当源站返回 301 正常、边缘节点却返回 200、302、404 或旧内容时，最该保留的不是一张截图，而是能区分“边缘缓存了旧响应”与“边缘配置覆盖了源站规则”的证据链。至少要留下请求时间、完整 URL、响应头、节点标识、源站对照结果，以及这些证据的采集方式。缺了其中任何一项，后续动作都只能靠猜。

先分清两种解释：缓存旧响应，还是配置覆盖

边缘节点异常最常见的两种原因是：

• 缓存层保留了旧响应。源站早已改成 301，但边缘仍把旧 URL 的 200 响应或旧 HTML 发给访客，直到缓存过期或被主动清除。
• 边缘规则覆盖了源站。源站确实返回 301，但边缘上的重写、路由或回源规则把请求指向了别处，或者直接由边缘生成了响应，源站根本没被问到。

这两者的处理方向完全不同：前者清缓存即可验证，后者必须改配置。判断依据不在状态码本身，而在“源站有没有被请求到”。

能区分两种解释的证据

响应头里的回源痕迹

保留完整响应头，而不是只看状态码。重点看这些字段是否存在、值是什么：

• Age：大于 0 通常说明响应来自缓存层；为 0 或缺失则更可能来自回源。
• Cache-Control、Expires：判断旧响应为何还能被继续使用。
• Via、X-Cache、CF-Cache-Status 一类字段：不同服务商命名不同，看到就记下原值，不要自行翻译成结论。
• Location：301 的目标地址是否与源站一致。若边缘返回的 Location 与源站不同，配置覆盖的嫌疑更大。
• Server、X-Served-By：用于标记响应由哪一层产生。

这些字段的名称和含义因服务商而异，必须以实际抓到的原文为准，不要套用别家的字段名去推断。

同一次请求的源站对照

在尽可能接近的时间窗内，用同样的 URL 和请求方法直接访问源站，记录源站返回的状态码、Location 和响应头。若源站稳定返回 301，而边缘返回 200 且带 Age，缓存旧响应的解释成立；若边缘返回的 Location 与源站不同，或边缘压根没有回源痕迹，配置覆盖更可能。

节点与时间维度

单次请求只能证明一个节点在一个时刻的表现。保留多个节点、多个时间点的结果，才能判断是全局配置问题还是局部缓存问题。记录时至少包含：请求发起时间（含时区）、解析到的节点 IP 或节点标识、请求所用的 URL（含协议和查询串）。

一个假设例子：怎么用证据决定下一步

假设旧栏目 /old/ 已改为 301 指向 /new/。源站直连返回 301，但边缘返回 200 并带有 Age: 86400，Location 缺失。

此时先做清除缓存这一动作，再立刻用同一 URL、同一节点复测。如果复测变成 301，说明是缓存旧响应，下一步应检查旧响应的缓存策略为何允许长期留存，并确认其他旧路径是否有同样问题。如果清除后仍是 200，或 Location 与源站不一致，就应转向检查边缘的重写与路由规则，而不是继续清缓存。这个动作的价值在于：它把两种解释压缩成一次可复现的对照，结果直接决定排查方向。

采集证据时的操作要点

1. 用 curl -I 或等效方式抓取响应头，保存原始输出，不要只抄状态码。
2. 同时保存请求 URL 的完整形式，包括协议、主机名、路径和查询串；重定向行为常因协议或尾斜杠不同而不同。
3. 标注采集时间与节点，避免把不同时刻、不同节点的结果混在一起比较。
4. 对同一 URL 至少保留源站直连与边缘访问两组结果，形成对照。
5. 记录采集命令本身，让第三方可以复现，而不是只给一份结论。

需要提醒的是，抓取量或某个日志字段归零，并不能单独证明边缘已经恢复正常，它也可能是采集方式变化、日志延迟或过滤规则导致的。判断是否恢复，仍要回到源站与边缘的状态码、Location 和响应头是否一致。

退出旧内容时，证据要留到什么时候

旧内容、旧系统或旧合作关系退出时，301 往往要长期保留，因为外部链接和用户书签不会同步消失。因此边缘异常的证据应保留到确认所有相关路径在源站与边缘表现一致为止，而不是清一次缓存就结束。若旧路径数量较多，建议按路径分组抽样，每组保留一份完整证据，并注明抽样依据，这样后续复查时不必从头再来。

把这些证据整理成可复查的记录，比任何一次“看起来正常了”的目测都更有用，因为下一次异常出现时，你需要的正是上一次的对照基线。