服务器日志里出现 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 更有用。