301转向：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /af37ecc4f7c4.html
📄
301转向：异常恢复后怎样区分缓存过期与真正修复
先给结论：异常恢复后，你看到的“正常”可能来自缓存里的旧响应，也可能来自源站已经修好。区分方法是绕开中间缓存直接核对源站状态，再让缓存自然过期或用受控请求触发一次回源，比较两次结果是否一致。如果只有带缓存的路径恢复正常，而直连源站仍返回错误，说明你看到的是缓存过期，不是真正修复。
用一个假设情境把决策过程走一遍
假设你运营一个站点，某天发现 /old-page 的 301转向 在部分访问路径下返回 404，另一部分路径仍跳到正确目标。你修好了源站配置，随后再测，发现大多数请求都正常了。此时最容易犯的错误是立刻宣布修复完成。真正要问的是：这些“正常”是回源拿到的，还是缓存把之前某次成功的响应留了下来。
把两条路径分开看：一条是经过 CDN 或反向代理的公开访问路径，另一条是直接指向源站 IP 的请求路径。如果前者正常、后者异常，缓存是更合理的解释；如果两者都正常且多次请求结果稳定一致，才更接近真正修复。
哪些证据指向缓存过期，哪些指向真正修复
区分的关键不是单次结果，而是结果随时间和路径的变化方式。
- 指向缓存过期的证据：直连源站仍返回旧状态或错误状态；响应头里的缓存年龄很大；换一个没有本地缓存的网络环境结果不同；等待缓存 TTL 过后结果发生变化。
- 指向真正修复的证据：直连源站返回预期的 301 状态和目标地址；多次请求、多个网络环境结果一致；缓存过期后重新回源，结果依然是修复后的状态。
注意一个常见误判：请求量或抓取量归零，并不能单独证明修复正确。它也可能来自抓取配额调整、站点被临时限制，或日志采集本身出了问题。把“量”当作唯一依据，容易把缓存造成的假象当成修复成功。
一个可执行动作：绕开缓存做源站核对
具体动作是：用直连源站的方式请求那条 URL，只看状态码和 Location 头，不看页面渲染结果。假设源站返回 301 且 Location 指向预期目标，说明源站层面已经修好；如果源站仍返回 404 或跳到错误地址，说明公开路径上的“正常”来自缓存。
这个动作的结果直接决定下一步：源站已修好，就转为等待缓存自然过期并抽样复查；源站未修好，就回到配置层面继续排查，而不是在缓存层反复刷新。
修复后怎样确认不是又一次缓存假象
确认分两步。第一步，在缓存过期窗口之后重新请求，比较状态码、Location 和最终落地页是否与修复目标一致。第二步，换一个此前没有访问过该 URL 的网络环境再请求一次，排除本地或边缘节点残留。
如果两次结果一致且都来自源站，才可以认为修复稳定。如果只有部分节点正常，说明缓存尚未全部过期，或不同边缘节点的回源行为不一致，此时应继续观察而不是收尾。
需要留意的适用条件
这套判断依赖你能直接访问源站或获得可信的源站响应。如果站点前面有多层缓存、且你无法绕开，就只能依靠缓存年龄、响应头变化和时间窗口来间接推断，结论的确定性会下降。另外，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些与本次判断无关，不要混进来当作修复依据。
把上面几步做完，你得到的不是“看起来正常了”，而是一条能说清来源的证据链：源站返回什么、缓存何时过期、复查结果是否一致。只有这条链闭合，301转向才算真正修复。
