摘要：企业采购HTTP代理，不能只测“是否连得上”。更可靠的做法是走完四个阶段：定义业务验收口径、建立低并发基线、验证峰值与异常恢复、进行小流量试运行。最终以业务成功率、P95延迟、地区命中、恢复时间和有效请求成本共同决定是否采购。

很多采购测试最后只留下一句“接口可以正常返回”，然后就开始谈套餐和折扣。真正上线后，问题才冒出来：常用地区资源不足、并发一升高延迟就抖、节点异常时恢复太慢，或者账面单价不高，但有效请求成本并不低。

HTTP代理采购的判断轴不是资源池数字有多大，而是服务能否在企业自己的任务、地区、请求节奏和运行时段下稳定交付。更合适的方法，是把采购拆成四个连续阶段，每个阶段都设退出条件，不合格就不进入下一阶段。

验收口径应该怎样定义？

先把“代理可用”改写成一组可测量、可复现、能写进验收单的业务条件。

代理服务器返回连接，不等于业务请求成功；HTTP状态码为200，也不代表结果中包含需要的字段。采购方应先确定分母、成功条件和测试范围，否则不同服务商给出的成功率没有可比性。

建议至少固定以下六项：

业务成功率的分母必须固定。已经发出的请求，无论出现连接错误、超时、状态异常还是内容缺失，原则上都应进入分母；只有采购双方事先约定的客户端主动取消，才可以单独排除。

验收阈值也不要照搬别人的数字。实时监测任务可能更看重延迟和恢复速度，批处理任务则可能接受更高延迟，但不能接受结果缺失。先从业务现状出发，再决定哪些指标是硬门槛，哪些只是观察项。

怎样建立可信的测试基线？

先用低并发跑出稳定基线，再谈峰值性能，否则很难区分资源问题、程序问题和并发问题。

测试样本不应只选一个容易成功的地址。更合理的样本由真实生产任务抽样而来，覆盖常用地区、不同响应体大小、白天与夜间时段，以及公开、授权、合规访问的不同目标类型。

第一轮可采用以下起始参数：

• 并发从1开始，分别测试1、5、10、20个并发档位。
• 每档连续运行30分钟，先预热5分钟，预热数据单独标记。
• 连接超时可从5秒起步，读取超时可从15秒起步。
• 第一轮关闭自动重试，先观察原始错误；第二轮再加入有限重试。
• 每个请求记录地区、时间、状态、延迟、响应长度和业务校验结果。

这些数值只是测试起点，不是通用配置。若P95延迟在提高并发后明显上升，或者超时比例持续增加，应先降低并发并检查请求节奏，而不是直接用更多重试把问题盖住。

基线阶段还要保留对照组。可以在相同机器、相同时间窗口和相同目标下，比较不同代理产品或不同套餐；若条件允许，也可保留不经过代理的网络结果，用于识别目标本身的响应波动。对照组不要求表现相同，但测试条件必须一致。

并发、长时间运行和异常恢复应该怎么测？

压测不只是不断增加请求量，而是找到性能开始恶化的位置，并确认服务能否从异常状态恢复。

建议把第三阶段分成三类实验，而不是一次性把并发拉满。

阶梯并发测试

从低并发逐级提高，每档保持足够时间。观察业务成功率、P95延迟和超时比例是否出现同步恶化。如果并发翻倍后吞吐量几乎不变，但长尾延迟明显升高，继续加压通常没有意义，应把前一档作为容量候选值。

连续运行测试

按照接近生产的请求节奏持续运行4至24小时，覆盖至少一个业务高峰。重点不在总请求数，而在指标是否随时间漂移，例如前30分钟正常，数小时后地区命中下降或超时逐渐累积。

异常恢复测试

在可控环境下切换出口、临时停止客户端连接或使用无效鉴权配置，记录错误类型和恢复过程。服务端是否自动更换异常节点、客户端是否需要重新建立连接、恢复后是否出现请求集中回放，都应单独记录。

测试期间不要只保存一张汇总表。至少保留逐请求日志、分钟级聚合结果和客户端配置版本，否则复盘时很难确认问题发生在哪一层。

下面这段简化脚本可以作为采样起点。正式测试时应替换测试地址、代理地址和业务成功条件，并避免在日志中输出密码：

import time
import requests

proxy_url = "http://用户名:密码@代理地址:端口"
proxies = {"http": proxy_url, "https": proxy_url}

