换user-agent无效是因为现代反爬系统已升级为设备级识别，依赖tls指纹、http/2特征、js渲染等多维行为分析；单纯轮换ua无法改变底层协议栈一致性，反而因滥用过时ua加速被封。
为什么换User-Agent根本没用？
单纯轮换 User-Agent 字符串，对多数现代反爬系统（比如 Cloudflare、Akamai、目标站自研风控）基本无效。它们早就不只看请求头，而是结合 TLS 指纹、HTTP/2 流控特征、鼠标轨迹、JS 渲染行为等做设备级识别。你换一百个 User-Agent，只要底层 TCP 连接、TLS 握手、证书链、JA3 指纹一模一样，照样被标记为“同一台机器”。
真正起作用的，是让每次请求在协议栈层面看起来像不同真实用户——这需要更底层的控制。
用 requests + fake_useragent 为什么反而加速被封？
fake_useragent 库返回的 UA 多数是过时或高频滥用的（比如旧版 Chrome、已下线的 Safari 版本），甚至包含明显伪造字段（如 Chrome/120.0.0.0）。目标站日志一扫就发现：这批请求 UA 看似多样，但共用同一个 TLS fingerprint、没有 Referer、Accept-Language 固定为 en-US,en;q=0.9、且全部走 HTTP/1.1 ——这是典型脚本行为。
- 别用
fake_useragent，自己维护一份精简、真实的 UA 池（只保留近 3 个月内主流版本） - 每次请求必须同步更新
Accept-Language、Accept-Encoding、Sec-Ch-Ua、Sec-Fetch-*等 Chromium 系必带 header - 禁用
requests.Session()复用连接——它会复用 TLS session ID 和 TCP socket，暴露连续性
什么时候该放弃 requests，改用 undetected-chromedriver？
当你遇到以下任意一种情况，requests 已经不是“不够好”，而是“不可能绕过”：
- 页面返回空内容，但浏览器打开正常（说明依赖 JS 渲染）
- 响应中含
data-selenium="true"或window.__SECURITY__类混淆字段 - 抓取前必须完成滑块/点选/文字识别（哪怕只是“我已阅读条款”勾选框）
这时候硬上 requests 模拟，成本远高于直接用 undetected-chromedriver3（注意不是 v4，v4 对新版 Chrome 兼容差）。它能自动绕过常见 WebDriver 检测点，且支持启动参数控制 TLS 指纹、禁用自动化标志、加载真实用户配置目录。
关键配置示例：
options.add_argument("--disable-blink-features=AutomationControlled")<br>options.add_experimental_option("excludeSwitches", ["enable-automation"])<br>options.add_experimental_option('useAutomationExtension', False)
IP 被封后，代理池怎么配才不白花钱？
买代理不是填个 http://user:pass@host:port 就完事。多数人踩坑在于：代理 IP 是干净的，但你的请求指纹和请求节奏，把每个代理都变成了“秒封号”。
- 每 IP 请求间隔必须 > 3 秒，且加入 ±1.5 秒随机抖动（固定间隔比无间隔更容易被识别）
- 禁止对同一域名在单个代理上连续请求超过 5 次——哪怕你有 100 个代理，也要按域名做请求配额隔离
- HTTP 代理必须支持 CONNECT 方法（否则无法处理 HTTPS 请求中的 SNI 和 ALPN 协商）
- 优先选数据中心代理中的“sticky session”类型，避免每次换 IP 导致 TLS 指纹突变过大
真正难的不是换 IP，而是让每个 IP 上的行为，看起来像一个真实、低频、有停顿、偶尔出错的人类用户——这点连很多商业代理文档都不会告诉你。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
