死链检测，错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b9686578ad0b.html
📄
死链检测，错误只在特定时段出现时怎样捕捉短暂证据
如果死链只在每天某个时段、某次批处理或某次发布后短暂出现，单次抓取很可能什么都看不到。可行的做法是把“检测”从一次性动作改成带时间戳的连续采样，并把响应头、跳转链和页面正文片段一起留存；但有一个反例会让这个结论失效：当错误由访问者身份、来源IP或登录状态决定时，单纯拉长采样时间并不能复现，必须换用带相同请求条件的采样方式。
先判断这是时段问题还是条件问题
时段性错误和条件性错误的外表很像，都是“有时好有时坏”。区分方法是看错误是否随绝对时间移动：把同一组URL在一天内分散请求，如果错误集中在固定时间窗，属于时段问题；如果错误集中在某个来源、某个User-Agent或带特定Cookie的请求上，属于条件问题。前者靠增加采样次数解决，后者靠复制请求条件解决。搞错方向，再多抓取也只是重复得到正常结果。
一个假设例子：某栏目页在每天凌晨批量更新缓存后返回502，持续约几分钟。若只在上午检测，会得到全部正常；若按每十分钟一次采样并记录状态码和时间戳，就能看到502集中在凌晨那一小段。这里的数字只是说明采样密度和窗口的关系，不代表任何真实站点的表现。
把证据分成三层，缺一层就无法复查
短暂证据容易在事后被质疑，因为它不可重现。要让它可复查，至少保留三层信息：
- 时间层：请求发起时刻、响应返回时刻、时区。没有时区的时刻在跨团队协作时几乎无法对齐。
- 响应层：状态码、响应头中的缓存与跳转字段、最终落地URL。只看状态码会漏掉软404和跳转链断裂。
- 内容层：响应正文的一小段特征文本或标题，用来证明当时返回的确实是错误页，而不是被中间层替换的正常页。
三层齐全后，你可以把“我见过它坏过”变成“在某个时刻、某条请求路径上，返回了这样的响应”。下一步的排查方向由响应层决定：如果跳转链在某一跳断掉，问题在跳转配置；如果状态码正常但内容层是错误页，问题在应用层。
连续采样要控制成本，而不是无限加频率
提高频率能提高抓到短暂错误的概率，但代价是请求量和日志噪音。更实际的做法是分层采样：对已知容易出问题的关键URL保持较高频率，对全站其余URL保持低频巡检。关键URL的选取依据是它们是否处在发布流程、缓存刷新或外部依赖的路径上，而不是凭感觉挑几个首页。
采样时还应避免把所有请求压在同一个出口。单一出口的失败可能来自本地网络或对方限流，会被误读成站点死链。分散出口并记录出口标识，才能在事后排除“是我这边的问题”。这一步的结果会直接影响下一步：如果错误只出现在某个出口，优先查网络与限流；如果所有出口都复现，才转向站点自身。
一个会让结论失效的反例
如果错误与访问者身份绑定，例如登录后才出现的失效跳转、特定地区才命中的错误页，那么无论采样多密、持续多久，匿名请求都不会复现。此时时间采样是无效的，必须换成带相同会话、相同来源条件的请求。判断线索是：错误报告来自特定人群或特定入口，而你的自动采样从未命中。遇到这种情况，先复制请求条件，再谈采样频率。
另一个容易误判的情形是：某段时间抓取量或请求量归零。归零可能来自检测任务本身失败、调度未执行、出口被封，而不代表站点那段时间没有死链。把归零直接当成“问题已消失”会跳过必要的复核。
下一步动作：先固化窗口，再决定退出还是保留
拿到带时间戳的证据后，第一步不是立刻删页面，而是把错误窗口和业务动作对齐：那个时段发生了什么发布、缓存刷新或外部调用。对齐之后，你才能判断这是可修复的短暂故障，还是旧内容、旧系统、旧合作关系退出过程中必然出现的过渡状态。
如果确认某批旧URL只在过渡期短暂报错，且它们仍有访问价值，应保留并修复跳转；如果确认它们已无价值且错误稳定复现，再进入退出流程。注意，用robots.txt限制抓取并不等于可靠的索引移除，站点地图也不保证收录，这两点不能作为“已经处理干净”的依据。把采样脚本、时间窗和判定条件记录下来，下一次同类异常出现时，你比较的是同一套证据，而不是重新猜一遍。
