实际上，代理IP的并发数不是拍脑袋定的，也不是"越多越好"。它可以用一个很朴素的公式从你的业务任务量反推出来。算出来之后你会发现，真正需要的并发数往往比你以为的少，但比你最初买的那个套餐又多了那么一截。
这篇就把这个估算逻辑捋一遍，从概念到公式到修正因子，最后附几个我们工作室实际跑过的场景经验值。
一、先把三个概念掰清楚
很多人一上来就问"我需要多少并发"，但"并发"这个词在不同语境下指的东西完全不一样。开工之前，得先把三个容易混的概念拎出来：
- 线程数/协程数：你本地代码里同时跑了多少个采集任务。这是你自己的事，跟代理服务商无关。
- 并发连接数：同一时刻有多少个HTTP请求正在"飞行中"（in-flight），每个都占着一个代理通道。这才是代理服务商计费和限流的那个"并发"。
- IP数量：你在一段时间内用到了多少个不重复的IP。这跟并发数有关系但不是一回事，并发100不等于你同时需要100个不同IP，也不等于你这一天只用100个IP。
说白了，代理服务商说的"并发数"指的是第二个——同时有多少个请求在用我的通道。你本地开500个协程，但如果每个请求200ms就回来了，同时占着通道的可能也就几十个。
问题恰恰出在这儿：很多人用线程数去估并发数，然后发现买多了或者买少了，以至于到最后，哪哪用着都不舒服。
二、核心公式：从任务量倒推并发数
往下拆一层看，并发数的本质是一个排队论问题。不用搞复杂的数学，记住这个基础公式就够用：
所需并发数=每秒请求数（QPS）×平均单次请求耗时（秒）
展开来说：
每秒请求数（QPS）=总任务量÷可用时间窗口（秒）
所需并发数=(总任务量÷可用时间窗口)×平均响应时间
举个例子你就明白了：
假设你要抓一个电商站的商品列表，总共50万个商品页，要求8小时内跑完。每个页面请求平均耗时（含代理转发、目标站响应、下载页面）大约1.5秒。
QPS=500,000÷(8×3600)=500,000÷28,800≈17.4次/秒
所需并发数=17.4×1.5≈26
26个并发。不多吧？很多人上来就买100并发，其实这个量级30个通道绑绑有余。
再来一个量级大点的：日均2000万条新闻源要在12小时内抓完，单次请求平均0.8秒。
QPS=20,000,000÷(12×3600)≈463次/秒
所需并发数=463×0.8≈370
这个就不小了，370个并发是实打实的中大规模采集。之前在大厂做信源采集的时候，3000+信源的系统稳态并发大概就在这个量级。
三、理论到实际：四个修正系数
上面那个公式是理想情况。实际跑起来，你得乘一组修正系数，不然一定不够用。
3.1失败重试系数：×1.2到×1.5
没有哪个采集任务能100%一次成功。代理超时、目标站返回403/503、验证码拦截——这些全得重试。
经验上，一手厂商的代理跑常规站点，失败率大概在5%到15%。如果目标站反爬强一点（电商、社交平台），失败率能到20%到30%。
失败的请求不但要重新排队，而且在失败之前已经占了一段时间的并发通道（等超时就是3到10秒白占着）。所以修正系数不是简单的1/(1-失败率)，而是要把超时占用也算进去。
粗算的话：
- 普通站点：×1.2
- 反爬中等的站点：×1.3
- 反爬很强的站点：×1.5甚至更多
3.2IP冷却/轮换间隔系数：×1.1到×1.3
这地方很多人踩坑——以为请求发完、响应回来，这个并发就释放了。
不完全是。如果你的策略是"同一IP连续请求之间插一个冷却间隔"（防止同一IP短时间内请求过密被风控标记），那每个并发通道的实际吞吐量就降了。比如你设了500ms的冷却，相当于每个通道的有效利用率打了个折。
冷却间隔越长，需要的并发数越多。修正系数大致是：
冷却修正=1+(冷却间隔÷平均响应时间)
比如平均响应1秒，冷却0.3秒，修正就是×1.3。
3.3波峰系数：×1.3到×2.0
如果你的任务不是均匀分布的——大部分采集业务都不是——高峰时段的QPS会远超平均值。
比如新闻采集，早上8到10点是发稿高峰，这两小时的任务量可能占全天的30%到40%。你不能用全天平均QPS去配并发，得按峰值来。
经验值：
- 任务分布比较均匀（比如全量扫描）：×1.3
- 有明显波峰（新闻/社媒监控）：×1.5到×2.0
- 事件驱动型（突发舆情、限时抢数据）：按峰值独立算，别用平均值
3.4安全余量：×1.2
最后无条件加20%安全余量。不是因为前面算得不准，是因为你的业务量会涨、目标站会调风控策略、偶尔会有突发任务——留点空间，省得到时候手忙脚乱加并发。
完整公式
把四个系数串起来：
实际并发数=基础并发数×重试系数×冷却系数×波峰系数×安全余量
回到刚才那个50万商品页的例子：
基础并发=26
实际并发≈26×1.3×1.2×1.3×1.2≈63
63个。比理想值翻了一倍多，但还是在可控范围内。你买80到100的并发包就很稳了。
四、几个常见场景的经验值
纯靠公式有时候不如有个参照系。这些是我们工作室和同行交流下来的粗略经验值，不是精确数，给你个量级概念：
| 场景 | 日任务量级 | 典型并发区间 | 关键变量 |
|---|---|---|---|
| 电商商品页扫描 | 10万–100万页/天 | 30–150 | 目标站反爬强度、是否需要渲染 |
| 新闻/资讯信源采集 | 50万–2000万条/天 | 50–500 | 信源数量、更新频率、波峰系数 |
| 社媒舆情监控 | 1万–50万条/天 | 20–200 | API限速、是否需要登录态 |
| SEO/搜索结果抓取 | 1万–10万次/天 | 10–80 | 搜索引擎反爬极强，单IPQPS压很低 |
| 价格监控（定时轮询） | 1000–5万SKU/天 | 5–30 | 轮询频率、目标站数量 |
| LLM训练语料采集 | 100万–5000万页/天 | 200–1000+ | 去重后的实际有效页比例 |
最后一行是我们自己在跑的。语料采集的特点是量巨大但对单条延迟不敏感，可以容忍排队，所以实际并发可以比理论值压低20%左右，用时间换成本。
五、三个常见的坑
坑1：并发买得越大越快？不一定
并发数上去之后，你对目标站点的请求密度也在上升。超过站点的承受阈值，触发频率限制或IP封禁，成功率反而会断崖式下跌。
我做语料这几年，见过不少团队一上来就把并发拉到500，结果成功率从90%掉到40%——有效吞吐量反而不如200并发的时候。
回到刚才那个数，有效吞吐量=并发数×成功率÷平均耗时。成功率如果跟着并发往下掉，这个乘积存在一个峰值点。找到那个点，才是你的最优并发。
坑2：没区分"通道并发"和"IP并发"
有些代理产品按"同时在线IP数"计费（比如独享代理），有些按"通道并发请求数"计费（比如隧道代理）。这两个东西的估算逻辑不一样：
- 通道并发：就是前面那个公式，算的是同时有多少请求在飞
- IP并发：你同时需要多少个不同的IP保持在线状态。这取决于你的IP存活时长和轮换策略——如果每个IP存活5分钟，你每分钟需要10个新IP，那同时在线就是50个
买之前搞清楚你买的是哪个，别算了半天发现口径对不上。
坑3：只算了稳态，没算冷启动
系统刚启动的前5到10分钟，所有线程同时开始发请求，瞬时并发会远超稳态值。如果代理服务那边有硬性并发上限，这波冲击可能直接触发限流。
解决方案很朴素：做启动限流。让线程分批上线，每批间隔几百毫秒到几秒，5分钟内爬升到稳态，别一脚油门到底。
六、一个可以直接套用的估算模板
最后给一个我们工作室内部用的速算模板，你可以直接往里填数：
#----业务参数----
总任务量（条/天）:________
可用时间窗口（小时/天）:________
平均单次请求耗时（秒）:________
#----基础计算----
QPS=总任务量÷(时间窗口×3600)
基础并发=QPS×平均耗时
#----修正系数----
失败重试:1.2/1.3/1.5（选一个）
冷却间隔:1+(冷却秒数÷平均耗时)
波峰系数:1.3/1.5/2.0（选一个）
安全余量:1.2
#----最终结果----
实际并发=基础并发×重试×冷却×波峰×安全余量
算出来的数大概率不是整数，向上取整再对齐到代理服务商的套餐档位就行。
这块怎么权衡，得看你们的业务量级。日采集量在10万以下的，老实说并发这个事根本不用纠结，最低档就够了；日采集量过百万的，花半天把这个公式跑一遍，能帮你省掉一大块冤枉钱——或者避免上线当天才发现并发不够用，那就不是钱的问题了。
