Python 3.11中如何结合httpx与TaskGroup批量校验代理IP？-Python教程-PHP中文网

不能跨taskgroup复用httpx.asyncclient，因其内部共享连接池和状态，易引发runtimeerror或连接混乱；必须显式分设connect、read等超时参数防止单个代理拖垮整批任务。

python 3.11中如何结合httpx与taskgroup批量校验代理ip？

直接结论：能用，但要注意 httpx.AsyncClient 实例不能跨 TaskGroup 复用，且需显式设置 timeout 防止个别代理拖垮整批任务。

为什么不能在 TaskGroup 里共用同一个 `httpx.AsyncClient`

TaskGroup 启动的每个协程是并发执行的，而 httpx.AsyncClient 内部共享连接池和状态（如 cookies、headers）。若多个协程同时调用 .get() 并复用同一 client，可能触发 RuntimeError: Event loop is closed 或连接复用混乱，尤其在代理响应慢/超时/断连时更明显。

✅ 正确做法：每个协程内新建 httpx.AsyncClient，或用 async with httpx.AsyncClient(...) 包裹单次请求
❌ 错误写法：client = httpx.AsyncClient(...); async with task_group: client.get(...)
⚠️ 注意：新建 client 成本不高，httpx 默认启用连接池，只要 limits 设置合理，不会导致端口耗尽

如何用 `asyncio.TaskGroup` 控制并发数并捕获异常

Python 3.11 的 asyncio.TaskGroup 是比 asyncio.gather() 更安全的选择——它能在任一子任务抛出异常时自动 cancel 其余任务，并把异常原样抛出，避免“静默失败”。

python-code-analyz

专业Python代码分析与优化，支持语法检查、安全扫描、性能评估、复杂度分析及重构后优化代码生成。

下载

设定并发上限：用 asyncio.Semaphore(n) 包裹请求逻辑，而不是靠 TaskGroup 自身限流（它不限流）
必须 await 每个请求：否则 TaskGroup 不知道该等谁，容易提前退出
代理校验建议目标 URL：用 https://www.php.cn/link/dc17d9b4862d86f8054735577c04462a（返回 JSON，轻量且能验证 HTTPS 代理是否工作）
示例片段：

import asyncio
import httpx
<p>async def check_proxy(proxy_url: str, sem: asyncio.Semaphore):
async with sem:  # 控制并发
try:
async with httpx.AsyncClient(
proxies={"http://": proxy_url, "https://": proxy_url},
timeout=httpx.Timeout(5.0, connect=3.0)
) as client:
r = await client.get("<a href="https://www.php.cn/link/dc17d9b4862d86f8054735577c04462a">https://www.php.cn/link/dc17d9b4862d86f8054735577c04462a</a>", follow_redirects=False)
return proxy_url, r.json()["origin"], True
except Exception as e:
return proxy_url, str(e), False</p><p>async def batch_check(proxies: list[str], max_concurrent: int = 10):
sem = asyncio.Semaphore(max_concurrent)
results = []
async with asyncio.TaskGroup() as tg:
for p in proxies:
tg.create_task(check_proxy(p, sem))
return results  # ⚠️ 注意：TaskGroup 不直接返回结果，需在协程内收集</p>

`httpx.Timeout` 的三个参数必须分开设，否则代理超时会卡死

代理 IP 常见问题是连接极慢（几秒到几十秒），或 TLS 握手失败。只设总 timeout 不够——connect 阶段卡住时，read 根本没机会触发。

connect：DNS 解析 + TCP 连接 + TLS 握手，对代理最关键，建议 ≤ 3s
read：服务器响应数据传输，可稍长（如 5s），但别超过 10s
pool：连接池等待空闲连接的超时，一般不用调，保持默认即可
错误配置示例：timeout=5.0 → 可能某个代理在 connect 阶段卡满 5 秒，拖慢整批任务
正确写法：timeout=httpx.Timeout(5.0, connect=2.5, read=4.0)

真实场景下容易忽略的细节

代理协议混用、HTTP/HTTPS 差异、以及 DNS 解析位置，都会让校验结果失真。

HTTP 代理不等于 HTTPS 代理：有些代理只支持 HTTP CONNECT，对 HTTPS 请求会直接失败，务必分别测试 http:// 和 https:// 目标
DNS 由客户端还是代理解析？httpx 默认由本地解析域名再连代理，若想让代理做 DNS（更贴近真实爬虫行为），得加 trust_env=False 并手动拼 Host header，较复杂，一般校验阶段可忽略
部分代理要求认证：URL 格式必须为 http://user:pass@host:port，且不能漏掉 http:// 协议头，否则 httpx 会报 InvalidProxyURL
批量时注意 User-Agent：某些代理网关会拦截无 UA 的请求，加一个简单 UA 更稳妥

真正跑起来之后，你会发现最耗时的不是并发本身，而是错误代理的 timeout 累积——所以 connect 超时比总 timeout 更关键，也最容易被跳过。