网站死链查询：错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ad1bad39abd9.html
📄
网站死链查询：错误只在特定时段出现时怎样捕捉短暂证据
先给结论：不要试图“复现”整个故障，而要把查询改造成按时间点执行、自动留档的探针。只有当你能拿到带时间戳的响应码、重定向链和响应体片段，才谈得上判断是源站间歇故障、边缘缓存过期，还是抓取调度恰好撞上维护窗口。下面用一个假设情境把决策过程走完。
先判断这是间歇故障还是窗口性故障
假设某站每天凌晨 2:00 到 2:20 做数据同步，期间部分详情页返回 500，白天一切正常。此时“网站死链查询”得到的白天结果会全部是 200，看上去毫无问题。要区分两种情况：
- 间歇故障：同一 URL 在任意时段都可能失败，失败与时间无固定关系，通常指向应用层不稳定或某个后端节点异常。
- 窗口性故障：失败集中在固定时段，且与发布、备份、同步、缓存刷新等运维动作重合，指向可预期的资源争用。
区分依据不是失败次数，而是失败时间戳的分布。把一周的失败记录按小时聚合，如果柱状图只在某几个小时隆起，窗口性故障的可能性明显更高；如果均匀散布，则应先查应用日志而不是继续加探针。
把一次性查询改成带时间戳的定时探针
普通爬虫跑完就结束，无法回答“凌晨两点发生了什么”。需要做的是把查询变成定时任务，并对每个 URL 记录四类字段：请求时刻、最终状态码、重定向跳数、响应体前若干字节。响应体片段很关键，因为 500 页面可能带着框架自己的错误 ID，这比状态码更能定位到具体服务。
一个可执行的动作：先取 30 到 50 个代表性 URL（首页、栏目页、详情页、带参数页各若干），用 curl -w "%{http_code} %{time_total} %{url_effective}\n" -o body.txt 这类方式每 5 分钟跑一轮，输出追加到带日期的文件。动作的结果是：你得到一条按时间排列的状态序列，而不是一个瞬时快照。下一步取决于这条序列——如果失败点能对齐到某个整点或某次部署，就可以去比对发布记录；如果对齐不上，才需要扩大 URL 样本。
用对照点排除“查询本身造成的假象”
短暂错误有时不是站点造成的，而是查询方式造成的。同一时段内，如果探针请求频率过高，可能触发源站限流；如果探针走的是与真实用户不同的出口 IP 或 UA，可能命中不同的缓存层。要排除这些解释，加两个对照点：
- 同一 URL 在同一时刻，用两种不同频率请求（例如 1 次/分钟与 1 次/5 分钟），看失败是否随频率上升。
- 同一 URL 在同一时刻，从两个不同网络位置请求，看失败是否只在其中一侧出现。
如果只有高频侧失败，问题更可能在限流或防护策略；如果只有某一侧失败，问题更可能在 DNS 解析或边缘节点。这个判断会直接改变下一步：前者应调整探针节奏，后者应把证据交给负责网络或 CDN 的一方，而不是继续改页面。
把证据整理成可交接的时间线
拿到数据后，不要只发一张失败列表。按时间线整理成三列：时刻、现象、当时正在发生什么。现象要写清状态码与重定向终点，正在发生什么则来自发布记录、备份计划或缓存刷新日志。这样交接时对方能直接判断是“代码在特定输入下出错”还是“基础设施在特定时刻被占用”。
需要注意：抓取量或请求量在某个时段归零，不能单独证明站点恢复正常。归零也可能是探针被限流、DNS 缓存过期或任务被调度器跳过。要确认恢复，至少需要状态码、响应体片段和对照点三者一致。
什么条件下才值得回退或改动
如果时间线显示失败严格跟随某次变更，且变更可撤销，回退是合理的第一步。如果失败与变更无关，只是与资源高峰重合，回退不会解决问题，应该改为调整任务时间或增加资源。判断条件可以写得很具体：失败时段与变更时间重合超过多数失败记录，且回退后同一探针在下一个周期不再出现相同状态码——满足这两点，回退才是有依据的动作；否则先修探针的取样方式。
最后提醒一点：robots.txt 的抓取限制不等于可靠的索引移除，短暂错误消失也不等于页面一定被正确处理。真正能支撑决策的，是带时间戳、可复查、有对照的响应记录，而不是某一次查询的结果。
