入口页的抓取速度和源站承受能力之间，永远存在一个平衡点。放得太松，蜘蛛一多源站就抖；卡得太紧，蜘蛛来两次没拿到完整内容就走了，再想叫回来要花不少时间。这篇聊的是服务端限速和并发控制，重点是怎么从日志里找到那个平衡点，而不是套一个固定数值。

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

很多站点把限速当成一个开关，其实它至少分三层，每层管的东西不一样。

• 网络层：单 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 限容易误伤正常用户，也拦不住伪蜘蛛。
• 阈值写死后长期不动：站点内容、服务器配置都在变，限速参数也得跟着复核。
• 真蜘蛛和伪蜘蛛用同一套规则：结果往往是伪蜘蛛照样打进来，真蜘蛛被误伤。
• 只在高峰期临时收紧：蜘蛛的抓取节奏被打乱，回来的时间会更没规律。

建议把并发和限速当成日常运维的一部分：每月看一次日志，确认真蜘蛛的抓取是否顺畅、源站负载是否有余量。数值没有标准答案，能对上自己站点的实际情况就够了。