代理稳定性怎么测：用任务交付记分表判断续用与扩容

衡量代理稳定性，先看“计划任务中，有多少按时交付了正确结果”，再同时看请求成功、重试恢复和遗漏任务。代理网关能连通、HTTP 返回 200，都不足以证明业务已经拿到可用数据。把分母和截止时间写清楚，才有依据决定续用、扩容或排障。

本文面向已经运行经授权的数据采集或网站 QA 任务的工程负责人及续费决策者，提供可以下载、离线复算的记分器。示例数据全部为教学而设，不是 IPHTML 或其他服务商的实测，也不能用来证明任何服务等级承诺。

一、先定义任务，再计算请求成功率

一个任务，是应用需要交付的一份结果。例如，在一个计划时间，检查指定地区的某个商品页面。同一任务的重试仍属于同一个任务；即使 URL 没变，下一小时的定时检查也是新任务。计划数量必须在执行前登记，否则工作进程没有启动时，遗漏的任务可能连分母都进不去。

让实际使用结果的人一起确认验收口径。以经授权的地区商品检查为例：

• 身份正确：必须是预期商品或页面标识，只返回同一域名下的页面不够。
• 上下文正确：地区、语言、币种符合要求，需要跨步骤保留的会话状态没有丢失。
• 内容有效：必需字段通过事先规定的校验。商品确实不可售可以是一条有效观察，但解析结果为空不能直接解释成“无库存”。
• 交付及时：从任务按计划具备执行条件时开始，到校验后的结果可用为止，包括排队、重试和等待。
• 分母明确：统计窗口内所有计划任务。事先批准的取消单独记录，不能事后把失败改标为取消来提高成功率。

Google SRE 工作手册介绍了“好事件／总事件”的指标形式，并说明测量位置会影响能看到哪些失败。本文将这个原则用于依赖代理的完整任务链路；链路未按时交付，并不自动等于代理服务商发生故障。

二、把每个指标的分母放在台面上

用独立的调度清单登记计划任务，用稳定的任务 ID 关联尝试日志，两边对账后再出报表。缺少尝试记录，可能是工作进程没运行，也可能是日志丢失；查明前应标记为“没有交付证据”，既不能当成确定的代理故障，也不能从结果中悄悄删掉。截止时间尚未到的任务属于未结束窗口，不应提前判失败。

三、用十个任务复算三个不同的“成功率”

下面全部是人为构造的教学数据。十个任务都要求五秒内完成；所有任务的截止时间及已记录尝试都结束后，才关闭统计窗口。时间从各任务的计划起点开始累计，不是单次请求的传输时间；示例使用顺序重试。

九个任务实际有尝试，共产生十一次请求。其中八次返回 200，因此得到8／11＝72.73%；六个已尝试任务最终有有效内容，因此得到6／9＝66.67%。但十个计划任务中，只有五个在五秒内交付有效内容，真正的按时有效交付率是5／10＝50%。三个数字各自成立，回答的却是不同问题。

此外，尝试覆盖率为 9／10＝90%，首次尝试成功率为 4／9＝44.44%，有效尝试率为 6／11＝54.55%。如果把最终有效交付也放回全部计划任务中计算，则是 6／10＝60%。J4 体现重试的恢复价值；J6 说明后来成功也不能抹掉一次逾期；J10 则说明只看请求日志会遗漏业务损失。

下载离线 Python 记分器，查看源码后使用 Python 3 运行。脚本只使用标准库，不访问网络、不读取代理凭据：

python3 proxy-reliability-scorecard.py --self-test
python3 proxy-reliability-scorecard.py

第二条命令输出 JSON，每项同时列出分子、分母和百分比。自检覆盖示例算术、恰好卡在截止时间的边界、遗漏任务、空尝试列表及错误输入。没有任何尝试时，请求类比率应是未定义，而不是 0%；对于已关闭且计划任务数量已知的窗口，交付率仍可以是 0%。

要复算自己的已结束窗口，可以准备 JSON 文件。下面的最小例子包含一个按时完成的任务，以及一个没有尝试证据的计划任务：

