机场试用偶尔失败怎么比？记录成功率而不是只看最快一次

两个机场节点都可能在十次请求中失败一两次。只保存最快截图，会把偶发成功当成稳定；开启无限自动重试，又会把第一次失败藏起来。可靠机场推荐更需要回答“第一次请求有多常成功”，再单独观察有限重试能否恢复。

建立不自动重试的基线

选择一个稳定、允许访问的小型 HTTPS 页面，对每个候选节点执行 10 次。每次间隔 10 到 20 秒，避免短时间集中请求。命令示例：

curl.exe --retry 0 --connect-timeout 5 --max-time 20 -o NUL -sS `
  -w "code=%{response_code} exit=%{exitcode} total=%{time_total}\n" `
  "https://example.com/"

记录退出码、HTTP 状态码和总耗时。HTTP 404 仍可能是传输成功但目标路径不存在，因此成功条件要事先写清楚，例如“退出码为 0 且最终状态码为 200”。

再做有限重试组

curl 官方手册说明，--retry 会对超时以及若干临时 HTTP 错误进行重试，并采用逐步增加的等待。第二轮可使用：

curl.exe --retry 2 --retry-max-time 60 --connect-timeout 5 --max-time 20 `
  -o NUL -sS -w "code=%{response_code} retries=%{num_retries} total=%{time_total}\n" `
  "https://example.com/"

第一组衡量首次成功率，第二组衡量短暂故障后的恢复能力。不要把重试后的成功倒填成首次成功，也不要对付款、注册等有副作用的请求套用自动重试。

用四项比较候选机场

首次成功次数，例如 9/10；
失败类型，是连接超时、TLS 错误还是 HTTP 5xx；
成功轮次的中位耗时，而非最快值；
重试后恢复次数与总等待时间。

测试必须使用同一设备、同一接入网络、同一目标和相近时间。先测 A 再测 B 可能受时间变化影响，条件允许时用 A-B-A-B 交替顺序。

何时值得继续试用

偶发一次目标站 503，且直连也同样出现，不足以否定机场。只有代理路径反复连接失败、换目标仍失败，或错误集中在某一节点时，才更有理由归因于线路。还应补一次真实任务验收，例如登录页、文档站或工作接口，但不要提交敏感信息到不可信目标。

验收方法

最终表格应能复算首次成功率，并保留每次原始结果。若两家差异只有一次请求，不要下绝对结论；延长到另一个时段再测。若失败类型和恢复方式清晰，读者才能据此做可靠机场推荐选择。

如需自行了解服务，可使用本站已披露推广关系的 FlyBit 注册入口或 99吧注册入口。邀请码只用于归因，不代表额外优惠或服务保证，购买前仍应按本文方法试用。

参考资料

curl 官方手册：--retry、--retry-max-time 与 num_retries

机场试用偶尔失败怎么比？记录成功率而不是只看最快一次