在抓取日誌里看到搜尋蜘蛛的請求集中返回 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 覆盖和内鏈入口去核對，不要把所有抓取波動都归到限速上。