入口页跑在共享主机、前面挂着 CDN 或者 WAF 限速规则时，抓取高峰很容易撞上 429 Too Many Requests，或者带 Retry-After 的 503。很多人只看一眼状态码就下结论“蜘蛛不来了”。其实限速影响的是抓取节奏和 URL 发现速度，和“URL 被丢掉”并不是一回事。
先把 429 和普通 5xx 分开看
- 429 Too Many Requests：语义上就是“你请求太多”，属于临时性拒绝，不是服务器故障。
- 503 + Retry-After：服务暂时不可用，但明确告诉抓取端“过一会儿再来”。
- 没有 Retry-After 的 5xx：原因可能是后端崩溃、超时、配置错误，抓取端只能自己判断退避多久。
这三种状态在抓取端眼里差别不小：前两种更像“先让一让”，第三种更像“这里现在不稳定”。但共同点是，只要入口页没返回可解析的 HTML，这一轮就解析不出里面的链接。
搜索蜘蛛遇到限速一般会怎么处理
- 降低对该主机或该目录的抓取速率，把请求摊到更长的时间窗口里。
- 按一定间隔重试，间隔可能随连续失败次数拉长，也就是常说的退避。
- 在限速持续期间，从该主机上新发现 URL 的机会变少，因为入口页本身就取不到。
- 如果限速拖到几周甚至更久，抓取配额被挪去别处的可能性会上升。
需要注意，不同搜索引擎的具体策略并不一致，退避时长、重试次数、是否读取 Retry-After 都有差异。把某一家的行为当成通用规则，容易判断失误。
Retry-After 填多少合适
Retry-After 支持两种写法：秒数，或者一个 HTTP 日期。写法本身没有争议，值填多少才是问题。
- 填几秒通常没意义，抓取端仍会按自己的节奏退避，很可能马上又撞上限速。
- 填一整天，可能让原本很快能重试的抓取被推后很久。
- 比较现实的做法是先按实际限速阈值估算，从几十秒到十几分钟这个区间试，再看日志调整。
如果你并不确定限速阈值，与其硬填一个大数字，不如先把后端压力降下来，让入口页能稳定返回 200。
里面的目标链接还会不会被发现
要分两件事看。
- 这一轮解析：入口页 429 或 503，HTML 没拿到，里面的目标链接这一轮自然不会被解析出来。
- 已经发现的 URL：已经进入待抓队列的 URL 不受这次限速影响，仍可能按原计划被抓取。
所以限速主要卡的是“新 URL 的发现速度”，而不是把已经发现的 URL 全部作废。反过来说，如果你的入口页长期只返回限速状态，那蜘蛛池里那些只靠入口页暴露的目标 URL，就会长期停留在“未被发现”的状态。
排查顺序
- 看边缘或源站日志，确认 429 的来源是搜索蜘蛛，还是自己的压力测试、监控探针。
- 确认限速规则是按 IP、按 UA 还是按路径触发，很多默认规则会把爬虫和普通流量混在一起算。
- 确认是不是 CDN 或 WAF 的通用防刷规则命中，而不是后端真的过载。
- 对已知的搜索引擎 UA 单独放行或单独设阈值，别和普通流量共用一个桶。
- 把入口页做成可缓存或静态化，减少每次请求都打后端。
如果你用的是抓取统计工具，可以顺带看一下响应码分布和“主机状态”一类的指标，确认限速是零散发生还是成片出现。零散几次不用慌，成片持续才需要动手。
蜘蛛池场景下的几个判断
- 入口页数量多、每个入口页访问频次低时，限速的成本会被放大，可以拆到多个主机或域名分担。
- 不要用 429 当作“防搜索蜘蛛”的常规手段，短时间能省资源，长期会让 URL 发现明显变慢。
- 把 429 和“被处理”“被降权”混为一谈没有意义，它首先是个抓取调度问题。
入口页返回 429 不代表目标 URL 被判死，只代表这一轮没被读到。真正要盯的是限速是偶发还是常态。
处理思路其实很朴素：先让入口页稳定、快速地返回可解析的 HTML，再谈里面的链接能不能被稳定发现。限速问题不解决，再多的入口页也只是在互相挤占同一份请求额度。