死链处理方法：测试工具能访问而实际用户失败时怎样复现条件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /890b9b4c11c6.html
📄
死链处理方法：测试工具能访问而实际用户失败时怎样复现条件
先给结论：当测试工具显示可访问、真实用户却失败时，不要急着改死链规则，而要把“工具成功”拆成可复现的条件——来源IP、User-Agent、请求方法、是否跟随重定向、是否带Cookie或登录态、解析到的节点。多数差异来自这些条件不同，而非死链处理本身失效。下面用一个假设情境把决策过程走完。
假设情境：同一批URL，工具全绿、用户全红
假设某站点把一批旧URL统一做了301跳转到新路径，运维用脚本批量请求，返回全部是200，于是判定处理完成。上线后客服收到少量反馈：从站内旧链接点进去停在报错页。此时若直接回退跳转规则，可能把已经正常的多数路径一起弄坏。更稳的做法是先复现“用户失败”的最小条件。
复现的第一步不是换工具，而是换身份。工具的请求通常无Cookie、固定User-Agent、直连源站；用户请求带浏览器标识、可能带登录态、可能经过CDN或负载均衡。把这三项逐一改成用户侧条件，观察哪一项改变后结果翻转。翻转的那一项，就是真正的分界线。
先分清是“请求到不了”还是“到了但被拒绝”
两种失败在日志里长得完全不同，处理动作也相反：
- 请求到不了：DNS解析到旧IP、CDN节点未刷新、源站某台机器规则未同步。表现是超时或连接被重置，源站访问日志里根本没有这条记录。
- 到了但被拒绝：源站或中间层返回403、404、410或跳转循环。表现是源站日志有记录，状态码与工具结果不一致。
判断依据是源站访问日志与CDN日志的时间戳能否对上。如果工具请求能在源站日志里找到、用户请求找不到，问题在链路前置环节；如果两者都能找到但状态码不同，问题在服务端按条件分支的逻辑。
用条件矩阵定位差异，而不是反复重试
把可疑变量列成一张对照表，每次只改一项，记录状态码和最终落地URL。假设情境中的矩阵可以这样设计：
- 基线：工具默认配置请求旧URL，记录状态码与跳转链。
- 加User-Agent：换成常见浏览器标识，其余不变。
- 加Cookie：带上登录态或地区偏好Cookie。
- 换出口：从不同网络位置请求，观察是否命中不同节点。
- 改方法：把HEAD换成GET，或反之，看是否只有某种方法被拦截。
若第2步翻转，说明服务端按User-Agent做了分支，死链规则只覆盖了默认分支；若第4步翻转，说明多节点配置不一致，需要逐节点核对而不是改规则本身。这个动作的价值在于：它把“要不要回退”变成“改哪一层”，避免整批回退带来的连带影响。
规模化后出现例外时，边界在哪里
个别样本成立不代表可以照搬。样本量小的时候，你验证的往往只是单节点、单身份、单方法；规模化后请求会分散到多节点、多身份，例外才暴露出来。可用的边界判断是：
- 如果例外集中在某一节点或某一地区，优先按节点同步处理，不要动全局规则。
- 如果例外集中在带登录态或带特定来源参数的请求，说明死链跳转与权限或参数校验的顺序有问题，应调整处理顺序而非删除跳转。
- 如果例外随时间自行减少，先确认是否与缓存过期或发布批次有关，再决定是否需要人工干预。
还要注意：抓取量或某类请求量归零，并不能单独证明处理正确——它也可能是工具换了出口、日志采样变化或缓存命中导致的。把归零当作唯一证据，容易把“没被请求到”误判成“已经处理干净”。
把复现结论写回处理流程
复现完成后，把分界条件固化进验证步骤：以后每次改死链规则，都用带用户身份的请求跑一遍关键路径，而不是只跑无状态脚本。这样下一次“工具能访问、用户失败”出现时，你能直接对照已知条件定位，而不是从头排查。回退应当是最后手段，且只回退翻转条件对应的那一层。
