代理套餐写着“100M”，不代表一个应用随时能跑到100Mbps，也不代表提高并发就会线性增加吞吐。客户端到代理、代理到目标两段路径中的慢处，都会成为瓶颈；小请求还可能受延迟和连接建立影响，根本跑不满带宽。
容量规划要从业务工作负载出发，而不是先选一个最大的数字。
一、先区分五个容量指标
| 指标 | 含义 | 常见误区 |
|---|---|---|
| 带宽 | 单位时间可传输的数据能力 | 峰值写成持续保证 |
| 吞吐 | 实际完成的数据量或请求数 | 忽略目标服务器瓶颈 |
| 并发连接 | 同时保持的连接数量 | 等同于每秒请求数 |
| 请求速率 | 每秒完成的请求 | 忽略请求大小与延迟 |
| 流量 | 一个计费周期的数据总量 | 与瞬时带宽混淆 |
二、为什么标称100M测速只有一部分
可能原因包括共享带宽、峰值口径、单连接限速、跨网链路、TCP拥塞、丢包、代理CPU、目标限速和客户端性能。100M通常指Mbps而不是MB/s，理论换算还未扣除协议开销。
更完整的解释可参考代理带宽标称与实际测速差异。
三、先描述业务工作负载
- 请求是小JSON、大图片还是持续流；
- 上传和下载比例；
- 平均与95分位响应大小；
- 目标地区和典型延迟；
- 长连接还是短连接；
- 峰值每秒请求和持续时间；
- 允许的超时、错误率和排队长度。
没有这些数据，单纯问“多少并发需要多少带宽”无法得到可靠答案。
四、连接复用为什么影响容量
HTTP keep-alive和HTTP/2可以复用连接，减少TCP与TLS握手；但长连接太多会占用文件描述符、NAT状态和代理资源。切换节点或凭据时，旧连接还可能继续使用旧路径。
应设置合理的最大空闲时间、连接寿命、每目标连接数和队列上限，而不是无限建连接。
五、延迟如何限制吞吐
小请求在高延迟链路上，单连接要等待往返，吞吐容易被RTT限制。增加有限并发或使用多路复用可能提高利用率，但并发继续增长会造成排队、丢包和目标限流。
要观察延迟分位数和错误率，而不是只看总请求数。平均延迟会掩盖少量很慢的请求。
六、容量测试分几步
- 单连接验证协议、认证和功能；
- 低并发建立延迟与吞吐基线；
- 逐级增加并发，每级保持稳定观察；
- 记录客户端、代理和目标三端资源；
- 找到延迟或错误明显拐点；
- 降低到安全负载，验证是否恢复；
- 重复测试不同时段和代表性节点。
压测必须针对自有或明确获授权的端点，并控制总量。不能用增加并发测试第三方的访问限制。
七、测试记录哪些指标
| 类别 | 指标 |
|---|---|
| 业务 | 成功率、请求速率、队列和超时 |
| 延迟 | 中位数、95/99分位、连接与首字节 |
| 网络 | 吞吐、重传、丢包和连接重置 |
| 代理 | 活跃连接、认证错误、CPU和内存 |
| 目标 | 限流、5xx、处理时间和容量 |
| 成本 | 流量、节点数和测试时长 |
八、容量余量留多少
没有适用于所有业务的固定百分比。应根据增长速度、故障切换、扩容交付时间、峰值持续时间和业务重要性决定。余量至少要覆盖正常波动，并考虑一个节点故障后剩余容量能否承接关键流量。
备用节点也要定期做低频容量验证，不然只知道“能连”，不知道能否承载。
九、什么时候扩容，什么时候先优化
以下情况先优化：
- 大量短连接重复TLS握手；
- 请求重试没有退避；
- 下载重复且没有缓存或断点续传；
- NO_PROXY错误让内网流量绕代理；
- 单个慢目标拖累整个连接池；
- 日志或监控本身产生过多流量。
当配置合理、目标有容量、代理侧接近明确限制且业务持续增长时，再扩带宽、连接或节点。
十、节点横向扩展需要注意什么
多个节点并不自动提高可用性。要考虑：
- 节点是否处于不同故障域；
- 目标白名单是否允许所有出口；
- 会话是否需要固定出口；
- 调度器是否按健康和容量选择；
- 写请求是否有幂等与去重；
- 节点故障时是否会重试风暴。
API重试安全可参考代理超时与幂等恢复。
十一、成本如何纳入容量模型
把节点、带宽、流量、连接、部署、监控和故障处置一起计算，不只看每条IP单价。企业预算方法见代理IP全生命周期成本模型。
十二、形成一份容量报告
报告写清测试日期、网络、节点、目标、请求模型、并发阶梯、指标、拐点、限制和建议安全负载。不要把一次低峰结果宣传成长期保证。
容量规划的最终输出应该是“在这些条件下，每个节点安全承载多少，超过什么阈值扩容或降级”，而不是一个脱离工作负载的带宽数字。
