蜘蛛池入口页的稳定性，很多时候不是被内容质量拖垮的，而是被并发和限速配置拖垮的。入口页数量一上去，服务器同时承受的压力来自两个方向：搜索引擎蜘蛛的批量抓取，以及其他来源的访问。两者的节奏叠在一起，就会出现响应变慢、超时甚至 5xx。这篇文章讨论的是怎么把这两个方向拆开看，并给出可操作的限速思路。
为什么并发和限速是同一个问题
蜘蛛的抓取通常是突发式的：某一段时间集中访问一批入口页，之后又安静下来。如果你的并发上限刚好卡在平均值附近，平时看不出问题，一旦来一波集中抓取就会排队。排队的结果是单请求耗时上升，连接被长时间占用，随后新来的请求连排队的机会都没有，直接失败。
所以限速不是单纯“限住某个 UA”这么简单，它要同时回答两个问题：给蜘蛛留多少额度，以及给自己留多少余量。前者决定抓取是否顺畅，后者决定服务是否还活着。
先把三个数摸清楚
- 最大并发连接数：反向代理的 worker_connections、应用进程池的上限，取其中最小的那个，它才是真正的天花板。
- 带宽与单页体积：入口页 HTML 越大，单位时间内能完成的请求数越少。带上大图、外链字体和统计脚本的入口页，实际消耗远高于表面体积。
- 单请求耗时：只要有一个环节在等数据库或等外部接口，连接就会被占住，并发上限再高也没用。
这三个数不是并列关系，而是相乘关系。只优化其中一个，效果往往有限。
限速到底该限谁
对蜘蛛
可以按来源 IP 段或 UA 分组设置连接数与速率上限。注意区分不同蜘蛛，避免一刀切把正常抓取也压住。阈值定得太低，蜘蛛来过一次就不再频繁回访；定得太高，自己的资源又被吃满。中间的空间需要靠日志慢慢调。
对自己
入口页能静态化就静态化，能走缓存就走缓存。缓存命中率高的时候，限速这件事本身就没那么紧张了。反过来，如果每个请求都要动态拼装，那么限速只是在给一个本就吃力的架构续命。
对外部依赖
入口页里引用的统计代码、字体、远程图片，都会产生额外请求。它们不占你的应用并发，但占带宽和连接。能本地化的尽量本地化。
一套可落地的配置顺序
- 先从 access log 里统计峰值 QPS 和平均耗时，拿到真实基线，而不是凭感觉设数字。
- 把入口页尽量做成静态或强缓存，降低单请求成本。
- 在反向代理层设置连接上限与速率上限，按来源分组，不要全局共用一套阈值。
- 设定合理的超时时间，超时后返回明确的状态，不要让它无限等待。
- 上线后留出观察窗口，确认 5xx 与超时下降，再逐步放宽阈值。
几个常见误区
- 以为并发上限拉得越高，蜘蛛就抓得越多。实际上资源被摊薄后，整体耗时反而上升。
- 对所有访问者用同一套限速规则，正常抓取被误伤，异常访问却没被挡住。
- 只在应用层做限制，忽略了反向代理和 CDN 层的连接堆积。
- 没有监控，等到日志里 5xx 成片出现才发现，此时已经错过了调整窗口。
限速的目标不是把蜘蛛挡在门外，而是让访问节奏和服务器能力大致匹配。宁可留一点余量，也不要长期跑在极限上。
最后提醒一点：并发和限速的调整是渐进的，改一次看一周，比一次改到位更稳。入口页的价值要靠长期的稳定响应来积累，频繁的失败响应只会让之前的铺垫打折。