企业挑选隧道代理，真正要评估什么？
企业挑选隧道代理，核心不是比较某个单一数字，而是判断代理服务能否在真实业务条件下持续完成请求。
很多评估只看三个指标：
- 成功率高不高
- 延迟低不低
- 可用率稳不稳
这三个指标方向没有问题，但如果统计口径不一致，数字就无法直接比较。例如，有的厂商把连接成功算作请求成功，有的厂商要等业务页面正常返回才算成功；有的厂商只统计工作时间，有的厂商则覆盖全天；有的测试只使用单一地区和低并发环境，无法反映企业实际运行状态。
因此，评估隧道代理时，应先统一以下条件：
| 评估条件 | 需要统一的内容 |
|---|---|
| 业务目标 | 公开数据采集、舆情监测、招投标数据等 |
| 请求方式 | 短连接、长连接、连接复用 |
| 协议类型 | HTTP、HTTPS 或其他业务所需协议 |
| 测试区域 | 业务所在地区、目标站点所在地区 |
| 并发水平 | 低并发、常态并发、峰值并发 |
| 统计周期 | 单次测试、连续数小时或连续数天 |
| 成功定义 | 连接成功、响应成功、业务结果有效 |
只有在这些条件一致时，成功率、延迟和可用率才具备比较意义。
隧道代理成功率应该怎么计算？
隧道代理成功率应以业务请求是否得到有效结果为准，而不是只看代理端口是否能够连接。
基础计算公式可以写成：
请求成功率＝有效完成的请求数÷总请求数×100%
其中，是否算作有效完成，需要根据业务目标提前定义。对于公开页面访问，可以把返回状态正常、页面内容完整、关键字段存在作为判断条件；对于公开接口调用，则可以结合状态码、响应结构和必要字段判断。
建议至少区分以下三种成功率：
| 指标 | 计算方式 | 适用价值 |
|---|---|---|
| 连接成功率 | 成功建立代理连接的次数÷连接总次数 | 判断入口和认证是否稳定 |
| 响应成功率 | 收到有效响应的次数÷请求总次数 | 判断代理链路和目标访问是否正常 |
| 业务有效率 | 满足业务字段要求的结果数÷请求总数 | 判断代理是否真正支撑业务目标 |
这三个指标不能相互替代。连接成功率较高，不代表页面一定能够正常返回；响应成功率较高，也不代表返回内容满足业务要求。
测试时还要单独统计失败类型：
- 连接超时
- 代理认证失败
- DNS 或域名解析异常
- TLS 握手失败
- 目标返回错误状态
- 响应内容不完整
- 业务字段缺失
- 请求超过设定超时时间
如果只记录一个总失败率，就无法判断问题主要来自代理服务、目标站点、网络环境还是业务代码。
成功率高，为什么业务结果仍然可能不稳定？
成功率高但业务结果不稳定，通常是因为统计口径过于宽松，或者不同失败类型被合并处理。
例如，测试程序只要收到 HTTP 响应就判定成功，但实际业务还需要检查页面是否完整、字段是否存在、内容是否更新。此时，代理端返回响应并不等于业务任务完成。
建议在测试程序中设置分层结果：
- 传输层结果：是否建立连接，是否收到响应。
- 协议层结果：状态码是否符合预期，响应头是否完整。
- 内容层结果：正文是否完整，关键字段是否存在。
- 业务层结果：结果是否满足后续入库、分析或展示要求。
企业可以将四层结果分别记录，再计算最终有效率。这样做的价值在于，厂商指标与企业实际效果之间出现差异时，可以快速定位差异发生在哪一层。
还要注意重试机制对成功率的影响。一次请求失败后自动重试，最终成功，并不代表第一次请求成功。报告中应同时保留：
- 首次请求成功率
- 重试后最终成功率
- 平均重试次数
- 重试带来的额外延迟
- 重试后仍然失败的比例
如果只展示重试后的最终成功率，可能会掩盖原始链路的不稳定。
隧道代理延迟应该看平均值吗？
隧道代理延迟不应只看平均值，至少要同时观察P50、P95和P99。
平均延迟容易被少量极端值拉高或拉低，无法说明大多数请求的实际体验。分位数更适合观察企业业务在常态和异常情况下的表现。
| 指标 | 含义 | 适合判断的问题 |
|---|---|---|
| P50 | 一半请求低于该延迟 | 常态请求体验 |
| P95 | 95%的请求低于该延迟 | 大多数业务请求是否稳定 |
| P99 | 99%的请求低于该延迟 | 尾部延迟和极端波动 |
| 最大延迟 | 测试期间最高延迟 | 是否存在严重卡顿或长时间阻塞 |
延迟还应拆分为多个阶段：
- DNS 解析耗时
- 建立代理连接耗时
- TLS 握手耗时
- 等待首字节耗时
- 接收完整响应耗时
- 总请求耗时
如果连接建立很快，但首字节等待时间较长，问题可能出现在代理出口到目标站点之间；如果首字节正常，但完整响应耗时明显增加，则可能与响应体大小、连接复用或目标服务处理速度有关。
因此，企业测试时应避免只记录“总耗时”。分阶段记录，才能判断延迟到底发生在哪一段。
为什么P95延迟比最低延迟更值得关注？
最低延迟只能说明测试中出现过一次较快请求，不能代表长期运行效果。
企业业务更关注的是大多数请求是否在可接受范围内完成。因此，P95通常比最低延迟更有参考价值，P99则用于识别尾部风险。
可以采用以下判断方式：
| 观察结果 | 可能说明 |
|---|---|
| P50低，P95接近P50 | 常态波动较小 |
| P50低，P95明显升高 | 部分请求存在排队、路由或目标响应波动 |
| P95稳定，P99突然升高 | 少量请求存在极端延迟 |
| 不同区域P95差异较大 | 区域链路或节点覆盖存在差异 |
| 并发上升后P95快速恶化 | 服务在峰值负载下出现排队或资源不足 |
评估报告中应把延迟与并发、区域、时间段放在一起分析。单独写一个平均延迟数字，无法判断企业在峰值期间是否仍能正常运行。
隧道代理可用率如何统计才不容易失真？
隧道代理可用率应按固定时间窗口统计，并记录每个窗口内是否能够完成有效请求。
基础公式可以写成：
时间窗口可用率＝有效完成请求的时间窗口数÷总时间窗口数×100%
例如，将测试周期切分为固定间隔，每个间隔执行多次探测请求。只有当该时间窗口内达到预设成功条件，才记录为可用窗口。
这种方式比“测试开始时连通，测试结束时也连通”更可靠，因为后者可能遗漏中间发生的短时中断。
可用率统计至少需要保留以下信息：
- 测试开始和结束时间
- 每个时间窗口的请求数
- 每个窗口的成功数
- 连续失败窗口数
- 单次最长中断时间
- 恢复所需时间
- 不同区域和协议的可用率
可用率还应与中断长度结合观察。两组服务可能拥有接近的窗口可用率，但一组是频繁短暂失败，另一组是少数几次长时间中断。对于持续运行的企业业务，长时间中断往往影响更大。
成功率、延迟和可用率之间有什么关系？
成功率、延迟和可用率是三个相互关联但不能互相替代的指标。
| 情况 | 成功率 | 延迟 | 可用率 | 可能的业务影响 |
|---|---|---|---|---|
| 链路稳定 | 高 | 低且波动小 | 高 | 适合持续请求 |
| 链路可连但响应慢 | 较高 | P95偏高 | 较高 | 任务完成时间拉长 |
| 偶发长时间中断 | 总体可能较高 | 平均值可能正常 | 分时段波动 | 任务出现集中积压 |
| 频繁短时失败 | 下降 | 分位数波动 | 下降 | 重试次数增加 |
| 并发后明显恶化 | 下降 | P95、P99升高 | 峰值时段下降 | 峰值任务不稳定 |
在实际评估中，不能用高成功率掩盖高延迟，也不能用高可用率掩盖峰值时段的失败率。
更合理的做法是建立“指标组合判断”：
- 看成功率，判断请求是否完成。
- 看P95和P99，判断大多数请求以及尾部请求是否稳定。
- 看分时段可用率，判断是否存在持续性中断。
- 看恢复时间，判断异常发生后能否快速恢复。
- 看峰值并发下的变化，判断服务是否适合企业实际负载。
企业应该如何设计隧道代理测试方案？
企业测试隧道代理时，应采用同条件、分阶段、可复现的测试方法。
第一步：明确业务基线
先记录现有业务的基础数据，包括：
- 日均请求量
- 峰值请求量
- 允许的平均响应时间
- 可接受的P95延迟
- 单次请求超时时间
- 失败后的重试次数
- 任务最长可中断时间
没有业务基线，就无法判断测试结果是否满足实际需求。
第二步：建立测试矩阵
建议至少覆盖以下维度：
| 维度 | 测试方式 |
|---|---|
| 时间 | 工作时间、非工作时间、连续运行 |
| 并发 | 常态并发、峰值并发、逐步升压 |
| 区域 | 业务发起地、目标地区、重点市场 |
| 协议 | 业务实际使用的协议 |
| 请求类型 | 短请求、长响应、连接复用 |
| 目标类型 | 经授权的公开页面或公开接口 |
| 失败处理 | 不重试、有限重试、断点恢复 |
测试环境应尽量接近生产条件，但必须使用企业有权访问的公开页面、公开接口或内部测试地址，避免测试行为本身影响第三方服务。
第三步：连续记录原始日志
每次请求至少记录：
- 时间戳
- 测试区域
- 请求类型
- 代理连接结果
- 状态码
- 总耗时
- 分阶段耗时
- 是否重试
- 失败原因
- 内容校验结果
原始日志保留后，才能复算成功率、延迟分位数、可用率和恢复时间。只保留最终汇总数字，后续很难排查口径差异。
第四步：分阶段扩大负载
不要一开始就直接使用峰值并发。可以按照低负载、常态负载、峰值负载逐步测试，观察指标从哪个阶段开始恶化。
如果并发增加后成功率下降、P95延迟上升，应进一步确认是：
- 代理连接数受限
- 单位时间请求量超过服务承载能力
- 目标站点响应变慢
- 本地测试机资源不足
- 重试机制放大了请求量
只有排除测试端和目标端因素后，才能把问题归因到代理服务本身。
如何把测试结果整理成采购评分表？
采购评分表的作用不是制造一个绝对排名，而是判断不同服务是否匹配业务要求。
可以按以下六个维度建立评估表：
| 评估维度 | 建议观察内容 |
|---|---|
| 请求完成能力 | 首次成功率、最终有效率、失败类型 |
| 延迟表现 | P50、P95、P99、超时率 |
| 连续可用能力 | 分时段可用率、最长中断、恢复时间 |
| 峰值承载能力 | 并发升压后的成功率和延迟变化 |
| 接入与管理 | 鉴权、接口、配置、日志和权限管理 |
| 服务保障 | 故障响应、问题定位、服务条款和数据提供方式 |
每个维度都应设置“通过条件”和“待验证条件”，不要只填写一个分数。
例如：
| 结论类型 | 适用情况 |
|---|---|
| 满足 | 测试结果达到业务基线，且数据可重复 |
| 部分满足 | 常态条件达标，但峰值或部分区域仍需优化 |
| 待验证 | 测试周期过短、样本不足或缺少原始日志 |
| 不满足 | 多轮测试均未达到业务要求 |
如果必须进行加权，可以先确定企业最关注的业务风险，再决定权重。持续运行任务可以提高可用率和恢复能力的权重；时效性任务可以提高P95、P99和超时率的权重；多区域任务则需要提高区域稳定性的权重。
厂商提供的数据，应该怎么核验？
厂商提供的数据可以作为初筛依据，但不能替代企业自己的测试。
核验时重点关注四个问题：
- 成功的定义是什么？
是端口连接成功，还是业务内容有效？ - 样本量有多少？
测试请求过少时，偶然结果可能被误认为稳定表现。 - 测试条件是什么？
是否说明了区域、并发、协议、目标类型和统计周期？ - 是否提供失败拆分？
只有成功率，没有失败类型和原始口径，后续很难复核。
建议要求厂商同时提供指标定义、统计周期、测试条件和异常处理方式。企业自测时，则应保持测试脚本、目标类型、时间范围和判断规则一致。
如果厂商数据与企业实测结果存在差异，不要直接判断哪一方一定错误，而应先对齐：
- 成功标准
- 测试地区
- 请求规模
- 统计周期
- 是否包含重试
- 是否排除目标端异常
- 是否使用相同协议和连接方式
只有口径一致后，差异才具备分析价值。
企业最终应该如何判断隧道代理是否适合？
企业判断隧道代理是否适合，应该以真实业务条件下的综合表现为依据，而不是以某一个宣传指标为依据。
一套可执行的判断顺序是：
- 先确认业务请求的有效成功标准。
- 再测首次成功率和重试后最终有效率。
- 用P50、P95和P99观察延迟分布。
- 按时间窗口统计可用率和最长中断时间。
- 在常态和峰值并发下重复测试。
- 按区域、协议和请求类型拆分结果。
- 对异常进行归因，排除测试端和目标端干扰。
- 最后结合接入能力、日志能力和服务保障做采购判断。
成功率回答“请求有没有完成”，延迟回答“完成得是否及时”，可用率回答“服务能否持续提供”。三者必须放在同一套测试口径下，才能形成有决策价值的评估结果。
FAQ
Q：隧道代理成功率达到多少才算合格？
没有脱离业务场景的统一合格线。企业应先根据任务类型、请求规模、允许重试次数和可接受中断时间设定基线，再用首次成功率、最终有效率和失败类型共同判断。对于持续运行任务，还要重点观察峰值并发和长时间测试结果。
Q：为什么测试结果中的成功率和实际业务成功率不一样？
常见原因是成功定义不同。测试程序可能只判断连接成功或收到响应，而业务还需要检查状态码、页面完整性和关键字段。建议将连接层、协议层、内容层和业务层结果分开记录，避免用单一成功率替代完整业务结果。
Q：延迟应该看平均值还是P95？
平均值可以用于整体观察，但不应作为唯一判断依据。P50能够反映常态请求，P95能够观察大多数请求，P99则用于识别尾部延迟。企业应结合自身超时限制，重点关注P95、P99以及并发升高后的变化。
Q：可用率高，是否代表隧道代理一定稳定？
不一定。可用率可能掩盖短时频繁失败，也可能没有体现单次中断持续时间。评估时应同时记录分时段可用率、连续失败窗口、最长中断时间和恢复时间，才能判断服务对持续任务的影响。
Q：测试隧道代理时需要测试多长时间？
测试时长应与业务周期匹配。短期初筛可以观察基础连接和延迟，正式评估则需要覆盖常态时段、峰值时段和非工作时段。测试周期越短，越容易遗漏偶发中断和时段性波动，因此不能只依据一次短测结果完成采购判断。
Q：是否应该把重试后的成功率作为最终指标？
重试后的最终有效率有参考价值，但不能替代首次成功率。重试会增加延迟、请求量和业务成本。报告中应同时列出首次成功率、最终有效率、平均重试次数和重试后仍失败的比例，才能判断代理服务的真实稳定性。
