死链检测方法：错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4c2db835c47a.html
📄
死链检测方法：错误只在特定时段出现时怎样捕捉短暂证据
当死链只在特定时段出现，最有效的做法不是提高扫描频率，而是把检测对象从“全站链接”缩小到“可能在该时段被访问或改动的少数入口”，同时让检测结果自带时间戳、请求上下文和响应链。否则你抓到的只是一次瞬时失败，无法判断它属于偶发网络抖动、定时任务引发的资源缺失，还是缓存或发布流程造成的短暂 404。下面以你手里的一份访问日志或监控记录为对象，说明怎样把它变成可执行的处理方案。
先判断这是间歇故障还是检测方式造成的假象
短暂错误有两种常见来源：一是链接真的只在某些时刻不可用，二是你的检测工具本身在该时段受到限速、超时或并发挤占。区分它们要看三组证据。
- 时间分布：错误是否集中在固定分钟或固定任务窗口，例如每天同一时段、每次发布之后。固定窗口更指向定时任务、缓存刷新或上游接口限流。
- 响应类型：同一 URL 在不同时段返回 404、403、超时还是连接重置。404 指向资源真的消失，超时和重置更可能是网络或服务端压力。
- 请求来源：错误是否只出现在某个出口 IP、某个爬虫 UA 或某个内网段。若换一个来源就正常，问题更可能在检测侧而非页面侧。
假设一份监控记录显示，某分类页的列表链接只在每天凌晨批量任务运行后的十分钟内返回 404，其余时间均为 200。这个分布说明它不是长期死链，而是资源在该窗口被临时替换或未就绪。此时若直接把这些 URL 全部下线，反而会误删正常链接。下一步应改为在该窗口内做定点复测，而不是扩大全站扫描。
把检测窗口对准变化发生的前后，而不是全天平铺
捕捉短暂证据的关键是让检测时间与业务变化时间对齐。你需要先找出该时段内发生了什么：发布、数据同步、缓存过期、证书或配置更新。然后按下面顺序建立最小检测集。
- 从日志中筛出该时段返回非 200 的 URL，去掉明显的外部链接和用户输入错误。
- 对每个 URL 记录首次出现错误的时间、持续时长、恢复时间，以及恢复时返回的状态码。
- 在变化发生前五分钟、发生中、发生后五分钟各请求一次，保留完整响应头和重定向链。
- 把结果与同时段的服务端日志或发布记录对照，确认错误是否与某次操作重合。
这个动作的结果会直接决定下一步：如果错误只在变化发生中短暂出现、随后自动恢复，处理重点应放在发布流程的原子性和缓存预热；如果错误在变化后持续存在，才需要按常规死链修复处理。若错误在三个时间点都出现，说明它并非时段性，之前的判断前提需要推翻。
让证据可复查：记录什么才算够用
短暂错误最容易在事后被质疑“当时是不是你看错了”。因此每次请求至少要留下以下字段，缺一项都会让复查变难。
- 绝对时间：带时区的完整时间戳，而不是“凌晨”这类描述。
- 请求上下文：请求方法、完整 URL、是否跟随重定向、使用的 UA 和出口 IP。
- 响应链：状态码、响应头中的缓存与重定向字段、最终落地 URL。
- 判定依据：这次请求是自动任务还是手动触发，超时阈值设为多少。
可以用一段最小脚本固定这些字段，例如在命令行里对目标 URL 做带时间戳的请求并保存响应头：
curl -sS -o /dev/null -D - -w "%{http_code} %{time_total} %{time_starttransfer}\n" "https://example.com/category/page"
这里的 <...> 若出现在页面源码中，应确认它是被当作示例文本还是真实标签；若是后者，检测时可能因解析差异得到不同结果。记录字段统一后，复查者才能判断某次 404 是页面真实返回，还是工具在超时后自行判定的失败。
用对照请求排除工具和网络的干扰
在得出“该时段存在死链”之前，至少做一次对照。对照请求的目的不是证明页面正常，而是确认检测路径本身没有引入错误。
- 同时请求一个已知稳定的同域页面，观察它是否在同一时刻也失败。
- 从不同网络出口或不同 UA 请求同一 URL，比较状态码是否一致。
- 把超时阈值调长或调短，看错误数量是否随之剧烈变化。若变化明显，原结果更多反映的是超时设置。
如果对照页面也在同一时段失败，那么问题更可能出在网络、DNS 或服务端整体可用性，而不是单个链接失效。此时把结论写成“某时段站点不可达”比写成“发现若干死链”更准确，后续动作也应转向可用性排查。只有当对照正常、目标 URL 稳定失败，且失败与业务变化时间重合，才可以把该 URL 列入待修复死链。
根据证据决定是修复、观察还是改检测
捕捉到短暂证据后，处理方式取决于错误的可复现程度和影响范围。
- 可稳定复现且影响用户访问：按真实死链处理，修正链接或补上重定向，并在修复后于同一时段复测。
- 只在变化窗口出现、随后恢复：优先调整发布或缓存流程，保留监控但不必立即改动链接。
- 只在特定检测来源出现：修改检测配置，避免把工具限制误判为页面错误。
- 无法复现且无用户影响证据：记录观察，不急于改动，等待下一次同窗口出现再比较。
假设你按上述方法在某次发布窗口内抓到 12 个 404，其中 10 个在发布完成后恢复，2 个持续到第二天。合理的下一步是只修复那 2 个持续失败的 URL，并把发布窗口的缓存预热加入检查项，而不是把 12 个都当作长期死链。这样既避免误伤，也让下一次同窗口检测有明确的比较基线。若你无法确认某个 URL 是否属于长期失效，最稳妥的动作是保留原始响应记录，在下一次同窗口复测后再决定是否修改。
