代理并发饱和测试：找到安全吞吐拐点
看似最快的代理配置，往往已经过载。吞吐量可能仍在上升，但排队时间、p95 延迟、重试次数和每个有效结果的成本上升得更快。真正适合生产的点，是继续增加并发却几乎不能增加已验证产出的拐点之前。
本指南适用于住宅、轮换、ISP 和数据中心代理线路的可重复容量测试。测试对象必须由你拥有，或已明确授权进行负载测试。本文不用于突破网站限制。
先拆分四种“并发”
- 提交并发： 调度器试图同时运行的任务数。
- 在途请求： 已离开应用、尚未完成的请求数。
- 活动连接： 已建立或正在建立的传输连接；多路复用可让一个连接承载多个请求。
- 排队任务： 等待于应用、HTTP 客户端、代理网关或下游处理器的任务数。
若只记录工作线程数，客户端连接池可能悄悄将大部分任务排队，最终却把请求到达代理前产生的延迟误判为代理性能问题。
列出每一层潜在瓶颈
测试前画出完整路径：
调度器 -> 解析器 -> 客户端连接池 -> 代理账号/网关
-> 网络与 TLS -> 已授权目标 -> 解析处理 -> 存储任一层达到上限都可能表现为“代理饱和”。应分别采集客户端排队、连接获取、DNS、代理连接、目标连接、TLS、首字节、传输、校验和下游处理耗时。
准备确定且已授权的测试端点
使用为测试设计的端点，保持响应大小、摘要与响应延迟可控，并与所有者约定测试时段和上限。固定请求体、方法、请求头、预期状态和校验规则。
建立两条对照：
- 直连对照： 在允许时用同一客户端直接访问同一端点，用于暴露客户端、目标端和下游上限。
- 代理路径： 将完全相同的工作负载发送到一个有明确记录的线路类型与账号策略。
不要在一条曲线中混合市场、会话模式、地址族或目标端行为。Global、North America、Europe 与 APAC 若对业务重要，应分别测试。
只统计真正有效的工作
每次尝试记录经过脱敏的字段：
run_id, route_class, market, address_family, session_mode
offered_concurrency, active_connections, in_flight, client_queue_ms
dns_ms, proxy_connect_ms, tls_ms, ttfb_ms, total_ms
status_class, retry_after_seen, attempt_number, response_digest_ok
bytes_transferred, useful_result, failure_phase每个并发档位应报告：
- 每秒已验证有效结果；
- 排队和总耗时的 p50、p95、p99；
- 首次尝试成功率与最终成功率；
- 响应完整性通过率；
- 每个有效结果对应的重试数和传输字节；
- 按阶段划分的 407、429 和 5xx；
- 每个有效结果的成本，而不是每次请求成本。
被截断、市场错误、未通过认证或校验失败的响应不能计入有效吞吐。
运行有上限的并发阶梯
按已记录的方法预热客户端，然后测试 1、2、4、8、16、32 等阶梯。示例数字不是建议上限；真正上限必须来自测试授权、供应商套餐和目标策略。
每个档位：
- 保持工作定义和线路类型不变。
- 使用相同的观测时长，并覆盖正常延迟波动。
- 将预热样本与正式样本分开。
- 重复测试，区分容量变化与短暂线路波动。
- 一旦超过约定上限、错误预算或延迟护栏，立即停止。
先采用闭环模型：一个工作线程只有在前一任务完成后才开始新任务。开放式到达率测试能够揭示队列增长，但任务可能以高于系统处理速度的速率累积，因此需要更严格的保护。
找拐点，不追峰值
相邻档位计算：
吞吐增量 = 新档位有效 RPS - 前一档位有效 RPS
每新增线程收益 = 吞吐增量 / 新增并发数
单个有效结果成本 = 代理总成本 / 已验证结果数拐点是边际吞吐明显衰减或护栏被突破前的最后一个档位。常见信号包括：
- 并发翻倍而有效吞吐仅增长不到 10%–15%；
- p95 总耗时或排队延迟陡升；
- 首次尝试成功率或响应完整性下降；
- 每个有效结果的重试与字节数增加；
- 429、407、连接重置或超时加速；
- 解析或存储队列持续积压。
生产值应保守地低于拐点。稳定档位的 70%–85% 可作为评估起点，但安全系数必须结合线路波动和业务容忍度，不能机械套用。
定位真正饱和的层
| 证据 | 可能的限制 | 下一项检查 |
|---|---|---|
| 客户端队列上升，活动连接保持不变 | 客户端池或连接上限 | 检查单来源与全局连接限制 |
| 代理连接耗时和 407 上升 | 账号或网关策略 | 核对供应商并发与认证限制 |
| 直连与代理的目标首字节均上升 | 已授权目标容量 | 降低负载并与目标所有者协调 |
| 出现 429 和重试指引 | 目标策略 | 遵守等待时间、降低到达率，不能轮换规避 |
| 传输耗时随字节上升 | 线路或本地带宽 | 对比按字节归一化吞吐与网络遥测 |
| 网络稳定但完成队列增长 | 解析或存储 | 限制输入并安全扩展下游 |
HTTP/2 或 HTTP/3 多路复用会让请求并发与连接数分离。必须记录协商协议与流行为，不能假设一个连接只对应一个请求。
设置生产工作池
可用容量受最小授权上限约束：
安全并发 = 每类线路的实测稳定容量 × 安全系数同时以客户端资源、供应商合同、目标授权和下游容量为硬上限。按市场和工作负载类型保留独立预算，避免某条慢线路占满全局工作池。
加入自适应背压：
- 队列超过时间或深度预算时停止接收新任务；
- 尾延迟或首次失败持续恶化时降低并发；
- 遵守服务端重试指引，使用有上限且带抖动的退避；
- 限制重试次数，并把全部尝试计入成本和负载；
- 连续多个健康窗口后再逐步恢复，而非立即跳回旧峰值。
不得通过轮换 IP 绕过限速或访问策略。
验收清单
- [ ] 测试目标、时段和负载上限已经明确授权。
- [ ] 直连与代理对照使用同一确定性工作单元。
- [ ] 市场、地址族和会话模式分别生成曲线。
- [ ] 排队时间、活动连接和在途请求分别测量。
- [ ] 同时报告首次成功、完整性和有效吞吐。
- [ ] 重试、字节与成本按有效结果归一化。
- [ ] 自动停止条件已配置并经过验证。
- [ ] 生产并发低于可重复出现的拐点。
- [ ] 背压和渐进恢复已经配置。
常见问题
最高 RPS 档位就是正确设置吗？
通常不是。它可能隐藏极高尾延迟、重试、无效响应和不稳定队列。应选择在质量、策略和成本护栏内最高且可重复的档位。
为什么增加线程后活动连接没有增加？
HTTP 客户端可能设置了单来源或全局连接限制，将额外任务排队；多路复用协议也可能在一个连接中承载多个流。请检查连接池指标与协商协议。
所有线路都应使用同一并发吗？
不应。容量会随市场、地址族、代理产品、会话策略和工作负载变化，应为每个实际线路类型保存实测预算。
能否不统计重试？
不能。重试会消耗带宽、代理用量和目标容量。首次结果应单独报告，但最终成本和负载必须包含全部尝试。
相关 98IP 指南
合规说明
仅对自己拥有或已明确授权的系统进行负载测试。遵守合同、robots 与访问策略、声明的速率限制、隐私要求和重试指引。不得用代理轮换规避封禁、配额或身份控制。仅保存脱敏运营遥测，绝不记录代理凭据或个人数据。
