服务器偶尔出现 5xx，对普通访客可能只是一次刷新就好，但对搜索蜘蛛来说，它会被记录成一次失败的抓取。当失败在短时间内反复出现，抓取端通常会主动降低对整站的请求频率，这就是常说的退避。退避本身是一种自我保护，问题在于它的恢复往往比触发慢得多。
为什么短时 5xx 会被放大
抓取端拿到的不是“刚才那几秒坏了”，而是“这个地址刚才没成功”。如果同一时段内多个 URL 都返回 5xx，判断就会从单页问题升级为整站可用性问题。此时降低并发、拉长重访间隔是最直接的选择，尤其在抓取预算有限的前提下，它会把资源先投向更稳定的站点。
更麻烦的是连带效应：一次失败的抓取不会自动补做，被跳过的 URL 可能进入更长的重试周期。如果这批 URL 恰好是新提交的入口，就会表现为“提交了但迟迟没动静”。
常见成因可以分几类
- 应用层异常：某个接口或模板在特定参数下抛错，只有部分 URL 命中。
- 资源瓶颈：数据库连接池打满、缓存击穿、磁盘 IO 抖动，表现为间歇性 502 或 504。
- 回源与网关：CDN 回源超时、负载均衡健康检查误判，导致节点被摘除又放回。
- 限流误伤：防护策略把密集请求当成攻击，直接返回 5xx 而不是明确的 429。
- 发布与重启：滚动更新期间部分实例短暂不可用。
其中限流误伤最容易被忽略。抓取端看到的是失败，就按失败处理，而实际上是被自己的策略挡在了门外。
从抓取日志里怎么确认
- 按时间聚合状态码，观察 5xx 是集中在几分钟内，还是全天零散分布。
- 看 5xx 的 URL 是否有共性：同一目录、同一模板、同一参数形态。
- 对比应用日志与网关日志的时间戳，确认失败发生在哪一层。
- 检查同时段的抓取频次曲线，看是否已经出现整体下降。
- 确认恢复后抓取量是否回到原有水平，还是停留在低位。
如果 5xx 只出现在特定 User-Agent 上，基本可以判定是策略问题而非容量问题。
恢复阶段的观察重点
修好故障不等于抓取立刻恢复。抓取端需要重新验证站点的稳定性，这个观察期通常按天计。此阶段可以关注三点：抓取频次的回升斜率、成功率的稳定性、以及被跳过的 URL 是否重新出现。如果回升缓慢，可以先把精力放在内链入口和 Sitemap 的准确性上，让有限的抓取次数落在有效地址上，而不是反复消耗在重定向或空页面上。
退避是结果，不是原因。先解决稳定性，再谈恢复速度，顺序反了只会反复触发。
降低影响的做法
- 对关键列表页和详情页做静态兜底，动态部分失败时仍能返回可读内容。
- 把限流反馈改成 429 并附带 Retry-After，让抓取端知道是临时状态。
- 健康检查区分“进程存活”和“依赖可用”，避免实例被反复摘挂。
- 发布采用分批重启，减少同一时刻不可用的实例比例。
- 为 5xx 设置独立告警阈值，不要和 4xx 混在一个指标里。
小结
间歇性 5xx 的危害不在于单次失败，而在于它会被解读为站点不稳定的信号，进而影响后续的抓取分配。日常把监控、限流反馈和发布节奏管好，比事后等待恢复更省事。恢复期间不必额外折腾，保持页面可访问、入口清晰，抓取节奏通常会自行回到正常区间。