代理评估只有在别人能够复现，并且知道每个数字代表什么时才有价值。本文建立一个可审计的小型测试方法，而不是编造“最佳代理榜单”。下面的线路名称和测量结果都是合成示例数据，不代表任何供应商的实时指标。
这套测试要回答什么问题
请使用你拥有或明确获准测试的端点。示例中的 TARGET_URL 是受控的 JSON 端点，IP echo 检查用于单独确认实际出口地址。每条线路运行相同的五次请求，使用相同的地区顺序、超时和 User-Agent。除非测试方案明确把重试视为产品行为，否则不要在测量窗口内偷偷重试。先记录原始请求，再计算聚合指标。
| 指标 | 定义 | 用途 |
|---|---|---|
| 传输成功率 | HTTP 状态码 200–399 的请求数 ÷ 总请求数 | 判断请求是否完成，但不把所有响应都当作有用数据 |
| 有效响应率 | 通过约定内容校验的响应数 ÷ 总请求数 | 区分快速返回的错误页、拦截页和真正可用的结果 |
| 平均延迟 / P95 | 请求耗时的平均值和 95 分位数（毫秒） | P95 可以暴露平均值掩盖的尾部延迟 |
| 错误分类 | 统计超时、代理错误、认证失败、目标 4xx/5xx 和策略拦截 | 解释失败原因，并判断是否适合重试 |
| IP 稳定性 | 1 −（不同 IP 数 − 1）÷（请求数 − 1） | 衡量出口身份是否符合预期 |
| 成本 | 每次请求成本或每个有效请求成本 | 避免把便宜但不可用的线路与可用线路直接混比 |
| 地理覆盖 | 成功到达的请求地区数 ÷ 请求地区总数 | 验证线路是否真的覆盖声明的地区 |
| 合规性 | 权限、条款、数据处理和访问频率的通过/不通过门槛 | 不通过门槛的线路直接不具备候选资格 |
1. 先固定测试设计，再看数字
请使用你拥有或明确获准测试的端点。示例中的 TARGET_URL 是受控的 JSON 端点，IP echo 检查用于单独确认实际出口地址。每条线路运行相同的五次请求，使用相同的地区顺序、超时和 User-Agent。除非测试方案明确把重试视为产品行为，否则不要在测量窗口内偷偷重试。先记录原始请求，再计算聚合指标。
from dataclasses import dataclass
from time import perf_counter
import requests
TARGET_URL = "https://httpbin.org/anything?probe=arcvenza-proxy-evaluation"
@dataclass(frozen=True)
class Route:
name: str
proxy_url: str
expected_region: str
ROUTES = [
Route("authorized_route_a", "http://USER:PASSWORD@proxy.example.test:8080", "US"),
]
def probe(route: Route) -> dict:
proxies = {"http": route.proxy_url, "https": route.proxy_url}
started = perf_counter()
try:
response = requests.get(
TARGET_URL, proxies=proxies, timeout=(10, 30),
headers={"User-Agent": "ArcvenzaProxyEvaluation/1.0"},
)
latency_ms = round((perf_counter() - started) * 1000, 2)
valid = response.ok and response.headers.get("content-type", "").startswith("application/json")
return {"route": route.name, "status_code": response.status_code,
"response_valid": int(valid), "latency_ms": latency_ms,
"error_class": "none" if response.ok else f"target_{response.status_code // 100}xx"}
except requests.exceptions.ProxyError:
return {"route": route.name, "status_code": None, "response_valid": 0,
"latency_ms": None, "error_class": "proxy_error"}
except requests.exceptions.Timeout:
return {"route": route.name, "status_code": None, "response_valid": 0,
"latency_ms": None, "error_class": "timeout"}
except requests.exceptions.RequestException:
return {"route": route.name, "status_code": None, "response_valid": 0,
"latency_ms": None, "error_class": "connect_error"}
for route in ROUTES:
print(probe(route))
探测代码把传输错误和 HTTP 响应分开。407 应归为代理认证错误，超时不应被当成“很慢但成功”的请求，429 应记录为目标站的限流或策略响应。保留这些错误分类，不要把它们全部压缩成一个“失败”计数。
2. 使用可复现的 CSV 固定样例
下面的固定样例包含四条匿名线路，每条线路五次请求。IP 列使用文档专用地址段，只用于说明。数字被刻意控制得足够小，便于人工核对；实际授权测试可以使用相同字段。`geo_ok` 表示实际出口地区与请求地区一致；`compliance_ok` 是审核门槛，不是性能承诺。
route,region,status_code,response_valid,latency_ms,ip,cost_usd,geo_ok,compliance_ok,error_class
sample_route_alpha,US,200,1,210,198.51.100.10,0.004,1,1,none
sample_route_alpha,DE,200,1,240,198.51.100.10,0.004,1,1,none
sample_route_alpha,SG,200,1,220,198.51.100.10,0.004,1,1,none
sample_route_alpha,US,200,1,230,198.51.100.10,0.004,1,1,none
sample_route_alpha,DE,200,1,250,198.51.100.10,0.004,1,1,none
sample_route_beta,US,200,1,180,198.51.100.11,0.003,1,1,none
sample_route_beta,DE,200,1,195,198.51.100.11,0.003,1,1,none
sample_route_beta,SG,200,1,205,198.51.100.12,0.003,1,1,none
sample_route_beta,US,200,1,215,198.51.100.11,0.003,1,1,none
sample_route_beta,DE,429,0,620,198.51.100.11,0.003,1,1,target_4xx
sample_route_gamma,US,200,1,320,198.51.100.13,0.006,1,1,none
sample_route_gamma,DE,200,1,350,198.51.100.13,0.006,1,1,none
sample_route_gamma,SG,200,1,480,198.51.100.13,0.006,0,1,none
sample_route_gamma,US,200,1,390,198.51.100.13,0.006,1,1,none
sample_route_gamma,DE,500,0,900,198.51.100.13,0.006,1,1,target_5xx
sample_route_delta,US,200,1,150,198.51.100.14,0.002,1,1,none
sample_route_delta,DE,200,1,160,198.51.100.15,0.002,0,1,none
sample_route_delta,SG,,0,2500,198.51.100.16,0.002,0,1,timeout
sample_route_delta,US,200,1,170,198.51.100.14,0.002,1,1,none
sample_route_delta,DE,407,0,190,198.51.100.14,0.002,0,1,proxy_auth
3. 计算成功率、有效率、尾部延迟和稳定性
成功率是传输层指标：状态码 200 到 399。有效率更严格，来自目标站点专用的内容校验。例如 JSON 端点需要检查响应类型正确且包含指定字段。P95 使用记录延迟的线性插值。IP 稳定性根据不同出口 IP 的数量计算；如果业务本来就需要轮换 IP，就应改为对照已声明的轮换或粘性目标。
import pandas as pd
df = pd.read_csv("proxy_probe_sample.csv")
df["transport_success"] = df["status_code"].between(200, 399).fillna(False).astype(int)
def p95(series):
return series.quantile(0.95, interpolation="linear")
metrics = df.groupby("route").agg(
attempts=("route", "size"),
success_rate=("transport_success", "mean"),
valid_response_rate=("response_valid", "mean"),
mean_latency_ms=("latency_ms", "mean"),
p95_latency_ms=("latency_ms", p95),
unique_ips=("ip", "nunique"),
mean_cost_usd=("cost_usd", "mean"),
compliance_rate=("compliance_ok", "mean"),
).reset_index()
metrics["ip_stability"] = 1 - (
(metrics["unique_ips"] - 1) / (metrics["attempts"] - 1).clip(lower=1)
)
geo = df.groupby("route").apply(
lambda g: g.loc[g["geo_ok"].eq(1), "region"].nunique()
/ g["region"].nunique()
).rename("geo_coverage")
metrics = metrics.merge(geo, on="route")
def min_max_benefit(series):
spread = series.max() - series.min()
return 1.0 if spread == 0 else (series - series.min()) / spread
metrics["latency_score"] = 1 - min_max_benefit(metrics["mean_latency_ms"])
metrics["p95_score"] = 1 - min_max_benefit(metrics["p95_latency_ms"])
metrics["cost_score"] = 1 - min_max_benefit(metrics["mean_cost_usd"])
weights = {"success_rate": 0.20, "valid_response_rate": 0.15,
"latency_score": 0.15, "p95_score": 0.10,
"ip_stability": 0.10, "cost_score": 0.10,
"geo_coverage": 0.10, "compliance_rate": 0.10}
metrics["weighted_score"] = sum(
metrics[column] * weight for column, weight in weights.items()
) * 100
print(metrics.round(3).sort_values("weighted_score", ascending=False))
4. 加权评分，同时保留权衡关系
本例的加权公式是：传输成功率 20% + 有效响应率 15% + 平均延迟得分 15% + P95 得分 10% + IP 稳定性 10% + 成本得分 10% + 地理覆盖 10% + 合规率 10%。各项收益指标在本次测试样本内归一化到 0–1；延迟和成本越低，得分越高。生产系统应固定归一化参考窗口，或者改用服务等级阈值，否则新增一个极端线路就可能改变历史线路的全部分数。
| 线路 | 成功率 | 有效率 | 平均 ms | P95 ms | IP 稳定性 | 地区覆盖 | 每次成本 | 得分 |
|---|---|---|---|---|---|---|---|---|
| sample_route_alpha | 100% | 100% | 230 | 248 | 100% | 100% | $0.004 | 95.0 |
| sample_route_beta | 80% | 80% | 283 | 539 | 75% | 100% | $0.003 | 84.4 |
| sample_route_gamma | 80% | 80% | 488 | 816 | 100% | 66.7% | $0.006 | 66.9 |
| sample_route_delta | 60% | 60% | 634 | 2,038 | 50% | 33.3% | $0.002 | 49.3 |
在这组样例中，sample_route_alpha 得分 95.0，成功、有效、稳定且覆盖完整，因此排名第一。sample_route_beta 平均更快且成本更低，但有一次 429 和一次 IP 变化，所以被扣分。sample_route_delta 每次成本最低，但超时、认证错误、IP 不稳定和地区覆盖不足使它总分最低。这些只是固定样例的结果，不是供应商排名。
5. 让比较保持公平
所有线路都应请求同一版本的目标、同样大小的响应。随机化线路顺序，或在多个轮次中轮换顺序，避免某条线路总是在繁忙时段运行。固定客户端地区、DNS 策略、TLS 设置、并发数、超时、请求数量和预热规则。报告测试时间窗口、样本量、目标、请求地区、排除项和错误分类。把冷启动结果和已预热会话分开，并同时保存原始行和聚合结果，方便复核。
仍然可能存在偏差：目标站可能只对某个源 IP 限流，IP 地理库可能过期，五次请求的样本量很小，线路池的组成也可能随时间变化。应在多个日期重复测试；样本足够时报告置信区间；不要把一次运行结果永久贴在线路或供应商身上。
6. 把合规性作为门槛
比较性能之前，确认线路可以用于目标站点和具体工作负载；在需要时确认供应商对 IP 来源和处理方式的披露；并遵守网站条款、robots 指引、认证边界、隐私义务和访问频率限制。不要用这套方法绕过访问控制。如果 compliance_ok 为 false，或无法建立合规依据，应直接标记为不具备候选资格，不能让速度或低价抵消合规问题。
一份可落地的评估清单
先写测试方案；选择获准目标；定义有效响应；记录原始请求；分类错误；计算成功率、有效率、平均延迟、P95、IP 稳定性、成本和地区覆盖；应用固定权重；审核 CSV；在多个时间窗口重复；最后写清结论边界。这样得到的是可解释的决策记录，而不是无法核查的“最佳代理”结论。