蜘蛛抓取頁面时，遇到 404 通常只是放弃目前地址；遇到 5xx 或請求超时，情况會不太一样：它拿不到有效内容，還可能反复重试。如果错誤集中在某些栏目或某些时段，抓取预算會被浪費在等响應上。這篇文章整理一套偏运维和运营结合的自查思路。
為什么 5xx 比 404 更容易拖住抓取
404 表達的是“這個地址不存在”，蜘蛛记錄後一般會降低對该地址的訪問。5xx 表達的是“服務器暂时無法處理”，蜘蛛通常理解為临时故障，可能過一段時間再来。問题在于，如果同一個地址持續 5xx，或者大量地址同时超时，蜘蛛會降低對站点的整体信任：它不知道下一次来能不能拿到内容，抓取频率和覆盖范围都可能受到影响。
把 5xx 当成“临时”来處理是對的，但前提是它真的短暂。如果连續几天都是同一批 URL 报错，對蜘蛛来说就不再是临时故障。
先分清错誤類型，再找原因
不同狀態碼指向的問题不一样，混在一起看容易誤判。
- 500 Internal Server Error：應用代碼異常、資料库连接失敗、配置错誤，通常需要看應用日誌。
- 502 Bad Gateway：網關或代理连不上後端，常见于 PHP-FPM 進程不够、後端服務挂掉、CDN 回源失敗。
- 503 Service Unavailable：服務主動拒绝請求，可能是限流、维護、连接池耗尽。
- 504 Gateway Timeout：後端處理超时，常见于慢查询、外部接口卡住、脚本执行時間過長。
如果日誌里 5xx 的 URL 高度集中，比如都落在搜尋頁、篩選頁或某個詳情接口，優先排查這些頁面的查询逻辑；如果分散在全站，更可能是服務器资源或網絡层的問题。
從日誌里定位的四個角度
- 按時間看：错誤是突增還是持續？突增通常和發布、活動、爬虫集中訪問或攻击有關。
- 按 URL 看：是個別栏目還是全站？带參數的 URL 是否更容易超时？
- 按 UA 看：蜘蛛請求和用戶請求是否都报错？如果只有蜘蛛报错，可能是限流規則或 WAF 誤拦。
- 按上游看：資料库、缓存、队列、第三方接口，哪一层先出現異常。
不要只看错誤數量。一次發布後静態资源 404 和一次資料库故障 500，處理優先級完全不同。
日常自查清單
- 服務器 CPU、内存、磁盘 IO 是否有長期高位，是否有進程被 OOM 杀掉。
- PHP-FPM、應用线程池、資料库连接池是否够用，队列是否堆积。
- Nginx、網關、CDN 的超时時間是否設定合理，回源是否稳定。
- 是否對蜘蛛做了過于嚴格的频率限制，導致大量 429 或 503。
- 监控是否覆盖 5xx 比例、响應時間、抓取失敗率，而不只是服務器在线狀態。
- 發布、迁移、改配置後，是否观察過一段時間的错誤日誌。
维護窗口別直接返回 200 空頁面
計划维護时，比較稳妥的做法是返回 503，並带上 Retry-After 头，告诉蜘蛛稍後再来。直接返回 200 但内容為空，容易被当成低质頁面；返回 404 又會让蜘蛛誤以為地址失效。两者都不如明确告诉對方“現在不可用，稍後恢复”。
如果只是部分功能维護，尽量保證内容頁可訪問，把维護限制在後台或接口层，减少對抓取的影响。
把降級和重试分開處理
遇到突發流量或依赖故障时，可以提前准备降級方案：缓存舊内容、關閉非核心功能、限制复杂查询。但降級不等于把错誤頁返回给蜘蛛。能返回缓存内容就返回缓存，不能返回时用 503 加 Retry-After，比让蜘蛛一直等超时更友好。
最後，別等蜘蛛抓取量掉了才看服務器错誤。把 5xx 和超时纳入日常监控，结合日誌按 URL、時間、UA 做简單分组，很多問题在影响抓取之前就能發現。