URL重定向，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ddfd282ec4e5.html
📄
URL重定向，源站正常而边缘节点异常时应保留哪些证据
直接回答：源站返回正常并不等于用户拿到正常结果，当边缘节点异常时，你至少要保留三类证据——从不同网络位置观察到的响应头（尤其是状态码与 Location）、边缘缓存与回源日志中同一次请求的对应记录、以及能证明源站当时行为的直接响应。缺任何一类，都无法把“源站正常”和“边缘异常”这两句话同时钉死。
下面用一个明确标注为假设的情境串联决策过程，所有数字只用于说明比较方法，不代表任何真实站点。
假设情境：源站 200，边缘却给 301 循环
假设你运营一个站点，把 /old-a 重定向到 /new-a。源站配置检查无误：直接请求源站 IP 并带 Host 头，返回 301，Location 指向 /new-a，而 /new-a 本身返回 200。但从你自己的办公网络访问线上域名，浏览器报“重定向次数过多”。
此时最容易犯的错是立刻去改源站规则。但源站已经证明自己正确，真正要问的是：边缘节点在转发或缓存这条重定向时，发生了什么，以及你手上的证据能不能支撑下一步动作。
证据一：从多个网络位置固定响应头
单一位置的一次 curl -I 不足以定性。边缘异常常常是节点级或区域级的，你在一个网络里看到 301 循环，换一个网络可能完全正常。动作是：至少从三个不同网络位置（例如办公网、移动网络、以及一个你控制的远程主机）各执行一次只看响应头的请求，把状态码、Location、以及缓存相关头（如 Age、Cache-Control、X-Cache 一类边缘标识）原样记录下来。
结果如何影响下一步：如果三个位置表现一致，问题更可能在边缘配置或缓存层，而非某个坏节点；如果只有部分位置异常，说明是节点或区域问题，此时改源站反而会破坏本来正常的路径。是否一致，直接决定你是去查边缘配置还是去报节点故障。
证据二：把边缘日志与回源日志按同一次请求对齐
响应头只能说明“结果”，日志才能说明“过程”。你需要保留两组日志并尝试对齐：边缘侧记录（哪个节点、命中还是回源、返回了什么状态码和 Location）与源站侧记录（同一时间窗口内是否收到回源请求、源站返回了什么）。
关键是对齐的时间戳和请求标识。如果边缘日志显示某次请求“命中缓存并返回 301”，而源站日志里根本没有对应的回源记录，那说明异常来自边缘缓存中的旧副本，而不是源站。反过来，如果边缘确实回源了、源站也返回了正确 301，但边缘吐给用户的是另一个 Location，问题就在边缘改写或转发环节。
这一步的证据价值在于：它能区分“缓存了错误结果”和“转发时改错了结果”，这两种原因的修复动作完全不同。
证据三：证明源站当时的真实行为
“源站正常”这句话必须可复查，否则只是记忆。保留方式是：绕过边缘直接请求源站，记录完整的响应头，并注明请求时间、Host 头、以及你使用的源站地址。同时保留当时的源站配置快照或版本记录。
注意一个容易混淆的点：源站返回 200 或 301 只说明那一刻的响应，不代表边缘看到的就是这个结果。如果源站配置在排查期间被人改动过，而你没有任何快照，那么“源站一直正常”就无法成立，后续所有推断都会松动。
哪些现象不能单独作为结论
排查中会出现一些看似有力的信号，但它们各自都有别的合理解释：
- 某个监控点的请求量突然归零，可能是该点自身网络问题，也可能是边缘拒绝服务，不能单独证明边缘处理正确或错误。
- 清空边缘缓存后问题消失，可能是缓存副本问题，也可能是清缓存动作顺带触发了配置重载，需要日志佐证。
- 换一个浏览器后正常，可能是浏览器缓存，也可能是该浏览器走了不同解析路径，不能直接归因于边缘。
这些现象可以作为线索，但必须和上面三类证据交叉验证后才能下结论。
按证据决定下一步动作
把三类证据摆在一起后，通常会落到两种成立条件之一：
- 证据指向边缘缓存旧副本：多位置响应不一致、边缘日志显示命中缓存且无回源、源站日志无对应记录。此时动作是定向刷新该路径的缓存，并保留刷新前后的响应头对比，确认刷新是否真的改变了结果，再决定是否需要调整缓存策略。
- 证据指向边缘转发或配置改写：多位置一致异常、边缘有回源且源站返回正确、但边缘输出不同。此时动作是核对边缘的重定向规则与源站规则的叠加关系，保留两份配置的对照，确认是哪一层在改写 Location。
无论落到哪一种，先保留证据再动手，是因为一旦你改了配置或清了缓存，原始状态就不可复现，后续也无法判断修复是否真正解决了根因，还是只是暂时掩盖了现象。
