死链接检测：测试工具能访问而实际用户失败时怎样复现条件
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4da0f6e7f463.html
📄
死链接检测：测试工具能访问而实际用户失败时怎样复现条件
先别急着改链接。把失败用户的请求原样搬进一个可重复的复现环境，逐项对齐网络出口、请求头、登录态和重定向路径，直到测试工具也复现失败；复现成功后再定位是哪个条件被工具默认绕过了。
先记录失败请求的原始条件
测试工具通常只发一个干净的 GET，而真实用户带着浏览器缓存、Cookie、Referer、User-Agent，还可能经过公司代理或移动网络。要让失败可复现，第一步是固定这些变量。
- 从用户侧拿到完整 URL，包括查询串和片段前的所有参数。
- 记录请求方法、是否带 Cookie、是否已登录、来源页地址。
- 记录网络环境：办公网、家庭宽带、移动数据、是否走代理或 VPN。
- 记录时间点和当时的响应：状态码、跳转链、页面提示文案。
把这些写成一个可以逐条比对的清单。假设用户从站内搜索页点击进入后失败，而工具直接输入 URL 成功，那么 Referer 与登录态就是第一批要怀疑的条件。
把工具默认忽略的条件逐项加回去
多数检测工具默认不发送 Cookie、不跟随全部重定向、不模拟代理。复现时按下面顺序补齐，每补一项就重跑一次，观察结果在哪一步从成功变为失败。
- 带上用户当时的 Cookie 和 Authorization 头。
- 把 User-Agent 换成用户实际使用的浏览器标识。
- 开启完整重定向跟随，并记录每一跳的状态码和 Location。
- 让请求经过同一出口网络，或至少使用同一地区的出口 IP。
- 补上 Referer，模拟从站内页面点击进入。
如果加入 Cookie 后立即失败，说明问题出在鉴权或会话状态，而非链接本身；如果只有换出口 IP 才失败，则要查 CDN 或防火墙的地域与频率策略。
区分状态码相同但结果不同的情况
工具和用户都拿到 200，却一个正常一个报错，常见原因是响应内容不同。此时不能只看状态码。
- 软 404：服务端返回 200，页面内容却是错误提示。工具判定为正常，用户看到失败。
- 重定向循环：工具设置了跳转上限后放弃，用户浏览器则卡在循环里。
- 内容协商差异：不同 Accept 或语言头返回不同页面，其中一种指向失效资源。
- 混合内容拦截：页面本身可访问，但其中引用的资源被浏览器按安全策略阻止。
验证方式是对比两次响应的正文摘要和关键头部，而不是只看第一行状态码。若正文不同，下一步就是固定请求头，让两边拿到同一份内容。
用一次受控请求验证假设
假设失败只发生在登录后且经过移动网络。构造两个对照请求：一个带登录 Cookie 走移动出口，一个不带 Cookie 走办公出口。如果只有前者失败，就能把范围收窄到会话与出口的组合，而不是链接失效。
这个动作的价值在于：它把“用户说打不开”变成“满足条件 A 和 B 时必然失败”。之后无论是修链接、调会话有效期，还是改 CDN 策略，都能用同一组条件回归验证，避免改完一处却在另一个条件下复发。
复现后要确认的边界
复现成功不等于问题已解决。还要确认修复是否覆盖了真实用户路径，而不是只让工具通过。若涉及抓取限制，注意 robots.txt 的抓取限制不等于可靠的索引移除；站点地图不保证收录；HTTPS 也不保证安全无漏洞或排名。不同搜索引擎对同一处理的支持情况须分别核查。只有当失败条件在真实网络与真实会话下不再出现，才算完成这一轮死链接检测的闭环。
