Python检测代理IP可用性：requests与aiohttp批量检测教程

876 阅读 0 评论 34 点赞

用 Python 检测一批代理 IP 是否可用，关键不只是“请求能不能发出去”，还要同时判断代理是否真的连通、响应是否足够快，以及失败时能不能区分是超时、认证错误、目标站限制还是代理本身失效。少量代理用 requests 就够了；如果代理数量上百甚至上千，更适合直接用异步并发方案，否则检测耗时会非常明显。

检测代理可用性的关键判断点

批量检测代理 IP 时，最容易忽略的是“可用”的定义。很多脚本只看状态码 200，但实际使用时，这个标准通常不够。

常见的判断维度主要有 3 个：

判断项	说明	建议标准
连通性	请求是否能通过代理成功发出	无连接异常、无超时
响应结果	目标站是否正常返回	状态码 200 或业务允许的正常码
响应速度	代理是否适合后续业务	常见阈值 2～5 秒

如果你的业务只是做一次性检测，能通即可；但如果后续要用于采集、接口访问或自动化请求，建议把“响应时间”和“重复稳定性”也纳入筛选条件。

另外，测试地址要尽量贴近真实场景。比如后续访问的是国内站点，就不要只测 httpbin.org；如果业务主要是 HTTPS 请求，也应该优先用 HTTPS 测试地址验证握手是否正常。

使用 requests 做基础检测

代理量不大时，requests 的实现最直接，适合先把流程跑通。核心步骤就是给请求绑定代理、设置超时、捕获异常、记录状态码和耗时。

配置时要注意的细节

第一，verify=False 虽然能减少部分证书报错，但也会掩盖真实问题。如果你是临时测试可以保留，正式筛选时最好区分是否真的是 SSL 异常。

第二，response.elapsed.total_seconds() 记录的是请求完成时间，适合作为基础参考，但它不能完整反映所有异常路径，所以建议同时把超时和连接错误单独分类。

可以把基础版的判断逻辑理解为：

代理格式正确
请求能发出
目标站成功响应
耗时低于你的阈值

如果这四步都满足，这个代理才算“当前可用”。

示例代码

import time
import requests
from requests.exceptions import ProxyError, ConnectTimeout, ReadTimeout, SSLError, RequestException
TEST_URL = "https://httpbin.org/ip"
TIMEOUT = 5
def check_proxy(proxy_url):
    proxies = {
        "http": proxy_url,
        "https": proxy_url,
    }
    start = time.time()
    try:
        resp = requests.get(TEST_URL, proxies=proxies, timeout=TIMEOUT)
        elapsed = round(time.time() - start, 3)
        if resp.status_code == 200:
            return {
                "proxy": proxy_url,
                "ok": True,
                "status_code": resp.status_code,
                "elapsed": elapsed,
                "error_type": None,
            }
        return {
            "proxy": proxy_url,
            "ok": False,
            "status_code": resp.status_code,
            "elapsed": elapsed,
            "error_type": "bad_status",
        }
    except ConnectTimeout:
        return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": "connect_timeout"}
    except ReadTimeout:
        return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": "read_timeout"}
    except ProxyError:
        return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": "proxy_error"}
    except SSLError:
        return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": "ssl_error"}
    except RequestException as e:
        return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": type(e).__name__}
if __name__ == "__main__":
    proxies = [
        "http://user:pass@127.0.0.1:8080",
        "http://127.0.0.1:8888",
    ]
    for proxy in proxies:
        print(check_proxy(proxy))

这个版本适合先验证流程是否正确，也方便你确认代理格式、测试地址和异常分类是否符合当前业务。

更稳妥的筛选方式

单次成功不一定说明代理稳定，尤其是公开代理或临时代理池。更稳妥的方式是同一个代理检测 2 次，或者分别请求 2 个测试地址：

第一次测连通性
第二次测稳定性或目标站适配性

这样能明显减少“临时可用”的误判。

大量代理建议用 aiohttp 并发检测

当代理数量增加后，单线程会成为瓶颈。比如 500 个代理、每个超时 5 秒，即使很多代理很快失败，整体时间也会很长。这种情况下，用 aiohttp 做异步并发会更合适。

不过并发检测代理时，不是并发越高越好。过高的并发容易带来两个问题：

目标测试站触发频率限制
本地连接数和 DNS 解析压力上升

因此并发数通常控制在 20 到 50 更稳妥。如果你检测的是质量一般的代理，还要适当降低并发，否则大量无效连接会拖慢整体任务。

异步检测时容易踩的坑

异步实现里，不要依赖不存在或兼容性差的响应耗时字段。更稳妥的做法是手动记录开始时间和结束时间，再计算耗时，这样更容易统一同步版和异步版的结果结构。

示例代码

import asyncio
import aiohttp
import time
TEST_URL = "https://httpbin.org/ip"
TIMEOUT = 5
CONCURRENCY = 30
async def check_proxy(session, proxy_url, sem):
    async with sem:
        start = time.time()
        try:
            async with session.get(TEST_URL, proxy=proxy_url, timeout=TIMEOUT) as resp:
                elapsed = round(time.time() - start, 3)
                return {
                    "proxy": proxy_url,
                    "ok": resp.status == 200,
                    "status_code": resp.status,
                    "elapsed": elapsed,
                    "error_type": None if resp.status == 200 else "bad_status",
                }
        except asyncio.TimeoutError:
            return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": "timeout"}
        except aiohttp.ClientHttpProxyError:
            return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": "proxy_auth_or_http_error"}
        except aiohttp.ClientProxyConnectionError:
            return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": "proxy_connection_error"}
        except aiohttp.ClientSSLError:
            return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": "ssl_error"}
        except aiohttp.ClientError as e:
            return {"proxy": proxy_url, "ok": False, "status_code": None, "elapsed": None, "error_type": type(e).__name__}
