测试死链接，错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2425f1a4d215.html
📄
测试死链接，错误只在特定时段出现时怎样捕捉短暂证据
当死链接错误只在特定时段出现，第一步不是立刻改页面，而是先固定证据：用固定时间窗、带时间戳的响应记录和可对照的请求头，把“错误发生的时间”与“错误发生的条件”分开。只有拿到能复查的短暂证据，才能判断是源站短时故障、缓存或限流造成，还是链接本身真的失效。
先用一个假设情境，把“偶发”变成可比较的时段
假设某站点在每天凌晨两点到四点之间，部分商品详情页返回 404，白天复测又正常。这个现象本身不能证明链接已死，也不能证明服务器故障。合理做法是先建立一个最小观测集：选取三到五个出问题的 URL，记录它们在错误时段的响应状态、响应时间、返回内容长度和响应头中的关键字段。
为了捕捉短暂证据，可以安排定时请求，把每次响应写入带时间戳的日志。重点不是追求高频抓取，而是保证同一 URL 在错误时段与正常时段都有记录。若某次请求返回 404，但响应体仍是站点模板而不是错误页，说明它可能来自缓存或边缘节点，而不是源站永久删除。若响应头显示由某个中间层生成，也要保留该字段，后续排查方向会完全不同。
区分三种常见来源，再决定下一步查哪里
短暂错误通常落在三类来源中，证据形态不同，下一步动作也不同。
- 源站短时异常：错误时段内多个不相关 URL 同时返回 5xx 或 404，正常时段恢复。此时应查服务器日志和发布记录，而不是逐个改链接。
- 缓存或中间层返回旧状态：同一 URL 在不同节点或不同请求头下结果不一致，响应头带有缓存相关字段。此时应核对缓存规则和刷新记录。
- 链接目标确实被移除：错误时段和正常时段都返回 404，且响应体是明确的未找到页。此时才进入链接替换或跳转处理。
这三种情况的共同点是：单次扫描结果都不足以定论。只有当同一 URL 在不同时段的表现可对照，才能排除“刚好碰上一次故障”的误判。
固定请求条件，避免把变量当成结论
捕捉短暂证据时，请求条件必须尽量一致。至少固定 URL、请求方法、User-Agent、来源页和是否携带 Cookie。若错误只在登录态下出现，而匿名请求正常，说明问题与权限或会话有关，不能按死链接处理。
一个实际动作是：在错误时段和正常时段各跑一轮相同请求，把结果并排保存。若错误时段返回 404，正常时段返回 200，且两次请求头一致，那么下一步应查该时段的源站日志或发布记录。若两次请求头不一致，则应先统一请求条件再复测，否则后续所有判断都建立在不同前提上。
还要注意 robots.txt 的抓取限制不等于可靠的索引移除。即使某条链接被 robots.txt 禁止抓取，它仍可能出现在搜索结果中，也可能在错误时段被其他方式访问到。站点地图不保证收录，提交站点地图也不能替代对短暂错误的证据收集。
把证据交给开发或运维时，带上时间窗和对照结果
交接时不要只说“凌晨会 404”。更有效的描述是：某 URL 在假设的凌晨两点到四点窗口内，三次请求均返回 404，响应体为站点错误模板；同一 URL 在上午十点请求返回 200，响应头与错误时段基本一致。这样对方可以直接查对应时间段的日志，而不是重新猜问题。
如果错误时段内多个 URL 同时异常，优先按时间窗聚合，而不是按 URL 逐个报。聚合后若发现异常集中在一次发布、一次缓存刷新或一次网络波动附近，处理方向就会从“改链接”转为“查变更记录”。这一步的结果会直接影响下一步：确认是变更引起，就回滚或修复变更；确认是链接目标被移除，才进入替换或跳转。
短暂证据也要有停止条件，避免无限复测
捕捉短暂错误不能变成长期高频扫描。可以设定一个观察周期，例如连续观察三个相同时间窗。若三个窗口内错误稳定复现，且正常时段稳定恢复，就应把证据交给对应环节处理，而不是继续增加请求频率。若三个窗口内错误不再出现，也不能直接宣布问题已修复，只能说明该时段内未复现，仍需保留日志以便下次出现时对照。
请求量归零或某次扫描没有发现 404，不能单独证明处理正确。它还可能意味着请求被拦截、目标时段未覆盖、缓存返回了旧结果，或者扫描条件已经变化。只有在请求条件一致、时间窗明确、对照结果可复查的前提下，短暂证据才真正有用。
