requests被秒封因服务端综合检测tcp指纹、ip行为和浏览器指纹；纯python默认tls特征固定、缺sec-ch-ua等头、无时序抖动，易被cdn/waf拦截。
为什么 requests 直接加 headers 还是被秒封？
因为服务端不只看 User-Agent，它同时采集 TCP 指纹（TLS 握手特征、HTTP/2 支持、ALPN 顺序）、IP 行为（请求间隔、并发数、历史响应码分布）和浏览器指纹（Canvas/WebGL/字体等 JS 特征）。纯 Python requests 默认用 OpenSSL 底层，TLS 扩展顺序固定、不发 Sec-Ch-Ua 头、无真实浏览器的时序抖动——这些全是硬伤。
常见错误现象：403 Forbidden 或 429 Too Many Requests 响应头带 cf-chl-bypass 或 x-served-by 字段；抓包发现请求根本没进业务逻辑，卡在 CDN/WAF 层。
- 别用
requests.Session()简单轮换User-Agent字符串——指纹雷同，IP 一挂全挂 - 别依赖
fake_useragent库——它只更新 UA 字符串，不改底层 TLS 行为 - 真实浏览器访问时带的
Sec-Fetch-*、Accept-Language、DNT等头，Python 默认全无
怎么让 Python 请求看起来像 Chrome？
核心是「协议层拟真」：用 httpx 替代 requests，搭配 httpx.AsyncClient(http2=True) 和自定义 TLS 配置；UA 必须匹配对应 Chrome 版本的完整指纹（含 Sec-Ch-Ua、Sec-Ch-Ua-Mobile），且每次请求微调时间戳和随机 header 顺序。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
httpx+httpcore的SSLContext自定义 TLS 1.3 扩展顺序（如重排supported_groups、启用key_share） -
User-Agent和Sec-Ch-Ua必须严格对齐，例如："Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"对应Sec-Ch-Ua: "Chromium";v="124", "Google Chrome";v="124", "Not=A?Brand";v="24" - 加一个
random.uniform(0.8, 1.3)的请求间隔抖动，避免固定周期触发速率模型
IP 限流绕过不是换代理就完事
高频 IP 被标记后，即使换代理，只要 TLS 指纹、UA、请求路径模式一致，WAF 仍会关联识别。重点不是“换”，而是“稀释”：把流量打散到不同 IP + 不同指纹组合 + 不同请求路径权重。
使用场景：爬取电商商品详情页时，/product/{id} 接口被限，但 /api/v2/product/{id}/reviews 可能未被监控。
- 代理必须支持连接池复用（如
httpx的limits参数控制每 IP 并发 ≤ 2） - 每个代理 IP 绑定唯一指纹配置（不同 Chrome 版本 UA + 不同 TLS 扩展顺序），禁止混用
- 对同一目标 URL，主动错开 Referer（
https://www.example.com/vshttps://m.example.com/）和 Accept-Encoding（gzip, deflatevsbr, gzip）
哪些参数组合最容易触发风控？
不是单个字段危险，而是多个低风险参数叠加形成「非人行为签名」。比如：Chrome UA + HTTP/1.1 + 无 Sec-Fetch-Site + Connection: close + TLS 1.2 且无 key_share 扩展——这基本等于告诉 WAF「我是 Python 脚本」。
性能与兼容性影响：
- 启 HTTP/2 会提升吞吐，但部分老旧 CDN（如早期 Cloudflare）会因 ALPN 协商失败直接拒连
- 强制 TLS 1.3 可绕过部分基于 TLS 1.2 指纹的规则，但国内某些中间设备可能降级失败
-
httpx的异步能力必须配合asyncio.Semaphore控制总并发，否则 DNS 解析或连接池耗尽反而暴露脚本特征
复杂点在于：指纹拟真程度和请求成功率是反比关系。过度模拟（比如强行伪造 WebGL 渲染结果）会导致 SSL 握手失败率飙升；而过于保守又会被秒识别。真正有效的策略，是按目标站点的 WAF 类型（Cloudflare / Akamai / 自研）动态调整指纹强度，而不是一套配置打天下。
