sub2api反代致OpenAI账号被封，踩坑复盘

背景

随着 OpenAI 推出 Codex CLI、Codex Desktop 等工具，开发者社区中出现了一类名为 sub2api 的轻量级反代方案。该方案能将单个 OpenAI 订阅账号（如 ChatGPT Plus）转化为可供多个客户端调用的 API 接口，从而绕过官方 API 的按量计费限制，实现“一份订阅多人共享”或“自动化服务低成本调用”。然而，这种非官方用法经常触碰上游的风控红线，导致账号被停用。近期 LINUX DO 论坛上的一篇帖子详细复盘了一次因 sub2api 反代导致 GPT 账号被封的全过程，揭示了自动化任务与正常使用混跑时的隐蔽风险。

核心内容

帖主操作了一个自动化服务，该服务通过 sub2api 反代持续向 OpenAI 发起循环式 Codex / SDK 请求。sub2api 的机制会基于客户端传来的 session_id、prompt_cache_key 等会话标识生成 session_hash，并将该 hash 粘性绑定到某个上游 OpenAI 账号。这意味着大量短任务会被集中发送到少数几个上游账号上。

从 OpenAI 服务端视角来看，被封的账号呈现如下特征：

• 同一出口 IP；
• 少数账号承载了绝大部分请求量；
• 大量短 session（即每次对话或任务很快结束）；
• 高 token 消耗；
• 自动化 agent 循环式请求；
• 请求形态与正常单人使用 Codex CLI、Codex Desktop 时产生的长会话模式截然不同。

帖子特别指出，被封的账号（代号 01）既不是请求数最高的，也不是 token 消耗最大的，因此排除了“单纯量大导致封号”的可能性。更合理的判断是：异常请求行为——尤其是 session 分布和反复新建 session 的模式——触发了上游的风控模型。

帖主总结了自己踩的几大坑：

1. 没有隔离流量：将自动化服务与正常 Codex 使用混在同一套账号池中。
2. 未设限流机制：没有对自动化任务的 session 数、并发数、单小时 token 上限、单日 token 上限做任何限制。
3. 短 session 泛滥：大量短任务不断生成新的 session，导致上游看到的 pattern 像无人值守的代理循环。
4. 缺少可观测性：反代层起初没有记录 session_id、session_hash、session_id_source 等字段，出问题后才补全。
5. 出口 IP 过于集中：少数上游账号承载了太多不同来源的流量，且全部来自同一出口 IP。

事件发生后，帖主采取了以下措施：

• 立即停掉高风险的自动化服务；
• 保留正常的 Codex Desktop / CLI 使用；
• 在 usage_logs 中补充 session_id、session_hash、session_id_source、session_explicit 等字段以增强追踪能力；
• 后续计划对自动化服务做账号隔离、并发限制、session 限制、token 限制以及熔断机制；
• 先观察剩余账号是否稳定，再决定是否补开新账号。

关键要点

• 反代可被上游识别：即使请求总量不大，异常的 session 特征（大量短 session + 同 IP + 少数账号）仍会触发风控。
• 自动化服务与正常使用必须分离：将 agent 循环和人类交互混用同一账号池是最高风险操作。
• 短 session 是危险信号：频繁新建 session 会让上游认为账号在运行无人值守的代理或滥用脚本。
• 限流必不可少：无限制的并发、token、session 数量会急剧放大异常特征。
• 可观测性应前置：反代层在初期就应记录 session 相关字段，否则遇到异常时无法快速定位根因。
• 出口 IP 的集中性会加剧风险：若所有流量都经同一出口，则账号的行为画像高度一致，容易被模板匹配。

意义与影响

这篇复盘对使用 sub2api 或类似反代方案的社区具有强烈的警示作用。它说明反代本身并非直接导致封号的原因，但不当的使用方式——特别是将高并发的自动化任务与正常用户长会话混在一起——会制造出高度异常的行为模式，使上游风控系统轻易识别。对于那些想通过反代节省成本但又需要运行自动化脚本的团队来说，必须做到账号隔离、限流熔断、session 监控三管齐下。此外，它也提醒开发者：反代层应尽早内置可观测性能力，否则事后补日志往往为时已晚。随着 OpenAI 持续收紧滥用检测，这类非标准接入方式的风险只会越来越高，社区的实践需要从“能用”转向“合规化隔离使用”。