抓取日志里出现红色错误，很多人的第一反应是去看 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 当成一项日常巡检指标，定期看一眼趋势，比等到抓取量明显下滑再去排查要省事得多。服务器稳定一点，蜘蛛来的节奏才会稳定一点。