{
  "planned_jobs": ["A", "B"],
  "deadline_ms": 5000,
  "attempts": [
    {"job_id": "A", "no": 1, "status": 200,
     "valid": true, "elapsed_ms": 900}
  ]
}

python3 proxy-reliability-scorecard.py closed-window.json

valid 必须由你的内容校验产生，脚本不会检查响应正文或替你判断业务正确性。elapsed_ms 是累计任务耗时，没有收到 HTTP 状态时用 null。这个教学格式允许有效内容对应成功的 2xx 状态，要求连续完整的尝试编号，并假定顺序尝试、统一截止时限。遇到缓存 304、并行竞速请求、不同任务时限或分布式链路，要先调整数据模型。它不负责调度任务，也不能证明输入日志没有漏记。

四、把“结果失败”和“谁造成失败”分开

HTTP 层成功，内容仍可能不符合任务。一个可核查的具体信号是 Cloudflare 官方文档中的 cf-mitigated: challenge，用于识别其 Challenge Page 响应。没有这个响应头，不代表所有内容都有效，仍应校验身份、字段和上下文。遇到验证页要单独分类，并寻找获准的访问方式，不能把持续换身份当成默认解决办法。

只在有权测试的基础设施和目标上做对照；保持应用主机、目标集合、负载内容、计划、并发及校验器版本一致，每次改变一个相关变量。IP 查询接口可以辅助确认路由，但不能替代真实的获准业务流程。如果官方 API、授权数据源或自有系统直接连接已经满足需要，应把它们纳入对照，而不是预设必须使用代理。

五、观测周期要覆盖你准备长期运行的任务

先用小规模、有限频率的代表性任务建立记录。例如，可以先观察完整一周，包含忙时与闲时，再沿用同一口径积累更长运行记录，支持大额续费或扩容判断。这只是计划示例，不是统计保证：低请求量、每周活动、目标变更和集中故障都可能留下盲区。十分钟无错误，不能证明整月稳定。

按获准目标、地区、会话模式、客户端版本和有意义的时段分别报告，每个分组同时列出真实样本量。第二轮如果把大部分流量转向更容易的目标，总成功率上升也不一定意味着服务改善。一个地区只有极少样本，即使观察值为 100%，仍然存在明显不确定性。

示例中六个成功任务的时间依次为 0.4、0.8、2.0、3.4、4.0、6.2 秒。按明确采用的最近秩法，p95 取第六个值，即 6.2 秒。它只描述六个完成任务，不能代表全部十个计划任务，更不是长期延迟承诺。不要给失败任务填“0 秒”；应在这个有条件的分位数旁边保留失败、未知及交付率。

六、把记分表落实为续用规则

评估前就约定业务时限、可容忍的漏交付数量和观察窗口。例如，某团队在一个明确窗口中安排 1,000 个任务，要求至少 950 个按时有效交付，即 95%，最多容纳 50 个未达到目标的任务。这些是演示假设，不是通用及格线，也不是 IPHTML 的承诺。还要约定证据缺失怎么处理，以及谁有权暂停扩容。

• 继续使用：重要分组满足事先约定的交付需要，成本可接受，已观察到的事故有清楚的解决记录。
• 先修复再扩容：遗漏调度、解析错误、上下文不一致或认证失败解释了差距。仅增加 IP 池并不能消除这些原因。
• 再测试容量：证据指向与负载相关的限制，并且可以通过受控、获准的实验隔离原因。先确认适用限制，再比较有效交付，不能只比较网关能否连通。
• 重新考虑访问路径或供应商：修复后用同一代表性任务复测；需求仍不满足时，以相同口径比较其他获准方案。

重试流量与人工维护的经济性，可以接着使用价格监测成本与试点决策表。判断支持质量，则记录自己工单的时间戳、已提供的排查资料、收到有效回复的耗时，以及问题是否再次发生。一次事故不足以建立长期口碑；有日期、可比较的证据，比未经验证的承诺更有用。

方法说明：本文采用 AI 辅助编辑分析，技术依据于 2026 年 10 月 9 日核对上方官方资料。数据、阈值及决策例子均为明确假设；实际测试仅验证离线算术与脚本行为，没有进行真实代理性能测试，也不宣称客户结果、支付或续费效果。