蜘蛛抓取失败时，很多人的第一反应是「是不是被屏蔽了」。实际上，日志里更常见的失败是服务器自己没答好：5xx、连接超时、响应被中断。这几类问题的处理方式差别很大，方向搞错了容易白折腾。
先把失败按响应类型拆开
看抓取日志时，别只盯着一个「失败率」，按下面三类分开统计更有用。
- 有响应但状态码不健康：5xx、403、429。蜘蛛拿到了明确答复，会据此调整自己的节奏。
- 连接层没走通：DNS 解析失败、TLS 握手失败、连接被重置。日志里常表现为超时或 EOF，蜘蛛连内容都没看到。
- 响应太慢：连接建立了，但首字节等太久，最后超时断开。看起来像没抓到，本质是服务器负载问题。
5xx：先把服务器修好，再谈抓取
5xx 是服务器明确表示自己这边出错了，和 404 不是一回事。404 说明内容不存在，通常不需要处理；5xx 属于暂时性故障，蜘蛛一般会稍后重试，但持续出现时抓取频次会明显下降。
看日志时先判断范围：
- 只集中在少数 URL：多半是某个页面模板或数据查询有问题，比如详情页调用外部接口、列表页参数触发慢查询。
- 集中在某个时间段：可能是定时任务、备份或流量高峰叠加，服务器扛不住。
- 全站铺开：数据库、应用进程池耗尽、内存不足、磁盘写满，这类要按故障处理流程走。
处理顺序建议是：先看 Web 服务器错误日志和应用日志，定位具体报错；再看数据库慢查询和连接数；最后才检查 CDN 回源配置。不要一上来就改 robots.txt 或加爬虫规则，那解决不了 5xx。
403 与拦截：先确认是谁挡的
403 大多不是蜘蛛主动放弃，而是请求在到达应用之前就被拦下。常见位置有三处：CDN 的防护规则、WAF 的 UA 与频率策略、服务器上的 IP 黑名单。找一个固定 IP 或模拟请求复现，看它在哪一层被拒绝，比在日志里反复猜要快。
如果确实是安全策略误伤，验证方式应该基于搜索引擎公布的反向解析和 IP 段，而不是简单放行某个 UA 字符串。UA 谁都能改，只靠它做白名单迟早出问题。
超时：慢在哪里比慢多少更重要
超时请求在日志里常常只有一行，看不出原因。可以临时打开慢日志，或者用命令行工具记录各阶段耗时：DNS、连接、首字节、传输。如果首字节就慢，问题基本在后端；如果传输阶段慢，多半是页面体积或带宽。
需要留意的一点是：蜘蛛有自己的超时窗口。服务器响应越慢，同一时间窗口里能完成的请求就越少，抓到的页面自然变少。这不是蜘蛛变懒，而是预算被慢响应吃掉了。
修复之后怎么确认真的好了
- 观察日志里 5xx 与超时的比例，连续几天回落到接近零，才算稳定。
- 看抓取频次与成功请求数是否逐步回升。通常不会立刻恢复，需要一个过程。
- 确认抓到的页面是正常内容，而不是错误页返回了 200——这种「软性错误」比真实错误更难发现。
- 把这次的触发条件写进监控告警，而不是等下一次再从日志里翻。
抓取异常的排查顺序，说到底就是先服务器、再网络、最后才是抓取策略。顺序反了，改多少规则都没用。