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

永久重定向方法源站正常而边缘节点异常时应保留哪些证据

源站返回 301 正常、边缘节点却返回 302、200 或 5xx 时，先不要改源站规则。此时应保留能证明“源站与边缘不一致”的证据：同一 URL 直连源站的完整响应头、经边缘节点的响应头、请求时间与节点标识、以及重定向链路每一跳的状态码。拿到这些证据后，下一步才是判断边缘缓存的是旧规则、旧配置，还是节点侧做了额外改写。

先固定对比条件，再判断该不该动源站

边缘异常最容易误判的地方，是把“边缘返回了错误状态”当成“源站配置错了”。要区分这两种情况，必须让两次请求尽可能只差一个变量：是否经过边缘。实际操作上，可以用带解析覆盖的方式直连源站，再用正常域名请求边缘，两条命令都加上 -I 只取响应头，并记录 date、server、location、cache-control、age、x-cache 这类字段。

判断依据可以简化成一条：如果直连源站稳定返回 301 且 Location 正确，而边缘返回的状态码或 Location 不同，那么问题在边缘链路，不应先改源站。反过来，如果直连源站本身就返回 200 或 302，边缘只是忠实转发，那才需要回到源站规则排查。这个区分决定了后续动作方向，先做错方向会把正常配置改坏。

证据清单：哪些字段能区分缓存旧规则与节点改写

不是所有响应头都有同等价值。能帮助定位的证据大致分三组：

• 状态与目标：每一跳的 status 和 location，用来确认是 301 还是被替换成 302、200。
• 缓存痕迹：age、cache-control、expires、etag、last-modified，用来判断边缘是否在返回一份旧副本。
• 节点身份：server、via、x-cache、cf-ray 一类字段，以及请求发生的时间，用来确认异常是否集中在特定节点或特定时段。

如果边缘响应里 age 很大、location 指向旧地址，通常更像缓存了旧规则；如果 age 为 0 但状态码仍与源站不同，则更可能是节点侧改写或配置未同步。这两种解释对应不同处理动作：前者先处理缓存刷新，后者先核对边缘配置版本。注意，请求量下降或某节点抓取归零，并不能单独证明边缘已经恢复正常，它也可能只是流量调度变化或监控口径变化。

两种条件下的不同选择

条件一：直连源站正常，边缘仅在部分节点异常。此时优先保留分节点证据，不要全量刷新缓存。动作是记录异常节点标识、异常出现时间、同一 URL 在正常节点与异常节点的响应头差异。结果如果显示只有少数节点返回旧 Location，可先针对这些节点做缓存清理或配置同步，再复测同一 URL。复测仍异常，才升级为配置问题。

条件二：直连源站与边缘都不稳定，或直连也出现 302。此时源站规则本身可能已被改动或存在多条规则冲突。动作是先冻结变更，导出当前重定向规则，逐条核对匹配顺序，再决定是否回滚。结果会影响下一步：如果回滚后直连恢复 301，说明问题在规则变更；如果回滚后仍异常，则要检查上游代理或应用层是否插入了跳转。

一个带假设的短例子

假设某站点把 /old 永久重定向到 /new，源站直连返回 301 且 Location 为 /new。经边缘请求时，一个节点返回 302 且 Location 为 /old，另一个节点返回 301。此时保留的证据应包含两次请求的时间、节点标识、完整响应头。若异常节点响应中 age 明显偏大，较合理的解释是缓存了旧规则；若 age 很小仍返回 302，则更应怀疑边缘配置未同步。这个例子只是说明比较方法，不代表任何真实节点行为。

保留证据时的常见例外

有些情况会让“源站正常”这个前提本身不成立。比如源站对直连 IP 与对边缘回源 IP 返回不同结果，或者源站根据 Host、协议、UA 做了条件跳转。这时直连正常并不能代表回源正常。必要适用条件是：对比请求的 Host、路径、协议保持一致，且确认边缘回源地址与直连地址一致。若不一致，应先补齐回源侧证据，再判断边缘是否真的异常。

另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；这些与边缘跳转异常不是同一层问题，不要用它们替代响应头证据。把上面的对比记录、节点差异和复测结果留存下来，才能在下一步决定是刷新缓存、同步配置，还是回滚源站规则。