CPA-Codex-Manager 是一款专为 OpenAI 账号池设计的高性能管理面板，支持全自动批量注册与 CLIProxyAPI 账号池监控。批量注册最大的拦路虎就是 OpenAI 的风控检测，而本项目基于 curl_cffi 库实现了多版本 Chrome 浏览器指纹伪装，从 TLS 加密层到请求头逐一对齐真实浏览器，帮助新手理解一套完整的"浏览器伪装"是怎么搭起来的。

为什么风控能"一眼识破"脚本？

很多新手以为只要把 User-Agent 改成 Chrome 字符串就能"伪装成浏览器"，其实这只做对了表面功夫。风控系统真正检测的，是浏览器藏在流量深处的"DNA"：

• TLS/HTTP2 指纹：真实 Chrome 发 TLS 握手时使用的加密套件顺序、ALPN 协议协商、HTTP2 帧类型排序、窗口大小等，都有固定的"指纹"。而 Pythonrequests库发出的流量，这些底层特征和浏览器完全不同，改 UA 也改不掉。
• 请求头一致性：Chrome 的sec-ch-ua（客户提示头）里声明的版本必须和 UA 里的版本号吻合，请求头的顺序也有固定规律，对不上就会被标记。
• 行为指纹：请求节奏是否机械、设备 Cookie 是否每次全新且格式正常等。

想骗过风控，必须让流量从底到表都像真的。这正是 requirements.txt 中curl_cffi>=0.14.0这个依赖存在的意义。

curl_cffi：一个参数伪装出完整浏览器指纹

传统 HTTP 库只能修改请求头，而 curl_cffi 的杀手锏是impersonate（伪装）参数——只要传入一个浏览器版本名，它会自动对齐：

• TLS 握手指纹（JA3/JA4 特征）
• HTTP2 帧结构
• 完整的浏览器请求头组合

比如本项目通用的 HTTP 客户端 http_client.py 中，RequestConfig默认impersonate: str = "chrome"，创建Session时直接传入即可：

self._session = Session( proxies=self.proxies, impersonate=self.config.impersonate, verify=self.config.verify_ssl, timeout=self.config.timeout )

对新手来说这意味着：不用手抄任何 TLS 参数，一行impersonate="chrome136"就让整个会话的底层流量伪装成 Chrome 136。

多版本 Chrome 配置表：不撞车的指纹池

批量注册场景下，如果几千个账号都带着同一个 Chrome 版本的指纹，风控很容易按"版本簇"批量拦截。所以 CPA-Codex-Manager 在 chatgpt_client_v2.py 中内置了一张多版本 Chrome 配置表：

_random_chrome_version()函数的策略是：

1. 随机挑一个版本配置；
2. 在补丁号区间内随机一个数，拼出完整版本号（如136.0.7103.127）；
3. 用该版本生成 User-Agent、sec-ch-ua等配套头。

这样每个注册会话分到的都是"不同版本 + 不同补丁号"的组合，指纹自然分散，避免了同版本指纹扎堆。

一致性是关键：从 sec-ch-ua 到设备 Cookie

只有 TLS 指纹还不够，表面请求头必须与所选版本严格一致。chatgpt_flow_utils.py 的build_browser_headers()负责构造"接近真实 Chrome 流量"的完整请求头：

• sec-ch-ua/sec-ch-ua-full-version：客户提示头，声明的 Chrome 版本与 UA 完全一致
• sec-ch-ua-mobile/sec-ch-ua-platform/sec-ch-ua-arch：平台信息声明（Windows / x86 / 64 位）
• Sec-Fetch-Dest/Sec-Fetch-Mode/Sec-Fetch-Site：按请求类型自动推导，导航请求还会加上Upgrade-Insecure-Requests、Sec-Fetch-User等真实浏览器才会带的头

另一处容易被忽略的细节是设备指纹。客户端初始化时会通过 chatgpt_flow_utils.py 的seed_oai_device_cookie()把一个新生成的oai-did设备 ID 预先写入 chatgpt.com、openai.com、auth.openai.com 等所有相关域名——模拟了真实浏览器首次访问时设备 Cookie 的行为，让后续每一步请求都"认得"这台设备。

一次注册、一份指纹：会话重置机制

批量注册中，每个账号应该对应一台"全新电脑"。chatgpt_client_v2.py 的_reset_session()在开启新任务时会整体重掷一次指纹：

• 重新生成随机device_id
• 重新调用_random_chrome_version()抽取 Chrome 版本
• 重建Session并刷新全套请求头与设备 Cookie

这保证了"一号一指纹"，前一个会话的指纹不会泄漏到下一个账号上。

protocol 与 headed：两档拟真度

客户端支持两种browser_mode，在 register_v2.py 中透传：

• protocol 模式：纯 HTTP 协议层伪装，速度快，适合大批量并发（最高 50 线程、1000 条任务）；
• headed 模式：在协议伪装基础上更接近真人浏览器——会附加Priority、DNT、Sec-GPC等真实 Chrome 才发送的头，并在每一步之间加入 0.15~0.45 秒的随机延迟，模拟人工操作节奏。

新手建议先跑 protocol 模式验证流程，再按需切到 headed 提升通过率。

不同模块选用不同 impersonate 版本

浏览源码可以发现一个有趣的设计：并非所有请求都用同一版本伪装，而是按场景匹配：

• 注册主流程（chatgpt_client_v2.py）：chrome131 / chrome133a / chrome136 随机
• Token 刷新（token_refresh.py）：impersonate="chrome120"
• 支付、账号上传、动态代理拉取等模块（payment.py、cpa_upload.py、dynamic_proxy.py）：impersonate="chrome110"
• Sentinel 质询（sentinel_token_v2.py）：可透传主会话的 impersonate，保证与注册流程指纹一致

版本适当"错开"反而更接近真实世界的浏览器分布——毕竟没有一台机器上的所有网络请求都来自同一个 Chrome。

新手避坑清单

总结

CPA-Codex-Manager 的浏览器伪装可以归纳为三层：curl_cffi 打底伪造 TLS/HTTP2 指纹→多版本 Chrome 配置表随机抽取，一号一指纹→请求头、设备 Cookie、行为延迟全面对齐真实浏览器。理解这套组合拳后，你再写任何需要对抗风控的自动化脚本时，都会有清晰的落地思路。