在抓取日志里看到搜索蜘蛛的请求集中返回 429，往往不是蜘蛛主动放弃，而是服务器或中间层把请求挡了回去。429 表达的是速率层面的拒绝，不是内容不存在，也不是永久不可访问。它会影响 URL 发现之后的实际抓取覆盖，因此值得单独观察。
429 和 503 要分开看
503 通常意味着服务端暂时无法处理请求，可能来自过载、维护窗口或后端异常；429 的含义更具体：服务本身能处理，只是来源的请求速率超出了当前允许的范围。两者的恢复方式不同。503 需要等资源恢复；429 需要调整速率，或者把被误限的来源放行。把它们混在一起统计，会看不清问题出在容量还是策略。
限速常见来自哪一层
- CDN 或 WAF 的频率规则，按 IP、按路径或按 UA 触发。
- 源站的限流模块，例如按连接数、按请求速率设置的阈值。
- 安全插件把高频访问的蜘蛛 UA 当成异常流量处理。
- 共享主机对单 IP 并发上限的限制。
这些层通常不区分搜索蜘蛛和普通高频访问，只要触发阈值就会被拦。抓取量下降时，先确认是策略拦截还是真的资源不足，再决定处理方式。
Retry-After 与退避节奏
返回 429 时如果带上 Retry-After，相当于告诉蜘蛛多久之后再来。这个头能让退避有依据，减少密集重试带来的额外压力。缺少这个头时，退避节奏只能由蜘蛛自行判断，恢复时间可能被拉长，也可能出现刚恢复就再次触发限速的来回拉扯。
限速不是一次性事件，而是一段需要观察的速率协商过程。
怎样确认限速真的在发生
- 按状态码统计日志，看 429 是否集中在特定时段或特定路径。
- 看响应时间。被限速的请求往往响应极短，因为请求没有进入实际处理就返回了。
- 按来源 IP 分组，确认是单一 IP 触发还是整体被限。
- 查看 CDN 控制台的拦截统计，区分边缘拦截和回源阶段的问题。
恢复节奏的调整方向
- 把已验证的蜘蛛来源加入白名单，但白名单要有更新机制，来源段会变化。
- 对抓取来源放宽并发限制，而不是直接全部放行。
- 把批量任务、备份、其他采集工具安排在蜘蛛活跃时段之外，减少叠加压力。
- 恢复后先看 429 比例是否下降，再看抓取请求量是否回升，不要一放开就期待回到满速。
容易被忽略的细节
限速阈值如果设得很低，正常抓取也会长期踩线；设得太宽，又起不到保护作用。更实际的做法是按路径区分：列表页、分页这类被抓频率高的路径适当放宽，后台、搜索接口、下单接口严格限制。这样既能保住 URL 发现的入口，也不会让真正需要保护的接口暴露在过高并发下。
另外，429 只反映速率，不反映内容质量变化。抓取量下降时，如果排除了限速因素，仍需回到抓取日志、Sitemap 覆盖和内链入口去核对，不要把所有抓取波动都归到限速上。