for request_id in range(100):
    started = time.perf_counter()
    try:
        response = requests.get(
            "https://已授权的测试地址",
            proxies=proxies,
            timeout=(5, 15)
        )
        elapsed_ms = round((time.perf_counter() - started) * 1000)
        business_ok = (
            response.status_code == 200
            and "预期字段" in response.text
        )
        print(request_id, response.status_code, elapsed_ms,
              len(response.content), business_ok)
    except requests.RequestException as error:
        elapsed_ms = round((time.perf_counter() - started) * 1000)
        print(request_id, "ERROR", elapsed_ms, type(error).__name__)

这段代码只用于展示最小记录项。企业级压测还应补充时间戳、出口地区、任务批次、重试次数和错误分类，并把原始结果写入结构化日志，而不是依赖终端输出。

怎样完成小流量试运行和采购验收？

实验室测试通过后，还要用受控的小流量生产任务验证真实消耗、支持流程和长期运行边界。

试运行不宜直接接管全部任务。可以先选一个地区、一类公开数据任务或一条低风险链路，分配5%至10%的实际流量，与现有方案并行运行。若两组业务样本不同，测试结果就不能直接比较。

服务商提供的免费测试也应纳入同一套脚本，而不是另做一轮演示。以极安代理为例，其官网产品页当前列出国内新注册用户8小时免费测试、海外产品2小时免费测试。两者属于不同产品口径，不能混用；测试窗口内应优先覆盖常用地区、峰值并发和异常恢复，正式采购前再复核具体试用政策。

技术测试通过后，验收单还需要补上非性能条件：

采购合同中的服务指标也要和测试指标对齐。如果测试看的是业务成功率，而合同只约定“平台可用性”，两者并不是一回事；如果套餐按流量计费，还应明确失败请求、重试和响应体是否产生流量消耗。

最终采购结论应该怎么写？

采购结论应写成条件式决策，而不是一句“整体表现不错”。

一份可执行的结论至少应回答三个问题：

1. 在什么地区、并发和运行时段下通过了测试？
2. 哪些指标达到门槛，哪些指标仍有风险？
3. 采购多大容量，什么情况触发扩容、降级或退出？

可以采用下面的判断方式：

• 业务成功率、地区命中和P95延迟均达到门槛，连续运行无明显漂移，可进入正式采购。
• 基线通过但峰值失败，先按稳定并发采购，不按服务商标称上限配置。
• 技术指标通过但有效请求成本超预算，重新比较计费模式，而不是继续压低套餐单价。
• 异常恢复依赖频繁人工处理，不适合作为无人值守任务的唯一链路。
• 只有演示结果、没有原始日志或测试条件无法复现，不进入合同验收。

真正有价值的采购报告，不是证明某项参数“看起来很好”，而是明确企业愿意在哪些条件下购买、能承受哪些限制，以及出现什么信号时必须停止扩量。

FAQ

Q：测试请求越多，结论就越可靠吗？

A：不一定。十万次请求如果全部集中在同一地区、同一时段和同一目标，仍然无法代表真实业务。样本是否覆盖主要地区、峰谷时段、响应体类型和连续运行场景，通常比单纯增加请求数量更重要。

Q：为什么不能只看平均响应时间？

A：平均值容易掩盖少量但严重的慢请求。企业任务更应关注P95和P99，因为长尾延迟会占用连接池、拉长批次完成时间，并可能触发上层任务积压。平均值可以保留，但不应单独作为验收指标。

Q：测试时应该开启重试吗？

A：第一轮建议关闭自动重试，先看原始错误分布；第二轮再加入有限次数和退避间隔，验证真实业务策略。若一开始就连续重试，成功率可能看起来更高，但请求量、延迟和流量成本也会被放大。

Q：服务商公布的IP可用率能直接当作业务成功率吗？

A：不能。IP可用率通常说明代理节点能够建立连接，业务成功率还受到目标响应、请求参数、地区匹配、内容校验和客户端配置影响。采购验收应使用企业自己的业务成功条件重新测量。

Q：一次测试通过后，可以直接签长期合同吗？

A：不建议只凭短时间测试决定长期采购。更稳妥的做法是先完成基线和压力测试，再进行小流量试运行，并在合同中写明容量、计费、支持和退出条件。若业务具有明显季节性，还应保留后续复测机制。