服務器日誌里出現 5xx、超时或者连接被拒，是站点运营中很常见的現象。看到這類记錄，先別急着下结论，更值得關注的是這次失敗属于哪一類：临时性故障和長期性故障，後續的處理方式差別很大。
一次失敗不等于這個 URL 被放弃
抓取是一個持續的過程，不是一次性動作。某個 URL 這一轮没抓成功，通常只是被放回队列，過一段時間再试。真正影响後續的是失敗的規律性：偶尔一次超时，和连續几天返回同样的错誤，给出的信号完全不同。
所以判断問题时，看“失敗了多少次”不如看“失敗集中在哪些 URL、持續了多久、是不是同一個狀態碼”。
不同错誤類型，處理方式不一样
连接超时與响應過慢
服務器在限定時間内没响應完，這次抓取通常會被放弃並稍後重试。偶尔發生影响有限；但如果慢查询、外部接口拖時間導致常態性變慢，重试也照样慢，抓取节奏會逐步收紧。
5xx 服務端错誤
500、502、503 這類狀態碼說明問题在服務端，一般會被当作可重试的情况。要注意 503 的语义：長期返回 503，和網站打不開没有實质区別。如果确實需要暫停抓取，配合 Retry-After 說明恢复時間會更清楚。
429 請求過多
這是被限速的信号，通常意味着触發了限速策略或防護規則。繼續试探没有意义，降低抓取频率或者检查規則配置更實际。
DNS 解析失敗與 SSL 握手失敗
這類問题發生在建立连接之前，连 HTTP 狀態碼都没有。域名解析異常、證书過期、SNI 配置错誤都可能造成。它們影响的是全站而不是單個 URL，恢复之前所有抓取都會失敗，值得優先监控。
403 與 401
訪問被拒绝一般不按 5xx 那样反复重试，但需要分清是防護誤伤還是有意限制。如果连正常的抓取請求都被拦，站点的可见入口就等于被人為收窄了。
重试與降频大概怎么發生
具体算法各引擎不同，但大方向比較接近：
- 失敗比例升高时，抓取速度會放慢，避免给服務器繼續加压；
- 同一個 URL 连續失敗，重试間隔會被拉長；
- 影响范围大（例如整站 5xx）时，即使恢复，也需要一段時間才回到原来的抓取水平；
- 返回 404、410 這類“内容确實不在了”的信号，通常不會被当作故障反复重试。
換句话说，服務器抖動一两個小时，和连續几天間歇性 5xx，後果並不一样。後者不只是少抓了几個頁面，還會让整体抓取节奏變得保守。
失敗可能藏在中間层
排查时不要只盯着應用服務器。CDN、负载均衡、WAF 都有可能返回错誤頁，常见的情况有：源站正常但 CDN 回源失敗返回 502；防護規則把某個 UA 或高频請求拦下来返回 403。這類错誤在應用日誌里根本看不到，需要看邊缘节点的记錄。
從日誌里統計失敗
- 按狀態碼分组，先看清失敗以哪一類為主；
- 看時間分布，是集中在某几分钟，還是整天零散出現；
- 看 URL 分布，是全站性的，還是局限在某個栏目、某個接口；
- 對照同期的發布、改版、配置變更，很多問题能直接對上。
减少無谓失敗的几個做法
- 监控證书有效期和域名解析，這两項出問题往往影响全站；
- 给抓取留出资源，別让爬虫請求和高峰业務抢同一批连接；
- 检查防護與限速規則，確認没有誤伤正常抓取；
- 确實下线的頁面返回 404 或 410，不要用 200 的空頁面含糊過去；
- 给慢接口设超时，避免單個頁面把整個請求拖住。
抓取失敗多數时候是运维問题，而不是“蜘蛛不友好”。把错誤碼和發生時間看清楚，比反复提交 URL 更有用。