aiohttp 频繁请求更易被封因高并发导致tls指纹、user-agent、连接行为高度统一，触发waf反爬；应使用asyncio.semaphore限流（如设为1–3）、换用httpx.asyncclient模拟真实浏览器tls参数，并在请求前添加随机延迟。
为什么 aiohttp 频繁请求反而更容易被封？
异步不是“更快就更安全”，而是并发更高、指纹更统一。同一时间发出几十个 aiohttp.ClientSession 请求，User-Agent、TLS指纹、连接复用特征高度一致，比同步请求更易被 WAF（如 Cloudflare、Akamai）识别为爬虫。很多网站的反爬规则直接针对高并发短连接行为打分，aiohttp 默认不设连接池上限、无请求间隔、TCP 连接复用策略激进，实际效果常比 requests 更“显眼”。
- 默认
Connector(limit=100)，意味着最多 100 个并发 TCP 连接——对多数目标站已超标 - 所有协程共享同一个 TLS handshake 指纹（尤其在未启用
ssl_context自定义时） - 无内置 delay，协程一调度就发包，真实 RTT 差异极小，行为像机器人
怎么用 asyncio.Semaphore 控制并发量？
别依赖全局 sleep，用信号量锁住并发数，让请求真正“排队”。重点不是总请求数，而是**同时活跃连接数**——这是触发限流的核心阈值。
sem = asyncio.Semaphore(3) # 同时最多 3 个请求 <p>async def fetch(session, url): async with sem: # 进入临界区 async with session.get(url, timeout=10) as resp: return await resp.text() </p>
- 数值选 1–3：多数中小型网站能承受 2–3 并发；电商/API 类站点建议从 1 开始试
- 放在
session.get()外层，而非每个协程里加await asyncio.sleep()——后者无法控制连接数 - 不要和
time.sleep()混用，会阻塞整个事件循环
如何让每次请求的 TLS 和 TCP 行为更“像人”？
Cloudflare 等系统会分析 TLS 握手参数（如 supported_groups、ALPN）、TCP 选项（如 Window Scale、Timestamps），纯 aiohttp 默认配置太干净，缺乏真实浏览器多样性。
- 换用
httpx.AsyncClient：它默认启用更真实的 TLS 参数，支持http2=True，且可传入ssl_context自定义握手 - 禁用连接复用：
httpx.AsyncClient(http2=False, limits=httpx.Limits(max_connections=3))，避免长连接暴露行为模式 - 必要时伪造 TCP 层行为（需
scapy或内核级工具），但绝大多数场景下，降并发 + 换httpx+ 随机 delay 已足够
随机 delay 的正确写法和陷阱
固定 delay（如每请求后 await asyncio.sleep(1)）容易被建模识别；必须带偏差，且 delay 应在请求发起前，而非响应后。
import random delay = random.uniform(0.8, 2.4) await asyncio.sleep(delay)
- 放在
sem.acquire()之后、session.get()之前：确保 delay 不影响其他协程排队 - 范围不宜过大（如 0–5 秒），否则整体效率断崖下跌；也不宜过小（如 ±0.1 秒），失去随机性意义
- 避免在
except块里补 delay——失败重试本就会放大特征，此时加 delay 可能导致请求节奏反而规律化
真正难的不是加 delay 或降并发，而是判断目标站用哪一层规则在封你：是基于 IP 的 QPS 统计？还是 TLS 指纹聚类？或是 JS 挑战后的行为分析？没日志、没验证手段，调参只是碰运气。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
