测试死链接，正常与异常结果怎样区分

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

测试死链接，正常与异常结果怎样区分

测试死链接时，正常结果不是“所有链接都返回 200”，而是每个链接的返回状态与它的真实用途一致：该跳转的跳转、该返回 404 的返回 404、该被屏蔽的返回 403。异常结果则是状态码与预期不符，或者工具把网络错误、超时、反爬拦截误报成死链。多人协作时，最容易出现的误解是把“非 200 一律算死链”，这会让大量正常链接被误判，导致返工。

为什么“非 200 就是死链”是常见误解

HTTP 状态码分几类：2xx 表示成功，3xx 表示重定向，4xx 表示客户端错误，5xx 表示服务端错误。对死链接检测来说，真正需要处理的是 404、410 这类“资源不存在”，以及 5xx 这类“服务器出错”。而 301、302 是正常的跳转，403 可能是权限或反爬拦截，429 是请求过于频繁，这些都不等于内容消失。

另一个原因是检测工具本身会引入噪声。批量请求太快时，服务器可能返回 429 或直接断开；需要登录的页面会返回 403 或跳转到登录页；CDN 或 WAF 可能对陌生 UA 返回验证页。这些现象看起来像死链，实际上是访问条件不满足。如果不区分，就会把“工具没拿到正常响应”当成“链接真的坏了”。

正常结果与异常结果的判断依据

判断时看三件事：状态码、最终落地 URL、页面内容是否与链接意图一致。可以按下面的对照来分：

软 404 尤其容易被漏掉：服务器返回 200，但页面正文写着“内容已删除”。这种情况工具的状态码检查发现不了，需要人工抽查或结合页面标题、正文关键词判断。

多人协作时怎样减少误判和返工

交付前先约定判定规则，而不是各自凭感觉处理。建议在任务说明里写清楚：哪些状态码算必须修复，哪些算记录观察，哪些算忽略。例如：

  1. 404、410、5xx 标记为必须处理，并附上出现位置和原始链接。
  2. 301、302 记录跳转目标，检查是否跳向无关页面或形成循环。
  3. 403、429、超时统一标记为待复核，注明检测时间和请求方式，不直接派给内容或开发修改。
  4. 对疑似软 404 的 200 页面，附上页面标题或正文片段作为证据。

这样做的价值在于：修复的人拿到的是可复现的结果，而不是一句“这里有个死链”。复核的人也能根据记录判断是链接问题、权限问题还是检测方式问题。

一个可执行的复核步骤

假设检测报告里有一条链接返回 403。不要立刻判定为死链，按下面顺序复核：

  1. 用浏览器无痕窗口直接打开该链接，看是否正常显示内容。如果能打开，说明 403 很可能来自工具请求特征，而不是资源消失。
  2. 用 curl -I 查看响应头，确认状态码和 Location 字段。命令示例：curl -I -L https://example.com/page。这里 -L 表示跟随跳转，能看清最终状态。
  3. 如果返回 301 或 302，记录最终 URL，检查是否与原链接主题一致。跳转到首页通常意味着原内容已不存在，需要更新链接或做重定向修正。
  4. 如果返回 404，再确认是否是大小写、参数或路径拼写问题。修正后重新请求，看是否恢复 200。
  5. 如果多次请求都返回 5xx，且其他页面正常，则更可能是该页面依赖的服务或脚本出错，交给开发排查。

这个步骤的适用条件是：你有权直接访问目标页面，且目标不是必须登录才能查看的资源。如果链接位于登录墙后，403 或跳转登录页属于预期行为，应改用带会话的检测方式，而不是按死链处理。

检查项与判断结果

交付前可以用这份清单快速自检：状态码是否与预期一致；跳转链是否超过合理层数；最终页面是否与原链接主题匹配；200 页面是否出现“不存在”“已删除”等字样；待复核项是否注明检测条件和时间。全部通过，说明这次测试结果可以交付；如果有待复核项没有说明条件，接收方就无法判断，返工概率会明显上升。

下一步，把这份判定规则写进协作说明，并对本次报告中的 403、429、超时项做一次集中复核，再决定哪些进入修复列表。

图1 图2
nginx