服務器偶尔出現 5xx，對普通訪客可能只是一次刷新就好，但對搜尋蜘蛛来说，它會被记錄成一次失敗的抓取。当失敗在短時間内反复出現，抓取端通常會主動降低對整站的請求频率，這就是常说的退避。退避本身是一種自我保護，問题在于它的恢复往往比触發慢得多。
為什么短时 5xx 會被放大
抓取端拿到的不是“刚才那几秒坏了”，而是“這個地址刚才没成功”。如果同一时段内多個 URL 都返回 5xx，判断就會從單頁問题升級為整站可用性問题。此时降低並發、拉長重訪間隔是最直接的選擇，尤其在抓取预算有限的前提下，它會把资源先投向更稳定的站点。
更麻烦的是连带效應：一次失敗的抓取不會自動补做，被跳過的 URL 可能進入更長的重试周期。如果這批 URL 恰好是新提交的入口，就會表現為“提交了但迟迟没動静”。
常见成因可以分几類
- 應用层異常：某個接口或模板在特定參數下抛错，只有部分 URL 命中。
- 资源瓶颈：資料库连接池打满、缓存击穿、磁盘 IO 抖動，表現為間歇性 502 或 504。
- 回源與網關：CDN 回源超时、负载均衡健康检查誤判，導致节点被摘除又放回。
- 限流誤伤：防護策略把密集請求当成攻击，直接返回 5xx 而不是明确的 429。
- 發布與重啟：滚動更新期間部分實例短暂不可用。
其中限流誤伤最容易被忽略。抓取端看到的是失敗，就按失敗處理，而實际上是被自己的策略挡在了门外。
從抓取日誌里怎么確認
- 按時間聚合狀態碼，观察 5xx 是集中在几分钟内，還是全天零散分布。
- 看 5xx 的 URL 是否有共性：同一目錄、同一模板、同一參數形態。
- 對比應用日誌與網關日誌的時間戳，確認失敗發生在哪一层。
- 检查同时段的抓取频次曲线，看是否已经出現整体下降。
- 確認恢复後抓取量是否回到原有水平，還是停留在低位。
如果 5xx 只出現在特定 User-Agent 上，基本可以判定是策略問题而非容量問题。
恢复阶段的观察重点
修好故障不等于抓取立刻恢复。抓取端需要重新驗證站点的稳定性，這個观察期通常按天計。此阶段可以關注三点：抓取频次的回升斜率、成功率的稳定性、以及被跳過的 URL 是否重新出現。如果回升缓慢，可以先把精力放在内鏈入口和 Sitemap 的准确性上，让有限的抓取次數落在有效地址上，而不是反复消耗在重定向或空頁面上。
退避是结果，不是原因。先解决稳定性，再谈恢复速度，顺序反了只會反复触發。
降低影响的做法
- 對關键列表頁和詳情頁做静態兜底，動態部分失敗时仍能返回可讀内容。
- 把限流反馈改成 429 並附带 Retry-After，让抓取端知道是临时狀態。
- 健康检查区分“進程存活”和“依赖可用”，避免實例被反复摘挂。
- 發布采用分批重啟，减少同一时刻不可用的實例比例。
- 為 5xx 設定獨立告警阈值，不要和 4xx 混在一個指标里。
小结
間歇性 5xx 的危害不在于單次失敗，而在于它會被解讀為站点不稳定的信号，進而影响後續的抓取分配。日常把监控、限流反馈和發布节奏管好，比事後等待恢复更省事。恢复期間不必額外折腾，保持頁面可訪問、入口清晰，抓取节奏通常會自行回到正常区間。