网站死链：错误只在特定时段出现时怎样捕捉短暂证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /52420d3ce9c9.html
📄
网站死链：错误只在特定时段出现时怎样捕捉短暂证据
结论：如果死链错误只在特定时段出现，优先在服务端做“按小时留痕”，而不是立刻改链接或提交删除。只有当你能把报错时间、请求路径、响应状态和当时的部署或任务记录对齐，才适合决定是修链接、改规则还是回滚。若错误无法在服务端日志中复现，反而要先怀疑采集端和缓存层，不要直接认定源站链接已失效。
先区分两种成立条件：源站间歇性故障与采集端误报
第一种条件是错误时间与业务任务高度重合。例如每天凌晨批量下架商品，随后两小时内部分旧链接返回 404。此时死链是真实状态变化，处理重点应放在下架流程是否同步清理引用、是否保留跳转。
第二种条件是错误时间与采集工具的运行周期重合，而源站日志没有对应记录。这更像采集端超时、DNS 抖动或代理节点异常造成的假死链。此时改站内链接不会解决问题，应先固定采集环境。
判断依据不是单次截图，而是同一路径在错误时段和正常时段的响应差异。若正常时段返回 200，错误时段返回 404 或 5xx，且服务端日志能对应，才偏向源站问题；若服务端完全没有该请求，则偏向采集端或中间层。
捕捉短暂证据时，先固定时间基准和请求标识
不要只记录“昨天下午出过死链”。把服务器、采集端和任务调度器的时间统一到同一时区，并在日志中保留请求 ID、完整路径、查询串、响应码、响应耗时和上游地址。这样做的实际动作是：在错误复现窗口内导出原始日志，而不是依赖事后回忆。
结果会直接影响下一步：如果同一请求 ID 在服务端只出现一次且返回 404，说明源站确实产生过死链；如果同一时间窗内服务端没有该请求 ID，则下一步应检查采集端重试策略和网络出口，而不是修改站点链接。
用最小化复现代替大规模扫描
短暂错误往往被高频扫描淹没。更有效的做法是选一条已知在特定时段出错的路径，在错误窗口前后各做一次请求，并保留完整响应头和响应体。若错误窗口只有几分钟，可以用定时任务按分钟请求该路径，但只针对少量路径，避免把复现变成压测。
假设某站点每天 02:00 到 02:10 执行缓存清理，某条旧链接在这十分钟内返回 404，其他时间返回 200。这里的数字只用于说明比较方法：把清理任务开始时间、缓存层日志和源站日志对齐后，若 404 只出现在清理任务之后，就应优先检查缓存回源和链接映射，而不是直接删除该链接。若对齐后仍无法解释，再考虑采集端假死。
一个反例：服务端日志齐全，也不能直接证明链接该删
即使服务端日志显示某路径在特定时段返回 404，也不能单独据此删除链接或提交移除。404 可能来自临时下架、权限校验、灰度发布或上游超时后的兜底响应。若这些解释未被排除，删除链接可能把可恢复页面变成真正不可访问。
因此，只有在确认该路径已无对应内容、且没有合理恢复计划时，才进入移除或跳转决策。否则应保留观察，先修复造成间歇性 404 的触发条件。
下一步动作：按证据强度决定修链接、改规则还是继续观察
- 先导出错误时段的服务端原始日志，保留请求 ID 和响应码。
- 把日志时间与部署、缓存清理、批量任务时间对齐。
- 若源站日志能复现，修触发条件或补跳转；若不能复现，先查采集端和中间层。
- 只有在确认内容已不存在且无恢复计划时，才处理链接移除或跳转。
这样做的结果是：你得到的是可复查的时间线，而不是一次性的死链截图；下一步该修哪一层，由时间线决定，而不是由单次报错决定。若时间线仍无法对齐，继续保留观察窗口比立即批量修改更稳妥。