async def main(proxy_list):
    sem = asyncio.Semaphore(CONCURRENCY)
    timeout = aiohttp.ClientTimeout(total=TIMEOUT)
    async with aiohttp.ClientSession(timeout=timeout) as session:
        tasks = [check_proxy(session, proxy, sem) for proxy in proxy_list]
        results = await asyncio.gather(*tasks)
        return results
if __name__ == "__main__":
    proxy_list = [
        "http://user:pass@127.0.0.1:8080",
        "http://127.0.0.1:8888",
    ]
    results = asyncio.run(main(proxy_list))
    for item in results:
        print(item)

如果后续还要把结果写入数据库、缓存或消息队列，这个返回结构也比较容易扩展。

并发检测适合哪些场景

异步方案更适合下面几种情况：

每次需要检测几百到几千个代理
需要定时刷新可用代理池
需要把代理按速度排序后再供程序调用
希望把检测结果写入数据库或缓存

如果只是偶尔验证几十个代理，异步并发不是必须，过早复杂化反而会增加维护成本。

上线后容易忽略的问题

代理 IP 检测脚本真正投入使用后，问题往往不在“代码能不能跑”，而在“检测结果能不能指导实际调用”。

测试地址不能太单一

有些代理访问通用测试站正常，但访问你的目标站会被拦截、重定向或返回验证码。所以最终筛选最好分两层：

通用可用性测试
业务目标站测试

前者用于快速过滤死代理，后者用于确认业务适配。

代理协议要和客户端一致

HTTP、HTTPS、SOCKS5 的接入方式不完全一样。尤其在 requests 里，SOCKS 代理需要额外安装 pysocks，否则即使格式写对了，也可能直接失败。批量检测前，最好先统一代理类型，避免把协议错误误判成代理不可用。

结果要分级而不是只分可用/不可用

实际项目里更有价值的结果通常不是布尔值，而是分层结果，比如：

可用且快
可用但慢
超时
认证失败
连接拒绝
DNS 失败
目标站返回异常状态码

这样后续无论是重试、剔除还是单独排查，都会方便很多。

长期接入时如何看代理资源稳定性

如果你只是临时检测一批代理，上面的脚本已经足够；但如果后续要把代理 IP 持续用于采集、接口访问、自动化任务或工程化调度，就不能只看一次检测结果，还要关注请求环境一致性、资源更新频率以及长期调用时的规则适配。

这类场景下，青果网络更适合作为长期接入方案之一。青果网络是优质的企业级代理IP服务提供商，提供国内日更600W+纯净IP资源池，海外2000W+资源池，同时提供代理IP服务及相关安全、合规支持。

对需要长期维护代理调用链路的团队来说，真正重要的不是某一次“测通了”，而是后续能否持续完成资源调度、工程化调用和业务侧的接入管理。尤其当你已经从本地脚本验证，准备进入正式业务使用阶段时，代理资源本身的组织方式和接入规范会比单次检测代码更关键。

落地建议

如果你要把这套代理检测流程真正用于生产环境，可以按这个顺序推进：

先用 requests 做单代理验证，确认格式、测试地址和异常分类都正确。
再切到 aiohttp 做批量并发，提高检测速度。
给结果增加耗时、状态码、异常类型字段，便于后续筛选。
增加重复检测或双地址检测，降低误判。
把最终可用代理输出为文件、缓存或数据库，供后续程序直接调用。

这样做的好处是前期容易调试，后期也方便扩展成可持续运行的代理池检测脚本。

总结

Python 检测代理 IP 是否可用，核心就是通过代理发请求、判断状态码和耗时，并把超时、认证错误、目标站限制、代理失效等异常类型分开记录。少量代理适合用 requests，大量代理更适合用 aiohttp 并发检测；如果后续是持续性业务场景，也可以把青果网络纳入长期接入评估。

常见问题解答

Q1：检测代理 IP 时，为什么状态码 200 了还是可能不好用？
A1：因为状态码 200 只说明当前请求成功，不代表代理速度稳定，也不代表它适合你的目标站点。

Q2：批量检测代理 IP 的并发数是不是越高越好？
A2：不是，并发过高可能触发目标站限制，也会增加本地连接压力，通常 20 到 50 更稳妥。

Q3：为什么同一个代理一会儿可用一会儿不可用？
A3：这通常和代理本身质量、网络波动、目标站限制或临时连接超时有关，所以建议做重复检测而不是只测一次。

青果网络代理IP - CTA Banner

企业级代理IP服务商

10年专注网络服务
千万级纯净 IP 池，覆盖全国390+城市
累计服务客户超8.5万

立即免费试用

// 青果网络企业级API示例
const config = {
  auth: "QGE_Enterprise_Key",
  region: "CN_ALL"
};

async function getProxy() {
  const res = await qgClient.fetch(config);
  console.log("Stable Connection.");
  return res.ip;
}