Cockpit 反代教程：JSON 导入 + API 服务配置，账密登录拜拜

为什么需要反代

先问一个问题：为什么有人要搞一堆 Codex 账号？

答案很简单——额度不够用。Codex 免费额度有限，Plus 订阅也有每日上限。写代码写到一半被限额真的很扫兴。

于是就有了一个需求：手上有多个账号，怎么让它们轮着用？

最原始的办法：

浏览器登录账号 A → 用完了 → 退出
浏览器登录账号 B → 用完了 → 退出
切来切去，烦死了

反代要解决的，就是这个问题。

反代在这件事里做了什么

「反向代理」这个词放在这个场景下，实际干的事可以拆成三层：

第一层：请求劫持 + Token 注入

Codex CLI 以为自己直接连 OpenAI，实际上请求被本地代理工具截住了。这个工具把 Refresh Token 附加到每个请求上，冒充登录状态。

Codex CLI → 本地反代工具（注入 RT）→ OpenAI API

没有反代的时候，Codex 需要浏览器登录，因为那层认证在浏览器里。有了反代，认证信息直接在代理层注入，浏览器那一步就省了。

第二层：多账号调度

一个账号额度用完 → 自动切到下一个。

                      → 账号 A（额度耗完）
Codex CLI → 反代工具 ─→ 账号 B（工作中）
                      → 账号 C（排队）

这就是「账号池」。你塞几十个账号进去，反代工具帮你做负载均衡。哪个有额度就调哪个，你不用管。

第三层：统一 API 出口

所有账号聚合后暴露一个统一的 API 地址，比如 http://localhost:9090/v1。把 Codex 请求地址改成这个，剩下的交给反代工具。

代理的四种形态

讲清楚上面的事之后，有必要理一下四种代理的区别——不然你去看别的教程很容易被「反代」「正向代理」「透明代理」这些词搞晕。

正向代理（Forward Proxy）

你上不了某网站，找一台能上的服务器帮你去拿。

你的电脑 → 正向代理服务器 → 目标网站

目标网站看到的是代理的 IP，不是你的。你明确知道要去哪，代理帮你跑腿。

反向代理（Reverse Proxy）

反过来——客户端不知道最终请求落到哪台服务器。

客户端 → 反向代理（Nginx/Cockpit）→ 后端 A/B/C

在 Codex 场景里，Cockpit 就是那个反向代理。CLI 以为自己在跟 OpenAI 直接通信，实际上请求被 Cockpit 截住、附加 token、转发出去。背后是哪个账号在工作，CLI 完全不知道。

透明代理（Transparent Proxy）

你在家里上网，网关默默劫持了你的请求，你甚至不知道它的存在。

你的电脑（无感知）→ 网关（透明代理）→ 目标网站

公司上网行为管理、路由器广告过滤都是透明代理。在薅羊毛场景里，透明代理有时被用来批量劫持流量。

SOCKS5 / HTTP 代理

最传统的代理。你手动配一个 IP 和端口，应用通过它发请求。

浏览器/App → SOCKS5 代理（127.0.0.1:7890）→ 目标网站

Telegram 设置代理、浏览器 VPN 插件都是这种。Cockpit 的 API 服务也可以让局域网内机器通过 HTTP 代理方式连过来用你的账号池。

Token 原理：反代到底是怎么过 OpenAI 认证的

很多教程说「有了 refresh_token 就能调 Codex」，这话对了一半。

实际上反代工具做的事比「注入一个 token」复杂得多。它本质上是 OAuth Token 管理器 + 请求头规范化代理，中间经过了好几层处理。

Codex CLI 是怎么认证的

和 ChatGPT 网页版完全不一样。ChatGPT 网页版依赖浏览器 Cookie + session token，而 Codex CLI 走的是 OAuth 2.0 设备码流（Device Authorization Grant）：

