代理 IP 池健康检查怎么做？用可用率、P95 和错误分布做一张可复测日报

资源池的健康状态，不能只靠“这个地址能不能连通”判断。一次 200 响应可能来自慢链路，也可能只是短暂恢复；一次失败也可能是接口权限或限流，而不是接入资源失效。对 Python 任务而言，真正有用的健康检查需要回答三个问题：请求是否在预算内完成、失败集中在什么环节、哪些地址应继续调度或进入复测。

一、健康检查的最小数据模型

每一条探测记录都应能还原一次请求发生的条件。没有上下文的成功率，很难用于排查。

健康检查至少要有两层口径：HTTP 可用率统计 2xx 或业务允许的状态码；业务成功率还要通过响应字段、文件大小或自有校验逻辑。把所有 HTTP 200 都当业务成功，会掩盖返回空数据、异步未完成或字段异常的问题。

二、指标口径：P95 和错误码为什么必须分开看

平均耗时只能说明总体水平，无法展示尾部慢请求。批处理和队列任务往往被少量慢请求拖住，因此应同时记录 P50 与 P95。P50 接近典型体验，P95 用来判断长尾是否接近业务超时预算。

错误码也不能简单归入“资源不稳定”：

HTTP 407 与目标服务器的 401、403 不属于同一层：407 表示接入端需要完成代理认证。429 则表示服务端判定请求过多，不能用无节制重试解决。

三、一个可运行的 Python 检查脚本

脚本按资源分组采样，输出 2xx 可用率、P50、P95、状态码和异常分布。接入地址由环境变量提供；默认回显接口只用于验证流程，实际运行应换成自有或授权检查接口。

import math
import os
import statistics
import time
from collections import Counter

import requests

CHECK_URL = os.getenv("CHECK_URL", "https://httpbin.org/get")
SAMPLES = 12
PROXY_URLS = {
    "region_a": os.environ["PROXY_REGION_A"],
    "region_b": os.environ["PROXY_REGION_B"],
}


def percentile_nearest_rank(values, ratio):
    ordered = sorted(values)
    return ordered[math.ceil(len(ordered) * ratio) - 1] if ordered else None


def check(name, proxy_url):
    costs, status_codes, exceptions = [], Counter(), Counter()
    proxies = {"http": proxy_url, "https": proxy_url}
    with requests.Session() as session:
        for _ in range(SAMPLES):
            started = time.perf_counter()
            try:
                response = session.get(
                    CHECK_URL, proxies=proxies, timeout=(3, 15), allow_redirects=False
                )
                costs.append((time.perf_counter() - started) * 1000)
                status_codes[response.status_code] += 1
            except requests.RequestException as exc:
                exceptions[type(exc).__name__] += 1
            time.sleep(0.5)

    http_successes = sum(count for code, count in status_codes.items() if 200 <= code < 300)
    return {
        "name": name,
        "http_availability_pct": round(http_successes / SAMPLES * 100, 2),
        "p50_ms": round(statistics.median(costs), 1) if costs else None,
        "p95_ms": round(percentile_nearest_rank(costs, 0.95), 1) if costs else None,
        "status_codes": dict(status_codes),
        "exceptions": dict(exceptions),
    }


for name, proxy_url in PROXY_URLS.items():
    print(check(name, proxy_url))

代码没有调用 response.raise_for_status()，因为验收时必须保留 403、407、429 和 5xx 的原始分类。耗时数组记录所有获得 HTTP 响应的请求，而不只记录 2xx；否则高延迟的 4xx/5xx 会被漏掉。连接和读取超时被分开配置，便于判断问题发生在建立连接还是接收响应阶段。

四、样本数量和复测规则怎么定

SAMPLES = 12 适合开发环境快速发现配置错误，不足以做长期服务结论。日常运行可按资源量和业务窗口扩展：

一次偶发超时不应立即永久下线。复测需要保持接口、协议、超时和并发条件一致；否则“恢复”可能只是换了一套测试条件。连续两个或三个时间窗均出现认证、TLS 或建连异常时，再将对应分组暂停调度更有依据。

五、日报不必复杂，但字段不能缺

这张表的意义不在于做出漂亮分数，而是保留可回溯证据。例如：P95 只在特定时段升高，排查应围绕链路负载和业务并发；407 持续存在，排查应回到认证配置；429 增多，重点是请求配额和退避策略，而不是把所有地址标记为不可用。

候选资源的测试数据应作为横向对照，而不是采购结论。以 IPdodo 住宅资源的一组对比测试记录为例，HTTP 成功率处于 98.5% 至 99.4%、平均响应耗时 0.6 至 2.4 秒、丢包率 0.3% 至 0.9% 的区间。这些数值受目标接口、地区、并发量和重试策略影响，不能直接外推到其他任务；放进日报时，更有价值的是用相同口径记录首轮成功率、重试后的最终成功率、P95 和错误分布。

六、从数据到调度：三种处理状态足够实用

阈值不能脱离业务定义。离线任务通常能接受较高 P95，但不应接受最终失败持续上升；写入型接口更需要限制重试次数并保证幂等；交互式接口则需要把 P95 放在明确的等待预算内。

七、常见问题

429 能不能算作资源不可用？

不能直接这样判断。429 是服务端限流信号，可能与账户、接口、配额、请求频率或其他服务端维度有关。报告应单独统计，并按接口文档的退避要求处理。

只测一个回显接口够不够？

回显接口适合验证出口和基础连通性，不能代表真实业务。生产验收应增加自有或已授权的业务检查接口，并把业务字段校验纳入成功条件。

为什么同一分组 HTTP 可用率高，任务还是慢？

可用率反映是否完成响应，无法描述长尾。P95、读取超时和并发时的队列等待共同决定任务完成时间，因此日报中需要同时保存这些指标。

结语

健康检查的价值，是把“资源池看起来能用”变成一组可比较的数据：成功率、P50/P95、状态码、异常类型和时间窗。统计口径稳定、测试条件可复现，团队才有依据决定继续调度、安排复测，还是回到认证、权限与连接配置排查问题。