抓取日誌里出現红色错誤，很多人的第一反應是去看 404。但真正影响整站抓取稳定性的，往往是 5xx 這一類服務端错誤：頁面本身没問题，地址也没變，只是服務器在蜘蛛来訪的那一刻没能把内容吐出来。這類错誤看起来偶發，如果反复出現，抓取安排就會被推迟，重要頁面的更新也容易被压後。
先分清 4xx 和 5xx 的意义
4xx 表示“這個地址不對”，蜘蛛收到後一般會逐渐减少對它的訪問；5xx 表示“這個地址是對的，但我現在给不了你”，蜘蛛通常會保留並稍後再试。两者的處理方向完全不同：前者要清理或修正地址，後者要修服務器與程序。把 5xx 当成死鏈去删，或者把 404 当成临时故障一直等，都會让問题拖下去。
5xx 常见的几個来源
- 應用超时：接口或頁面渲染時間過長，超過網關的等待上限。
- 資料库连接池耗尽：並發稍高就開始排队，蜘蛛刚好撞上排队高峰。
- 缓存失效後的回源風暴：缓存集体過期，後端一瞬間被打满。
- 後端服務重啟或發布：滚動更新期間部分請求直接失敗。
- CDN 回源失敗：邊缘节点拿不到源站内容，對外统一返回 5xx。
- 防護與限流規則：把来自搜尋蜘蛛的訪問当成異常流量拦掉。
自查步骤
- 先從服務器日誌或搜尋後台的抓取错誤里，按狀態碼和時間段把 5xx 單獨筛出来，別和 4xx 混在一張表里看。
- 看分布：是集中在某几個栏目、某個接口，還是全站随机出現。集中說明是特定代碼路径的問题，分散則更像资源或容量問题。
- 對照時間轴：把错誤高峰和發布時間、备份任務、批量脚本、流量活動對齐，很多“偶發”其實是有規律的。
- 复現：用同样的地址、同样的 User-Agent 手動請求几次，观察响應時間與返回头，確認是否只在特定條件下失敗。
- 看资源：CPU、内存、连接數、慢查询、磁盘 IO，找出真正的瓶颈点。
- 修复後回看：確認一段時間内该地址不再返回 5xx，再观察抓取安排是否回到正常节奏。
监控上该盯哪些指标
只盯平均响應時間容易被掩盖問题，建议同时看：5xx 請求數占比、P95 與 P99 响應時間、超时次數、连接池等待時間、回源失敗率。给 5xx 设一個告警阈值，比如十分钟内超過某個數量就通知，比事後翻日誌要主動得多。
抓取错誤里的 5xx 不是“網站挂了”才需要關心，它更像服務器稳定性的温度計，波動變多就是一個提前预警。
處理时的優先級
優先修那些被频繁訪問的地址，也就是首頁、栏目頁、重要内容頁；低频的深层頁面可以排在其後。如果短時間内無法彻底修复，至少要让错誤返回得干净，不要一邊 5xx 一邊還在長時間等待，把连接占满會让問题扩散到其他本来正常的頁面。
几個容易忽略的细节
- 错誤頁本身不要返回 200，否則容易被当成正常内容處理。
- 發布窗口尽量避開抓取高峰，减少無谓的失敗。
- 限流規則要给搜尋蜘蛛留出白名單，別和普通爬虫一起拦。
- CDN 與源站的超时配置要匹配，否則一邊超时一邊重试，反而放大压力。
把 5xx 当成一項日常巡检指标，定期看一眼趋势，比等到抓取量明顯下滑再去排查要省事得多。服務器稳定一点，蜘蛛来的节奏才會稳定一点。