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

网站死链检查：测试工具能访问而用户失败时怎样复现条件

先别急着改死链状态码。测试工具能访问、真实用户却失败，通常意味着“访问成功”这件事在不同条件下并不等价。复现的关键不是再跑一次工具，而是把工具与用户之间所有可能不同的条件逐项固定下来——网络出口、DNS解析、请求头、Cookie与登录态、CDN节点、跳转链路。只有当你能让本地复现出同一失败，才有资格判断这条链接该保留、改写还是退出。

先分清“谁在访问”：工具与用户的差异清单

测试工具往往从一个固定机房出口发起请求，用户则来自各地运营商、不同设备。以下差异最容易造成“工具通、用户挂”：

• 出口IP与地理位置：某些源站或CDN按地域、按ASN返回不同结果，工具所在机房可能恰好命中白名单或缓存节点。
• DNS解析路径：工具可能使用公共DNS并命中较新的记录，用户本地DNS缓存仍指向已下线的旧IP。
• 请求头与UA：部分服务对空UA或爬虫类UA放行，对浏览器UA反而触发防护或重定向。
• Cookie、登录态与权限：工具匿名访问拿到200，用户带着过期会话访问却落到登录页或403。
• 协议与跳转：工具允许跟随跳转，用户浏览器在某一跳被拦，或从HTTPS被跳到HTTP后失败。

把这几项写成一张对照表，逐项标注“工具值”和“用户值”，分歧点往往会直接暴露出来。

把分歧转成可核对的项目：复现的最小动作

复现不是凭感觉，而是控制变量。一个可执行的做法是：用curl或浏览器开发者工具，按用户侧的条件重放请求，并记录每一步的响应。

1. 固定请求头：把工具默认UA换成用户真实浏览器的UA，观察状态码是否变化。
2. 固定DNS：用curl --resolve把域名强制解析到用户侧实际拿到的IP，绕开工具本地缓存。
3. 固定会话：带上用户真实的Cookie或登录态重放，而不是匿名请求。
4. 记录跳转链：关闭自动跟随跳转，逐跳查看每个3xx的Location指向哪里。
5. 换出口再试：从与用户相近的运营商或地域发起一次请求，确认是否为节点相关。

如果换成用户UA后状态码从200变为403，那问题就不在“链接是否存在”，而在访问控制策略，处理方向完全不同。

三种取舍的适用前提：保留、改写还是退出

复现出失败条件后，才轮到决策。三种处理各有成立前提，不要一刀切。

保留

适用于失败只出现在特定边缘条件、主体内容仍对大多数用户可达的情况。例如仅某个旧节点返回异常，而主链路正常。此时应记录该条件并持续观察，而不是立刻删链接。前提是你已经确认失败范围有限，且能说清触发条件。

改写

适用于目标资源已迁移、但存在等价替代页的情况。把死链指向新地址，或改成指向分类页。前提是替代页与用户原本想找的内容确实对应，而不是为消除死链随便指一个页面。改写后要重新用用户侧条件验证一次。

退出

适用于资源确实不存在、且没有合理替代的情况。此时移除入口链接比保留一个必然失败的跳转更干净。前提是已排除“只是工具和用户条件不同”这一可能——否则你删掉的其实是一条正常链接。

一个假设例子：同一链接的两种结论

假设一条旧活动页链接，测试工具返回200，用户点击却看到404。按上面步骤复现后发现：工具匿名访问命中CDN缓存中的旧副本，而用户带登录态访问穿透缓存直达源站，源站上该页面已删除。

这个例子里，工具的成功是缓存造成的假象。正确的下一步不是修CDN，而是确认页面是否真的下线：若已下线且无替代，退出该链接；若有新活动页，则改写指向新地址。假设缓存TTL为一天，那么在这一天内工具仍可能持续报“正常”，这正是不能只依赖工具结论的原因。

验证与记录：让结论可被别人复核

复现条件一旦确定，把它写进检查记录：出口、DNS、UA、会话状态、跳转链、最终状态码。这样其他角色可以按同样条件重跑，而不是各说各话。需要提醒的是，抓取量或某项检测结果归零，并不能单独证明你的处理正确——它也可能只是缓存刷新、工具更换出口或统计口径变化造成的。判断处理是否到位，要看用户侧条件是否已能稳定复现出预期结果。当你能用同一组条件让失败稳定出现、再让修复后稳定消失，这条链接的取舍才算真正有依据。