入口頁的抓取速度和源站承受能力之間，永遠存在一個平衡点。放得太松，蜘蛛一多源站就抖；卡得太紧，蜘蛛来两次没拿到完整内容就走了，再想叫回来要花不少時間。這篇聊的是服務端限速和並發控制，重点是怎么從日誌里找到那個平衡点，而不是套一個固定數值。

先分清三種不同的“限速”

很多站点把限速当成一個開關，其實它至少分三层，每层管的東西不一样。

• 網絡层：單 IP 的连接數、带宽。防火墙或 iptables 就能做，但對蜘蛛不太友好，容易直接掐断连接。
• 應用层：Nginx 的 limit_req、limit_conn，或者應用里的令牌桶。按每秒請求數和並發连接數控制，這是主战场。
• 业務层：資料库连接池、後端接口超时。這一层不直接拒绝蜘蛛，但請求堆积到這里，表現就是 TTFB 變長、5xx 變多。

三层是串联的。只調 Nginx 不調後端，等于把压力從门口挤到了屋里。

蜘蛛的抓取节奏和普通用戶不一样

普通用戶的流量大致是平滑的，蜘蛛不是。同一批入口頁可能在几分钟内被集中訪問，然後又安静很久。單個搜尋引擎對單個站点的並發通常不高，但如果入口域名多、搜尋引擎有好几個，叠加起来就不算小數目了。伪蜘蛛更难缠，它們往往不看 robots、不遵守频次约定，打得很凶。

所以限速規則最好按 UA 或来源特征分组，给真蜘蛛一套相對宽松的額度，其他流量走預設規則，而不是一刀切。

限速過嚴和過松，分別是什么表現

• 過嚴：日誌里 429、503 占比高；同一批 URL 反复被抓却總不完整；蜘蛛来訪频次慢慢下降，最後几天才来一次。
• 過松：後端 CPU 和資料库负载被拉到高位，正常用戶的响應也變慢，高峰期開始出現 5xx。

两種情况的共同点是：你只盯着入口頁看，是看不出来的，得把訪問日誌、後端监控和蜘蛛的抓取資料放在一起對。

怎么找到合适的阈值

1. 先临时放宽限速跑几天，记錄峰值 QPS、並發连接數和 P95 响應時間，把這張基线表存下来。
2. 在压测环境里标出源站能長期稳定承受的 QPS，實际配置取它的七成左右留余量。
3. 按 UA 分组配置：真蜘蛛一套阈值，普通流量一套阈值，未知来源最紧。
4. 限速触發时返回 429 並带上 Retry-After，不要直接断连接。
5. 每次只調整一個维度，观察一周再决定下一步，別一次改三四個參數。

429 和 503 別混着用

429 的意思是“請求太多，稍後再来”，语义清楚，配合 Retry-After 头，蜘蛛一般能理解並退避。503 更像“服務暂时不可用”，蜘蛛也會降低频次，但它可能把這段時間判断成站点整体不稳定，恢复得比 429 慢。日常限速優先用 429；如果是真在维護、後端挂了，才用 503。

還有一個邊界：如果整站對蜘蛛都返回 429，就等于告诉搜尋引擎這個站点長期不稳定，抓取频次會被整体調低，這和你想達到的效果正好相反。

减负往往比限速更根本

• 入口頁尽量静態化，別每次請求都查一遍資料库。
• 用反向代理或 CDN 挡掉重复請求，让回源量降下来。
• 给蜘蛛訪問的版本去掉無關的統計脚本和第三方资源，减少不必要的請求。
• 把 sitemap 和列表頁整理清楚，让蜘蛛少走弯路，無效爬行少了，压力自然小。

限速是兜底手段，不是效率工具。能靠缓存和静態化省掉的請求，不要指望靠限速消化掉。

几個常见的坑

• 只按 IP 限速：蜘蛛的出口 IP 會變，按 IP 限容易誤伤正常用戶，也拦不住伪蜘蛛。
• 阈值寫死後長期不動：站点内容、服務器配置都在變，限速參數也得跟着复核。
• 真蜘蛛和伪蜘蛛用同一套規則：结果往往是伪蜘蛛照样打進来，真蜘蛛被誤伤。
• 只在高峰期临时收紧：蜘蛛的抓取节奏被打乱，回来的時間會更没規律。

建议把並發和限速当成日常运维的一部分：每月看一次日誌，確認真蜘蛛的抓取是否顺畅、源站负载是否有余量。數值没有标准答案，能對上自己站点的實际情况就够了。