永久重定向，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /93e36bab4bfa.html
📄
永久重定向，源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站返回 301 正常、边缘节点却给出 302、404 或超时，你要保留的不是“源站没问题”这一句话，而是能证明差异发生在哪一跳的证据链。核心是让下一环节的人能复现你看到的现象，而不是相信你的转述。下面用一个假设情境串起整个过程。
假设情境：同一 URL，两种结果
假设你负责的站点把 /old-page 永久重定向到 /new-page。你在源站直接请求，得到 301 和正确的 Location。你从办公网络请求，得到 302 并跳到一个无关地址。此时源站配置没变，差异只可能出现在中间的边缘节点、缓存或解析路径上。你要做的第一件事不是改配置，而是固定证据。
关键判断依据：同一时刻、同一 URL、不同请求路径返回不同状态码，说明问题不在源站逻辑，而在请求经过的某一跳。这个判断成立的前提是你确实固定了时间、URL 和请求路径，否则两种结果可能只是配置在两次请求之间被改过。
要保留的第一类证据：请求与响应的原始记录
不要只截图浏览器地址栏。浏览器会缓存、会跟随跳转、会隐藏中间响应。你需要能显示每一跳的原始记录。
- 完整响应头，尤其是状态码、
Location、Cache-Control、Age、Via、X-Cache这类能暴露边缘行为的字段。 - 请求头，尤其是
Host、User-Agent、Accept-Encoding，以及你用来指定解析目标的参数。 - 请求时间，精确到分钟，并注明时区。跨时区团队核对时，时间戳对不上会让整条证据链失效。
实际动作：用命令行工具分别向源站地址和域名发起请求，把两次输出完整保存。结果如何影响下一步——如果两次响应头只在边缘相关字段上不同，你就把排查范围收窄到边缘节点；如果连源站请求也开始异常，说明问题已经上移，边缘证据只是旁证。
要保留的第二类证据：解析与节点归属
边缘异常常见于解析指向了不同节点，或部分节点缓存了旧规则。你需要记录请求实际落到了哪里。
- 记录域名当前的解析结果，以及你请求时用的解析目标。两者不一致时，说明你的测试可能没打到出问题的那个节点。
- 记录响应头里能标识节点或缓存命中的字段。不同服务商字段名不同，按你实际看到的记录，不要套用别人的字段名。
- 如果条件允许，从两个不同网络分别请求同一 URL，保留两份结果。这能区分“全局异常”和“特定路径异常”。
注意一个容易误判的点：某个节点返回旧结果，不代表规则没生效，也可能是该节点缓存尚未过期。此时 Age 字段比状态码更能说明问题。把 Age 和响应时间一起记下来，能帮你判断是缓存问题还是配置分发问题。
要保留的第三类证据：配置变更与时间线
边缘异常经常和一次未记录的变更同时发生。你需要一条能对齐的时间线。
- 重定向规则的当前内容，以及你确认它生效的时间点。
- 最近一次规则、缓存策略或解析变更的时间，以及变更人。
- 你观察到异常的最早时间，和你第一次成功复现的时间。
假设你的时间线显示：规则在上午十点发布，异常在十点零五分出现，而缓存 TTL 是十分钟。这时“规则没生效”和“旧缓存未过期”都能解释现象。你不能只凭时间接近就断定是配置错误，需要再看 Age 是否接近 TTL。这一步决定你是去改规则，还是去等缓存过期或主动清理。
证据到手后，先做哪一个动作
按代价从低到高排序，而不是按直觉直接改规则。
- 用带解析目标的请求再打一次出问题的节点，确认异常可复现。不可复现时，先怀疑本地缓存或测试路径，而不是边缘故障。
- 对比源站与边缘的响应头差异。若差异只在缓存字段，优先处理缓存；若
Location本身不同，才回到规则分发。 - 只有在确认规则未正确分发后，才重新发布或回滚规则，并记录这次动作的时间，作为下一轮证据的起点。
这里有一个取舍：立即清理全部缓存能快速让现象消失，但会破坏你正在收集的证据。如果问题还在影响线上流量，先保留一份异常响应再清理；如果影响可控，先收集完整再动手。选择哪条路，取决于你能否在清理后仍复现问题。
哪些现象不能单独作为结论
抓取量下降、某个状态码统计归零、站点地图里的 URL 不再出现，这些都不能单独证明边缘处理正确。它们还可能来自抓取预算变化、统计口径调整或正常的缓存刷新。要判断处理是否有效，仍要回到源站与边缘的响应对比。另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这两点在你整理证据时不要混入重定向异常的判断。
把上述证据按“请求记录、节点归属、时间线”三类归档，并注明每份证据的获取时间和路径，下一位接手的人就能沿着同一条路径复现，而不是从零猜测。
