入口頁跑在共享主机、前面挂着 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，就會長期停留在“未被發現”的狀態。

排查顺序

1. 看邊缘或源站日誌，確認 429 的来源是搜尋蜘蛛，還是自己的压力測試、监控探针。
2. 確認限速規則是按 IP、按 UA 還是按路径触發，很多預設規則會把爬虫和普通流量混在一起算。
3. 確認是不是 CDN 或 WAF 的通用防刷規則命中，而不是後端真的過载。
4. 對已知的搜尋引擎 UA 單獨放行或單獨设阈值，別和普通流量共用一個桶。
5. 把入口頁做成可缓存或静態化，减少每次請求都打後端。

如果你用的是抓取統計工具，可以顺带看一下响應碼分布和“主机狀態”一類的指标，確認限速是零散發生還是成片出現。零散几次不用慌，成片持續才需要動手。

蜘蛛池场景下的几個判断

• 入口頁數量多、每個入口頁訪問频次低时，限速的成本會被放大，可以拆到多個主机或域名分担。
• 不要用 429 当作“防搜尋蜘蛛”的常規手段，短時間能省资源，長期會让 URL 發現明顯變慢。
• 把 429 和“被處理”“被降權”混為一谈没有意义，它首先是個抓取調度問题。

入口頁返回 429 不代表目标 URL 被判死，只代表這一轮没被讀到。真正要盯的是限速是偶發還是常態。

處理思路其實很朴素：先让入口頁稳定、快速地返回可解析的 HTML，再谈里面的連結能不能被稳定發現。限速問题不解决，再多的入口頁也只是在互相挤占同一份請求額度。