5xx 与超时为什么比 429 更值得警惕
429 通常是一个明确的信号：服务器在说“我现在跟不上，请慢一点”。蜘蛛收到 429 后一般会降低速率并稍后重试，抓取总量会下降，但发现的路径本身还在。
5xx 和超时的含义不同，它往往意味着请求没有真正到达能返回内容的那一层。常见来源包括：应用层异常、数据库连接池耗尽、上游服务超时、负载均衡健康检查失败、CDN 回源超时。对蜘蛛来说，这些页面“现在拿不到”，而它并不知道是暂时的还是永久的。
更麻烦的是连锁反应。抓取频率被压低之后，即便服务器几分钟后恢复正常，蜘蛛的降速策略也可能延续一段时间。表现就是：故障十分钟，抓取量下滑却持续数小时。
用日志建立一份可对比的基线
要判断是不是异常造成的回落，先要有平时正常的样本。建议按天统计下面几项，形成最近两周的基线：
- 蜘蛛请求总量，以及 2xx、3xx、4xx、5xx、超时各自的占比；
- 首字节时间的均值与 P95，不要只看均值；
- 每个主要栏目被请求的 URL 数量，而不只是请求次数；
- 新发现 URL 的数量，即首次出现在日志里的 URL。
只有总量是不够的。如果总量持平但新 URL 数骤降，说明蜘蛛在反复抓旧页面而不推进发现，这通常和入口页面响应慢、或某一层节点持续异常有关。
区分全局异常和局部异常
把 5xx 按路径前缀分组，往往能看出问题范围。全站普遍升高偏向基础设施；集中在某个目录，则更可能是该模块的代码或数据问题。局部异常持续时间长的话，可以考虑先把这部分链接从主要入口临时移出，减少无效请求，等修复后再放回。
恢复期该注意什么
- 先确认稳定性，再考虑提速。观察 24 小时内 5xx 占比是否回到基线，再谈抓取恢复。反复抖动比一次性故障更容易让降速持续。
- 不要靠频繁提交 Sitemap 催促。Sitemap 只负责告知 URL 存在，不保证抓取节奏。故障未解除时反复提交，反而增加无效请求。
- 保留正常返回的入口页。首页、栏目页尽量保证可用，这些页面是发现新 URL 的主要通道。深层内容可以慢，但入口不能断。
- 核对 robots.txt 与 Sitemap 的可访问性。这两个文件如果也返回 5xx，蜘蛛可能按保守策略处理，影响面比单个页面大得多。
把抓取量下降直接归因于算法调整或权重变化，是最常见也最浪费时间的误判。多数情况下，先去日志里看响应码分布，能得到更接近事实的答案。
预防：让异常尽早被看见
与其等抓取回落后再排查，不如把几个动作前置：对 5xx 和超时设置阈值告警；对首字节时间做趋势监控；给蜘蛛请求单独打标，方便和普通用户流量区分开。数据库连接池、缓存命中率、回源带宽这几项，经常是超时的真正源头。
另外，抓取回落不总是坏消息，有时只是站点规模或内容更新节奏变化的自然结果。判断时要结合新 URL 数量、有效内容更新量一起看，单看请求总量容易得出错误结论。
整体思路可以概括为：用日志建立基线，用分组定位范围，用稳定性而不是提交次数换回抓取节奏。