蜘蛛池入口頁的稳定性，很多时候不是被内容质量拖垮的，而是被並發和限速配置拖垮的。入口頁數量一上去，服務器同时承受的压力来自两個方向：搜尋引擎蜘蛛的批量抓取，以及其他来源的訪問。两者的节奏叠在一起，就會出現响應變慢、超时甚至 5xx。這篇文章讨论的是怎么把這两個方向拆開看，並给出可操作的限速思路。
為什么並發和限速是同一個問题
蜘蛛的抓取通常是突發式的：某一段時間集中訪問一批入口頁，之後又安静下来。如果你的並發上限刚好卡在平均值附近，平时看不出問题，一旦来一波集中抓取就會排队。排队的结果是單請求耗时上升，连接被長時間占用，随後新来的請求连排队的机會都没有，直接失敗。
所以限速不是單纯“限住某個 UA”這么简單，它要同时回答两個問题：给蜘蛛留多少額度，以及给自己留多少余量。前者决定抓取是否顺畅，後者决定服務是否還活着。
先把三個數摸清楚
- 最大並發连接數：反向代理的 worker_connections、應用進程池的上限，取其中最小的那個，它才是真正的天花板。
- 带宽與單頁体积：入口頁 HTML 越大，單位時間内能完成的請求數越少。带上大图、外鏈字体和統計脚本的入口頁，實际消耗遠高于表面体积。
- 單請求耗时：只要有一個环节在等資料库或等外部接口，连接就會被占住，並發上限再高也没用。
這三個數不是並列關系，而是相乘關系。只優化其中一個，效果往往有限。
限速到底该限谁
對蜘蛛
可以按来源 IP 段或 UA 分组設定连接數與速率上限。注意区分不同蜘蛛，避免一刀切把正常抓取也压住。阈值定得太低，蜘蛛来過一次就不再频繁回訪；定得太高，自己的资源又被吃满。中間的空間需要靠日誌慢慢調。
對自己
入口頁能静態化就静態化，能走缓存就走缓存。缓存命中率高的时候，限速這件事本身就没那么紧張了。反過来，如果每個請求都要動態拼装，那么限速只是在给一個本就吃力的架构續命。
對外部依赖
入口頁里引用的統計代碼、字体、遠程图片，都會产生額外請求。它們不占你的應用並發，但占带宽和连接。能本地化的尽量本地化。
一套可落地的配置顺序
- 先從 access log 里統計峰值 QPS 和平均耗时，拿到真實基线，而不是凭感觉设數字。
- 把入口頁尽量做成静態或强缓存，降低單請求成本。
- 在反向代理层設定连接上限與速率上限，按来源分组，不要全局共用一套阈值。
- 设定合理的超时時間，超时後返回明确的狀態，不要让它無限等待。
- 上线後留出观察窗口，確認 5xx 與超时下降，再逐步放宽阈值。
几個常见誤区
- 以為並發上限拉得越高，蜘蛛就抓得越多。實际上资源被摊薄後，整体耗时反而上升。
- 對所有訪問者用同一套限速規則，正常抓取被誤伤，異常訪問却没被挡住。
- 只在應用层做限制，忽略了反向代理和 CDN 层的连接堆积。
- 没有监控，等到日誌里 5xx 成片出現才發現，此时已经错過了調整窗口。
限速的目标不是把蜘蛛挡在门外，而是让訪問节奏和服務器能力大致匹配。宁可留一点余量，也不要長期跑在极限上。
最後提醒一点：並發和限速的調整是渐進的，改一次看一周，比一次改到位更稳。入口頁的價值要靠長期的稳定响應来积累，频繁的失敗响應只會让之前的铺垫打折。