1. CLI → OpenAI：请求设备码（POST /api/auth/device/code）
2. CLI 打印一个链接给你：去浏览器打开，输入验证码
3. 你在浏览器授权后，CLI 轮询获得 refresh_token
4. CLI 用 refresh_token 换取短期 access_token（POST /api/auth/refresh）
5. access_token 挂了调用 /chat/completions

整个流程不依赖任何 Cookie。这是理解反代的关键前提。

Cockpit 在中间做了什么

当你把 JSON 导入 Cockpit 并启动后，每次请求的实际流程是这样的：

Codex CLI → Cockpit（拦截）
              │
              ├─ 检查缓存的 access_token 是否过期
              │   ├─ 没过期 → 直接用
              │   └─ 过期了 → 用 RT 调 /api/auth/refresh 换新的 AT
              │
              ├─ 替换请求头：
              │   ├─ Authorization: Bearer <新的 access_token>
              │   └─ User-Agent: openai-codex-cli/1.0  ← 关键！
              │
              ├─ （可选）改写请求体
              │   └─ 比如修正 model 名称、补充参数
              │
              └─ 转发到 OpenAI 后端

所以不是「拿到 RT 直接注入」就完事了。Cockpit 干了几件脏活：

1. Token 交换 用户提供的 JSON 里放的是 refresh_token（长期有效），但 OpenAI 的模型推理接口根本不认 refresh_token。Cockpit 需要主动调用 /api/auth/refresh 把它换成 access_token（JWT，有效期约 30 分钟），然后在后续请求的 Authorization 头里带上这个 access_token。

2. 自动续期 access_token 只有 30 分钟寿命。Cockpit 会在收到 401 或者检测到 token 即将过期时，自动用 refresh_token 换新的。用户完全无感。

3. User-Agent 伪造 这是很多人忽略的一点。OpenAI 的 Cloudflare WAF 会检查请求的 User-Agent 头。如果你直接用 curl 或 python-requests 去请求，User-Agent 是 python-requests/2.x 或 curl/8.x，直接给你 403 拦了。

Cockpit 会自动把 User-Agent 改成 openai-codex-cli/1.0，让后端以为请求来自官方 CLI，放行通过。

4. 请求体适配 有些客户端的请求体格式和 Codex CLI 不一样（比如 model 名称不同），Cockpit 可能会自动做负载重写——修正 model 字段、删除不支持参数、补充 stream 标记等。

总结

你以为是	实际是
反代工具拿 RT 直接调 API	用 RT 换 AT，再用 AT 调 API
只需要改 Authorization 头	还要改 User-Agent、可能改请求体
一次注入搞定	每 30 分钟自动续一次
浏览器那套认证	OAuth 2.0 设备码流，无 Cookie

所以反代的核心价值不是「注入 token」，而是 把一套复杂的 OAuth 凭证管理 + 反爬对抗逻辑封装成一个本地服务，你只管把请求地址改成 localhost 就行。

为什么不同反代工具的 JSON 格式不一样

用过几个工具的人应该注意到了：Cliproxy2API 的 JSON、sub2api 的 JSON、Cockpit 的 JSON，字段名和结构都不一样。

原因很简单——这些工具是不同的人写的，没有统一标准。

一段最原始的 ChatGPT session JSON 长这样：

{
  "accessToken": "eyJhbGciOi...",
  "refreshToken": "eyJhbGciOi..."
}

但到了各个工具手里，格式就各自为政了：

工具	格式特点
Cliproxy2API（CPA）	字段名带 `cpa_` 前缀，按邮箱分目录，适合 CLI 代理场景
sub2api	多层嵌套结构，包含代理链路配置信息，适合路由器/服务器部署
Cockpit	扁平结构，数组套对象，一个 token 一行，设计简单直接

打个比方：同一个人去银行、酒店、公司 HR 登记，填的表都不一样。数据是同一份，但每个系统有自己的字段结构。

你从卡密网站买的 JSON 一般是 CPA 或 sub2 的格式。如果你要用 Cockpit，就需要先做格式转换。下面开始实操。