永久重定向方法：异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1d2b6fe0ca85.html
📄
永久重定向方法：异常恢复后怎样区分缓存过期与真正修复
结论有前提：如果异常恢复后看到的状态码、跳转目标或抓取结果发生变化，而服务器配置、回源响应和缓存控制头都没变，那更可能是缓存过期，不是真正修复。只有当回源响应本身已经正确、并且缓存层确认回源取到了新响应时，才能把观察到的变化归因于修复。
缓存过期与真正修复的可区分证据
两者最核心的差别在于：变化是否来自回源。缓存过期只是旧副本被淘汰，回源内容可能一直没变；真正修复则是回源那一层先变了，缓存只是被动跟随。
- 回源响应：直接请求源站或绕过 CDN 的地址，看永久重定向的状态码和目标是否已经正确。若回源仍返回旧目标，缓存层再新也只是旧内容的重新分发。
- 缓存年龄与命中状态：响应头里的
Age、X-Cache、CF-Cache-Status一类字段能显示这次响应是命中还是回源。命中状态下看到的变化，不能直接当成修复证据。 - 多节点一致性：同一 URL 从不同地区或不同出口请求，若部分节点已变、部分未变，通常指向缓存副本尚未全部过期，而不是修复本身不稳定。
- 配置变更时间：把回源配置的修改时间与首次观察到正确响应的时间对齐。若正确响应出现在修改之前，缓存过期的解释更合理。
一个会让结论失效的反例
如果源站配置改对了，但缓存层仍按旧的 Cache-Control 或 Expires 保存着旧响应，那么清除缓存后看到的正确跳转，可能只是清缓存这个动作的结果，而不是源站修复本身在生效。更麻烦的是，如果回源响应里同时带着较长的 max-age 和 s-maxage，缓存会继续把旧副本当作新鲜内容分发，此时从缓存层观察到的任何变化都不能证明永久重定向已经真正修好。
所以，判断修复是否成立，不能只看浏览器或单一节点。必须先确认回源响应正确，再确认缓存层已经回源取到这份正确响应，两个条件同时满足，结论才成立。
一个注明假设的短例子
假设某 URL 原本应永久重定向到 A，异常期间跳到了 B，运维修改了源站配置后，从本地浏览器访问看到跳回 A。此时若源站直连仍返回 B，而缓存节点返回 A，说明本地看到的是缓存过期后的旧副本，不是修复完成。反之，若源站直连和多个缓存节点都返回 A，且 Age 很小或标记为回源，才更接近真正修复。
下一步动作：先验证回源，再验证缓存传播
先绕过缓存直接请求源站，确认永久重定向的状态码和目标已经正确。若回源仍不正确，继续修源站，不要清缓存，否则只是把旧内容重新铺一遍。若回源已经正确，再观察缓存层是否在预期时间内回源取到新响应，并检查 Cache-Control 是否允许缓存保存这份新响应。只有当回源正确、缓存也确认取到新响应后，才把这次变化记录为修复完成，并继续观察后续请求是否稳定返回同一目标。
