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 數量、有效内容更新量一起看，單看請求總量容易得出错誤结论。
整体思路可以概括為：用日誌建立基线，用分组定位范围，用稳定性而不是提交次數換回抓取节奏。