如何解决Python异步爬虫被网站封禁IP的频率控制策略？

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()

• 数值选 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 应在请求发起前，而非响应后。

立即学习“Python免费学习笔记（深入）”；

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 挑战后的行为分析？没日志、没验证手段，调参只是碰运气。