ChatGPT Plus 不等于 API Key：Codex 代理与多人使用方案梳理
很多人买了 ChatGPT Plus 才发现它和 OpenAI API Key 是两套体系，接 Codex CLI、Claude Code 时接连卡在代理、转换层和多人共用上。本文拆开讲清订阅与 API 的账务关系、按进程和按域名的代理分流思路、转换层的适用边界，以及多人使用的合规做法与检查清单。
不少人第一次买 ChatGPT Plus 时，会默认它自带 API 额度，直到把 key 填进第三方工具、发现根本不通，才意识到这是两个产品。等把订阅接进 Codex CLI、又想接到 Claude Code 上，问题会集中爆发：代理必须开吗、要不要加一层转换、能不能几个人一起用。
下面按「账务关系 → 网络接入 → 工具间转换 → 多人共用」的顺序拆开讲，给出可以直接照做的配置思路，也标出需要自己确认的边界。
先分清：订阅和 API 是两套东西
| 维度 | ChatGPT Plus 订阅 | OpenAI API |
|---|---|---|
| 计费方式 | 按月订阅 | 按 token 用量计费 |
| 凭证形态 | 账号登录 | API Key |
| 典型场景 | 网页、官方客户端、部分官方工具 | 程序调用、第三方工具接入 |
| 额度 | 订阅内限额 | 单独充值，用多少扣多少 |
结论很直接：想让 Claude Code 这类第三方工具用上，需要的是 API Key，Plus 订阅不能直接当 key 用。Codex CLI 本身支持用 ChatGPT 账号登录（走订阅额度），也支持配 API Key，具体支持哪些登录方式以官方文档的最新说明为准。
手上只有 Plus 时，任何「把它转成 key 给别的工具用」的做法都是在借道，不属于官方支持的用法，稳定性和账号安全都要自己承担。
本地跑 Codex，代理不是只有「全局」一种选择
系统代理（含 TUN 模式）最省事，代价是所有流量都跟着走，访问国内站点可能变慢或出异常。实际可以按三个粒度选：
- 全局 / TUN：一次配置长期有效，适合懒得折腾、且能接受全量转发的人。
- 应用级分流：在桌面代理客户端里按进程或域名匹配，只让相关请求走代理。部分客户端支持按应用匹配，比纯域名规则更干净。
- 进程级环境变量：只给单条命令加代理，不影响其他任何程序。
进程级写法最轻量，适合临时验证：
# macOS / Linux：只对当前这条命令生效
https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 codex
# Windows PowerShell
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
codex
端口要和代理客户端的混合端口一致，7890 只是常见默认值，不是通用值。想持久化就写进 shell 的 rc 文件，或者工具的 .env 里，避免每次都手敲。
按域名分流的思路是把 OpenAI 相关域名（如 openai.com、chatgpt.com、oaistatic.com、auth0.com）加入独立规则集，其余流量直连。域名规则容易漏，尤其是登录跳转和静态资源，遇到页面能开、功能报错的情况，先怀疑规则集不全。
需要提醒的是：以上只解决「哪些流量走代理」，不解决「账号能不能在该地区正常使用」。OpenAI 的服务只在部分国家和地区提供，注册地、登录 IP、支付方式不一致都可能触发风控；使用前请确认自己的地区与账号状态符合官方条款和当地法律法规，具体要求以官方最新说明为准。
至于在国外 VPS 上自建一层转发（各类 api 网关类工具），好处是一处配置多设备复用，手机、平板、多台电脑不用各配一遍；代价是云厂商 IP 段被大量复用，容易被判定为异常流量，密钥也留在了第三方机器上。这类做法适合自用自维护，不适合对外提供。
把 Plus 接到 Claude Code：能转，但不建议长期依赖
中间层工具（各种 switch 类客户端、api 转换网关）的原理都差不多：把 Anthropic 风格的请求翻译成 OpenAI 风格，再拿某个凭证去请求上游。
对这件事有两种态度，各有道理：
- 没必要转：两个工具各自用官方凭证，工具调用、长上下文、流式输出都不容易出问题，账目也清楚。
- 先转起来：成本低、上手快，用来试水或学习够用。
差异主要体现在适用场景上：转换层适合短期验证和个人试验；一旦进入长任务、自动化流程或多人依赖，风险就会放大——上游改协议、加参数或调整风控，整条链会突然断掉，而且报错往往很难定位是翻译层的问题还是上游的问题。
更稳妥的路径是：Claude Code 用 Anthropic 官方 key 或官方支持的接入方式，Codex 用它的登录方式，两边各自计费。如果本地机器性能有限，或者需要长时间挂着跑这类会持续发请求的工具，也可以考虑租用一台位于受支持地区的远程 Mac（整机独享、按月使用），把运行环境和出网环境一起放到远端，本地只做连接，适合长期在线跑任务。
多人共用：风险最高的一环
共享同一个订阅账号，属于违反服务条款的做法，风险不只是「可能被封」：额度互相挤占、出问题无法定位、凭证散落在多人手里收不回来、账号状态异常时所有人都停摆。这类做法不适合团队协作。
合规替代方案：
- 官方团队/企业席位：按人头订阅，每人有独立账号和独立设置。
- API 组织：给成员或项目分别签发 key，设置用量上限和预算告警，定期轮换。这是多人共用一套能力最标准的做法。
- 共享执行环境而非账号：需要一台长期在线的机器跑任务时，共用机器、各自用独立凭证，比共用账号安全得多。
落地检查清单
- 确认凭证类型：要的是订阅登录，还是 API Key，别买错。
- 代理粒度优先选应用分流或进程环境变量，尽量不用全局。
- 核对客户端端口，别照抄 7890。
- 临时验证用命令行环境变量，稳定后再写进配置文件。
- 域名规则集要覆盖登录跳转和静态资源域名。
- 转换层只用于临时验证，不上生产、不长期依赖。
- 多人协作走官方席位或 API 组织，不共享账号。
- 定期查看用量和账号状态，异常时先停再查。
小结
Plus 订阅和 API Key 是两条独立的线，买之前先想清楚要接什么工具；代理解决的是「怎么连出去」，改变不了「能不能用」，地区与账号合规问题要单独确认；转换层能省一时的配置成本，长期稳定性不如各用各的官方凭证；多人共用订阅账号是最容易出事的一环，有预算就走官方席位或 API 组织。涉及计费规则、地区支持和条款细节的部分，请以官方最新说明为准。
