可用率的计算看似简单——成功除以总数——真算起来却有不少讲究：什么算一次请求？什么算成功？失败的重试算不算？走代理IP时这些口径直接决定数字的含义，口径不同，同一个出口能算出差别很大的可用率。搞清计数规则，才不会被数字误导。
先看「分母」怎么定：统计的是请求次数还是连接次数？请求次数按每次业务操作计，连接次数按每次建立连接计，两者数字可能差很多。代理IP批量任务如果一次连接发多次请求，用请求次数算出的可用率会更高、也更能反映业务真实体验。口径要在统计前先明确。
什么算成功有讲究
「成功」的判据也分宽严：宽松口径只要请求发出去了、有响应就算成功，不管状态码是什么；严格口径则要响应正常（如 2xx）才算成功，被拒绝、超时、乱码都算失败。代理IP场景中判断出口好坏，通常用严格口径——能连上但被目标站拒绝，对业务来说依然是失败。
重试的处理同样影响数字：一次失败后立刻重试成功了，按「请求」算是一次失败一次成功（成功率 50%），按「业务任务」算则任务最终成功。批量任务关心的是任务完成率，可能更愿意用后者；但评估出口本身质量，必须按原始请求算，否则重试会把坏出口的真相掩盖掉。
口径不统一，对比就失真：拿 A 服务商按宽松口径报的 99.5%，和 B 按严格口径实测的 98% 比，结论必然偏颇。正确的做法是先定一套自己的口径（严格判据、按请求算、含重试前原始结果），所有出口都用同一套统计，数字之间才有可比性。
把口径固定成自己的标准还有一个附带好处：长期跟踪的可用率趋势是同一把尺子量出来的，出口质量的升降一目了然。代理IP使用者维护一套稳定的统计口径，相当于给链路质量建立了一台不会骗人的仪表盘。
可用率计数有口径：分母按请求还是连接、成功看宽严判据、重试是否计入——同尺子才能比数字。
把口径写进统计习惯
落地到日常，建议把口径固化成一句自检：每次统计前先问三件事——分母是什么、成功怎么判、重试怎么算。三问答完再统计，结果才站得住脚；答不出来就默认用严格判据加按请求算，这是最不乐观也不悲观的中间口径。
最后提醒一点：口径没有绝对对错，只有适不适合场景。选出口用严格口径更稳妥，看任务完成用任务级口径更贴业务。关键是「用什么口径就要在什么口径下解读」，别拿严格口径测出来的数去对比服务商宽松口径的宣传值，那只会得到错误的结论。
口径话题对代理IP自动化的意义尤其直接：监控与重试逻辑都建立在口径之上——按什么判据计数、失败后何时重试、重试多少次算放弃，代码里写的每个参数背后都是口径决策。把口径想清楚再写逻辑，自动化任务的成功率统计与出口调度才准确可靠。
给团队或脚本使用者一个建议：把可用率口径写进说明文档，注明「按请求计、严格判据、含重试前原始结果」，避免不同成员各按各的理解统计，数字无法对齐。口径透明化，是多人协作场景下代理IP质量数据可信的前提。