测试死链接，异常恢复后怎样区分缓存过期与真正修复

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

测试死链接，异常恢复后怎样区分缓存过期与真正修复

先给结论：异常恢复后只看一次“现在能打开”不能判定真正修复，必须把“响应状态”和“内容版本”分开验证。缓存过期通常表现为同一URL在不同节点、不同请求头下结果不一致；真正修复则表现为源站稳定返回目标状态，且内容与修复目标一致。下面用一个假设情境把决策过程串起来。

假设情境：一次修复后结果反复

假设你负责的站点有一批内链指向已下线的旧页面，你用301把它们统一指向了新栏目。上线后你抽查发现，有的URL返回200，有的仍返回404，还有的返回301但跳转目标不对。你重复测试三次，结果每次都不一样。这时最可能的解释不是“修复没生效”，而是缓存层、CDN节点或浏览器本地缓存仍在提供旧结果。要区分，先固定测试条件，再看源站。

第一步：固定请求条件，排除干扰变量

不同工具默认的请求头、重定向跟随策略、缓存绕过方式不同，结果自然不同。你需要统一三件事：

请求头中是否带 Cache-Control: no-cache 或 Pragma: no-cache，强制回源。
是否跟随重定向。跟随与不跟随会看到不同的状态码序列。
测试节点。同一URL从不同地区、不同网络请求，可能命中不同缓存副本。

动作：用同一工具、同一请求头、同一节点连续请求同一URL五次，记录每次的状态码和响应体首行。如果五次结果不一致，说明中间层有缓存或负载均衡分发到了不同源。下一步不是继续改配置，而是先定位是哪一层在返回旧结果。

第二步：看响应头，判断是谁在回答

响应头比状态码更能说明问题。重点看这几个字段：

Age：大于0说明响应来自缓存，数值是缓存已存活的秒数。Age很大且内容仍是旧的，基本可判定缓存未过期。
X-Cache、CF-Cache-Status、X-Proxy-Cache：不同服务用不同字段标记命中或回源。命中缓存且内容旧，说明需要刷新缓存而不是改源站。
Last-Modified 和 ETag：与修复时间对比。如果Last-Modified早于你的修复时间，说明返回的是旧版本。
Location：301或302的目标地址是否是你配置的新地址。目标不对，说明规则本身有问题，不是缓存。

动作：把响应头完整保存下来，和修复前的记录对比。如果Age持续增长但内容不变，下一步是刷新对应缓存；如果Age为0或没有缓存标记但内容仍旧，下一步是检查源站文件或应用逻辑是否真的更新了。

第三步：直接回源验证，绕开所有中间层

要判断源站是否真正修复，必须绕开CDN、反向代理和浏览器缓存。可行方式包括：

用带随机查询参数的URL请求，例如 /old-page?cachebust=你的时间戳。多数缓存会把带不同查询串的请求视为不同资源，从而回源。注意：如果源站对查询参数做了规范化或忽略处理，这个方法可能失效，需要先确认。
直接请求源站IP并带上 Host 头。这能跳过DNS和CDN，但要求你能访问源站且源站接受该Host。若源站有防火墙或只允许特定回源IP，此路不通。
在源站服务器本地用 curl -I http://127.0.0.1/old-page 请求。这排除了所有网络中间层，看到的就是应用真实输出。

动作：如果回源结果是正确的301或200，而公网请求仍是旧结果，问题在缓存层，下一步是刷新缓存并等待其生效。如果回源结果本身就是错的，问题在源站，下一步是检查重定向规则、文件替换或应用路由配置。

第四步：区分“缓存过期”与“真正修复”的判定表

把观察到的证据按下面两组归类，不要凭单次结果下结论：

偏向缓存过期：回源正确、公网错误；Age大于0且持续；不同节点结果不同；带随机参数请求正确；清除本地缓存后浏览器正确。
偏向真正修复：回源正确、公网也正确；Age为0或很小；不同节点结果一致；带随机参数与不带参数结果相同；连续多次请求状态码稳定。

还有一类容易被误判为“已修复”的情况：缓存恰好过期，返回了正确结果，但源站规则并未真正改对。例如你只改了CDN边缘规则，源站仍返回404，边缘缓存过期后又会暴露问题。验证方法是强制回源后再看一次，如果回源仍错，就不能算修复。

第五步：把验证变成可复查的动作

真正修复需要留下可复查的证据，而不是“我刷新了一下就好了”。建议按以下顺序操作：

记录修复前每个URL的状态码、响应头、跳转目标。
执行修复动作，记录修复时间和改动内容。
强制回源请求每个URL，记录回源结果。
刷新缓存后，从至少两个不同节点请求，记录公网结果。
间隔一段时间后再次请求，确认结果稳定，没有回退到旧状态。

如果第五步出现回退，说明之前的“修复”只是缓存过期造成的假象，需要回到源站重新检查。只有回源结果和公网结果在多次、多节点请求下都一致，才能判定为真正修复。这个判定过程不依赖某个特定工具，依赖的是把请求条件和响应证据固定下来，再逐层排除。