死链处理：测试工具能访问而实际用户失败时怎样复现条件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /150d62fe4690.html
📄
死链处理：测试工具能访问而实际用户失败时怎样复现条件
测试工具返回 200，不等于真实用户能打开。多数情况下，差异来自测试工具默认不发送或自动补全了某些请求条件——Cookie、Referer、Accept-Encoding、UA、DNS 解析路径或落地节点。要复现用户失败，先收集失败用户的原始请求特征，再用同一组条件重放，而不是反复刷新测试工具。
先分清两种“能访问”不是一回事
测试工具能访问，通常只证明服务器对某一种请求形态返回了成功状态。实际用户失败，可能是请求根本没到同一台源站。常见分叉有三类：
- 解析层：用户所在网络把域名解析到旧 IP、CDN 边缘节点或劫持页，测试工具走的是另一条解析路径。
- 传输层：中间设备对特定 UA、Referer 或 TLS 指纹做了拦截或重置，而测试工具的特征不在拦截名单里。
- 应用层：源站按 Cookie、登录态、地区或缓存键返回不同内容，测试工具恰好命中了正常分支。
这三类的取证动作不同。解析层要比对用户侧解析结果，传输层要抓完整请求头，应用层要拿到用户的 Cookie 与完整 URL。混在一起排查，会一直得到“我这边正常”的结论。
用可核对的证据区分解释
让失败用户提供三样东西：完整 URL（含查询串）、浏览器网络面板里该请求的状态码与响应头、以及该域名在用户设备上的解析结果。这三项能直接切开大部分歧义。
如果用户侧解析到与测试工具不同的 IP，问题在解析或 CDN 调度，不在死链本身。如果解析一致但状态码不同，重点看请求头差异。如果状态码相同而页面内容不同，通常是缓存键或地区分支问题。
一个假设例子：测试工具以 curl -I 请求某旧文章地址，得到 301 到新地址；用户点击后停在空白页。核对发现用户请求带了 Accept-Encoding: br，而边缘节点对 Brotli 响应的处理异常，返回了空体。此时“测试工具能访问”是真的，但结论“链接没坏”是错的——失败发生在响应体，不在状态码。
保留、改写还是退出：按失败位置决定
复现条件之后，处理方式取决于失败发生在哪一层，而不是取决于链接“看起来”是否还能打开。
保留并修正适用于源站仍返回正确内容、只是某类请求条件被误伤的情况。例如拦截规则过宽、缓存键漏掉了某个维度。动作是收窄规则或补全缓存键，然后让失败用户用原条件重试；重试成功才说明修的是同一问题。
改写为明确跳转适用于内容已迁移、旧地址只剩历史价值的情况。301 要指向与旧内容语义最接近的新地址，而不是首页。改写后仍需用失败用户的原始条件复测，因为跳转目标也可能命中同类拦截。
退出索引并返回 410适用于内容永久删除、且没有等价替代页的情况。此时要接受一个事实：robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，两者都不能替代正确的状态码。410 比 404 更明确，但同样不承诺移除时间。
复现失败的最小动作清单
- 记录失败用户的完整 URL、UA、Referer、Cookie 关键项、Accept-Encoding 和解析 IP。
- 在测试环境用同一组条件重放，先只改一项，观察状态码与响应体是否变化。
- 若改 UA 后失败消失，检查 WAF 或边缘规则；若改解析后失败消失，检查 DNS 与 CDN 调度。
- 确认修复后，让原失败用户在同一网络、同一设备上重试，而不是由测试方代验。
第三步的结果直接决定下一步：拦截类问题改规则，解析类问题改调度，应用类问题改缓存或代码分支。跳过重放直接全站重定向，会把一个局部拦截问题扩散成大规模跳转，反而掩盖真实原因。
哪些现象不能单独作为结论
请求量下降、抓取量归零或某个统计指标变化，都不能单独证明死链处理正确。这些现象还有别的合理解释：统计口径变更、抓取预算重新分配、上游流量本身减少。把它们当作唯一证据，容易在错误的方向上继续加固。
HTTPS 也不保证安全无漏洞或排名，它只解决传输加密这一层。死链处理是否生效，最终要看失败用户在原条件下能否打开，而不是看某个工具的单次成功响应。
