如何为 200 个并行浏览器会话规划代理容量
浏览器平台提高并发上限，并不代表代理池、目标站点和数据管道能够安全承载同样的规模。系统可能成功启动 200 个浏览器，却因为认证排队、会话混用、目标限流、内存压力和重试放大，最终获得的有效结果反而少于 60 并发。
本指南适用于已获授权的数据采集、市场研究、广告验证、本地化检查和回归测试。目标不是追求最高启动数，而是在目标规则、账户限制、隐私要求和成本预算之内，找到最高的可持续有效吞吐量。
先建立容量模型
压测前分别定义五类上限：
- 浏览器上限：可同时运行的浏览器进程或上下文数量。
- 代理上限：并发会话、建连速率、带宽以及可用地区库存。
- 目标上限：获授权目标允许的请求频率和并发度。
- 管道上限：任务队列、解析器、数据库、对象存储和下游接口的处理能力。
- 业务上限：每个有效结果可接受的最高成本和完成时间。
安全运行点由其中最小的限制决定，而不是由某个组件宣传的最大数字决定。
可以先用以下公式估算：
有效吞吐量 = 启动会话数 × 首次成功率 × 结果验证通过率 ÷ 总分钟数首次成功率必须与重试后的最终成功率分开记录，否则一个依赖大量重试的脆弱系统也会看起来很健康。
建立具有代表性的测试分组
不要只测试一个简单页面再推断全部业务。测试分组至少应覆盖：
- 国家和地区；
- 动态住宅、静态住宅或数据中心线路；
- 粘性会话或轮换会话；
- 页面体积与 JavaScript 复杂度；
- 无登录流程和已授权的登录流程；
- 单页检查和多步骤业务旅程。
每个分组至少完成 30 次有效尝试后再作判断。测试数据、截图、Trace 和日志中不得出现密码、代理凭证或非必要个人信息。
执行阶梯式并发测试
按 10、25、50、100、150、200 等阶段逐步提高并发。每个阶段应持续足够长时间，覆盖页面的正常波动，而不是只测第一次突发请求。
每个阶段记录：
- 浏览器启动成功率；
- 代理认证成功率；
- 建连和 TLS 耗时；
- 首字节、DOM 就绪和工作流完成时间；
- 首次成功率与最终成功率；
- 403、407、429 和 5xx 的分类原因；
- 国家、ASN 或粘性会话的异常变化；
- 流量以及每个验证通过结果的成本；
- 排队、执行和清理耗时；
- 内存、CPU、文件描述符和数据库饱和度。
出现以下任一情况就停止加压：有效吞吐量不再上升、p95 完成时间超过服务目标、错误率连续两个阶段上升，或目标明确表明已经达到允许上限。
区分浏览器工作进程与代理会话
一个浏览器工作进程不一定等于一个代理会话。根据业务选择隔离模型：
- 强隔离旅程：每个浏览器上下文使用独立代理会话；
- 多步骤流程：全程使用同一粘性会话，保持地区和出口连续；
- 完全无状态请求：仅在每次请求相互独立时使用受控轮换。
不要让无关用户或任务共享同一粘性会话。复用虽然能减少建连开销，但失控的复用可能混合 Cookie、出口身份或历史限流状态。
先设置背压，再设置重试
安全的队列应在系统失稳前延迟或拒绝新任务。至少限制：
- 每秒新启动浏览器数量；
- 每个地区的活动上下文；
- 每个代理网关的会话数；
- 每个目标的请求并发；
- 重试并发；
- 单次运行的总流量与总预算。
重试任务应进入更小的独立队列，并设置随机抖动和重试预算，只重试幂等操作。如果某阶段出现 20 个失败，又立即向已饱和的代理池发起 20 个重试，重试策略就会成为负载放大器。
定位第一个瓶颈
| 监控信号 | 可能瓶颈 | 下一步检查 |
|---|---|---|
| 启动失败上升但代理认证稳定 | 浏览器平台 | 工作配额、内存、启动速率 |
| 407 明显上升 | 代理配置 | 凭证范围、会话格式、网关上限 |
| 所有目标的建连时间都上升 | 代理或网络 | 网关饱和、DNS、TLS、带宽 |
| 只有一个目标的 429 上升 | 目标策略 | 降低允许速率并增加排队 |
| 成功率稳定但排队时间上升 | 数据管道 | 工作者或数据库容量 |
| 最终成功率稳定但首次成功率下降 | 过度依赖重试 | 线路质量、隐藏成本、重试风暴 |
每次只改变一个变量。一次同时更改地区、浏览器版本、代理类型和并发级别，能产生漂亮图表，却不能形成可靠结论。
选择生产并发上限
不要把压测中的崩溃点直接作为生产配置。应在最低已验证饱和阈值下保留余量，以应对更重页面、地区库存变化和下游延迟。可先将生产上限设为阈值的 70%–80%，并在错误或延迟预算被突破时自动降载。
最终决策记录应包括：
- 各地区、各工作流的批准并发；
- 代理会话与轮换规则；
- 队列和重试上限；
- p50 与 p95 完成时间；
- 首次成功率目标；
- 每个有效结果的最高成本；
- 自动停止条件；
- 测试日期、版本和负责人。
发布前检查清单
- 已确认书面授权和目标规则。
- 已验证代理地区及会话持续性。
- 凭证不会进入日志和截图。
- 测试样本覆盖真实页面类型。
- 使用阶梯式加压，而不是一次跳到最大值。
- 分开统计首次成功和重试恢复。
- 已设置地区、目标和预算上限。
- 取消或超时后能够完整清理资源。
- 只保留必要且允许的数据。
- 浏览器、代理或目标发生重大变化后重新压测。
常见问题
200 个并发浏览器是否等于 200 条代理连接？
不等于。一个浏览器可能建立多条连接，多个上下文也可能复用或轮换代理会话，因此必须分别测量浏览器并发和真实连接/会话行为。
是否应该为每个浏览器分配唯一住宅 IP？
只有获授权流程确实需要这种隔离时才这样做。不必要的唯一出口会增加成本并降低库存利用率。会话模型应匹配业务旅程、目标规则和隐私边界。
应用哪个指标决定并发上限？
使用同时满足延迟、错误、合规和成本约束的“每分钟验证通过结果数”。启动会话数只是基础设施指标，不是业务结果。
什么时候应重新进行容量测试？
浏览器或运行时大版本变化、代理套餐或网关变化、目标改版、新增地区，或页面体积和流程复杂度显著变化时，都应重新测试。
合规说明
只对已获授权的系统和数据执行自动化。遵守目标条款、适用的 robots 与访问政策、速率限制、隐私义务、地区法规和数据保留要求。不得利用并发或代理轮换绕过访问控制。
继续阅读Playwright 代理配置指南、住宅代理会话粘性测试和代理 429 处理指南。
内部研究记录：Cloudflare，Browser Run 并发上限更新，2026 年 8 月 20 日。
