背景时有人和我说sub2api 可能不被codex 支持了，另外就是 CLIProxyAPI 被官方支持，但是 CLIProxyAPI 基本上可以认为是一个服务端的 ccswitch，如果只是 CLIProxyAPI 还不足以公司内部分配使用/监控。
这次尝试并不是为了主动替换 Sub2API。
起因是一个更直接的问题：如果有一天 Sub2API 因为版本、维护、部署环境或其他原因无法继续使用，现有的模型账号和内部用户是否还有一条可以较快恢复的服务链路？
基于这个问题，我们在沙箱中搭建并验证了一个组合方案：
New API + CLIProxyAPI
它的目标不是复刻 Sub2API 的全部实现，而是在原系统不可用时，先恢复几个最基本的能力：
- 给内部用户提供统一 API 地址。
- 为不同使用者签发独立 API Key。
- 接入现有模型账号。
- 提供基础模型权限、额度和调用日志。
- 保留后续迁移或回切的空间。
本文记录这套备用链路的结构、已验证范围和仍然存在的缺口。
备用链路结构
Codex / OpenAI SDK / 内部应用
|
| New API Key
v
New API（对外网关）
- 用户与 API Key
- 模型和分组权限
- 额度与调用日志
- 渠道路由
|
| 内部专用 Key
v
CLIProxyAPI（上游适配）
- OAuth 认证文件
- 多账号选择
- 账号状态维护
- 协议转换
|
v
官方模型服务
部署环境需要统一出口时，再增加一层本机代理：
CLIProxyAPI -> Hushsocks -> 上游服务
普通使用者只接触 New API。CLIProxyAPI、认证目录和 Hushsocks 都只监听本机地址，不直接暴露给下游用户。
为什么需要两个项目
单独使用其中任何一个项目，都不能直接覆盖我们需要的最小范围。
New API 有用户、API Key、分组、额度和日志，但它并不擅长完成订阅账号的首次登录和账号池维护。
CLIProxyAPI 可以管理 Codex 等账号并提供兼容接口，但它的多个入口 Key 更接近多个访问凭据，不是完整的多用户、额度和运营体系。
因此在备用方案中，两者分别承担一部分工作：
New API：面向内部使用者
CLIProxyAPI：面向上游模型账号
这只是为了补齐应急链路，不代表这种拆分一定优于 Sub2API 的一体化实现。
应急覆盖范围
| 能力 |
Sub2API |
当前备用链路 |
验证情况 |
| 统一 API 地址 |
内置 |
New API |
已验证 |
| 下游 API Key |
内置 |
New API |
已验证 |
| 用户与分组 |
内置 |
New API |
基础能力已验证 |
| 模型权限 |
内置 |
New API |
已验证 |
| OAuth 账号接入 |
内置 |
CLIProxyAPI |
已验证 |
| 多账号选择 |
内置 |
CLIProxyAPI |
基础能力已验证 |
| OpenAI 兼容接口 |
内置 |
两层组合 |
已验证 |
| 模型列表 |
内置 |
两层组合 |
已验证 |
| 调用日志 |
内置 |
New API |
基础能力已验证 |
| 精细计费 |
内置 |
New API 配置 |
尚未完整对齐 |
| 运营管理 |
内置 |
New API |
尚未完整对齐 |
| 全协议兼容 |
内置 |
依赖两层转换 |
需要继续测试 |
| 故障恢复 |
单服务体系 |
多服务组合 |
需要额外运维 |
备用链路能够先恢复日常调用，但不能直接声明为完整替代。特别是计费口径、协议细节、错误处理和运营流程，需要单独核对。
存储方式
New API 和 CLIProxyAPI 的存储方式不同。
New API 的用户、渠道、Key、额度和日志存放在数据库。沙箱使用 PostgreSQL，并在现有数据库中创建独立 schema：
PostgreSQL database
├── public -> Sub2API
└── new_api -> New API
New API 的连接固定为：
search_path=new_api
没有配置 new_api,public 的回退路径，避免 New API 在迁移期间命中 public 中的同名表。实际验证中，New API 的表全部创建在 new_api，Sub2API 的 public 表没有发生变化。
CLIProxyAPI 主要使用文件：
config.yaml 服务配置和内部 Key
auth/*.json OAuth 认证凭据
plugins/ 可选插件
logs/ 可选日志
这意味着认证目录必须放在持久化磁盘，并纳入权限控制和备份。它不像数据库那样方便做集中查询和变更审计，是备用方案中需要接受的运维成本。
单机沙箱部署
目前的目标规模是单企业、100 人以内团队，先用单机验证恢复链路是否成立。
沙箱中的服务布局为：
New API 0.0.0.0:3000
Sub2API 0.0.0.0:8080
CLIProxyAPI 127.0.0.1:8317
Hushsocks 127.0.0.1:1080
Prompt Guard 127.0.0.1:8000
目录结构如下：
/opt/sub2apideployhome/
├── app4yun/
├── sub2api/
├── newapi/
├── cliproxyapi/
│ ├── config.yaml
│ └── auth/
├── hushsocks/
├── prompt_guard_stub
└── sub2api.start.sh
统一启动脚本按顺序启动并探活各个服务。任一关键进程退出时，启动脚本结束整组进程，由云平台重新拉起。
这种方式便于沙箱部署，但也意味着单个新增服务启动失败时，其他进程会一起退出。它适合作为当前验证方式，不应直接视为最终高可用设计。
搭建中遇到的问题
1. Linux amd64 不等于一定兼容
首次使用的 New API 官方 Linux amd64 二进制是动态链接版本，要求较新的 glibc：
GLIBC_2.32
GLIBC_2.34
沙箱系统只有 glibc 2.28，因此二进制在启动前就无法加载。由于统一启动脚本会结束整组进程，最终表现为所有服务都没有运行。
处理方式是基于同一版本源码重新构建静态二进制：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build
重新打包后确认：
ELF 64-bit x86-64
statically linked
这次问题说明，应急包不能只检查文件名中的 linux_amd64，还要检查：
file binary
ldd binary
2. New API 模型需要配置渠道和价格策略
New API 创建渠道后，不能只填写上游地址和 Key。还需要同步实际模型列表，并选择合适的价格或自用模式，否则测试请求可能在到达上游前被 New API 拒绝。
沙箱采用自用模式，只用于验证内部链路，不代表正式计费配置已经完成。
3. CLIProxyAPI 的认证目录需要单独维护
CLIProxyAPI 的账号信息保存在文件中。账号导入、备份、权限和迁移都需要明确操作流程。对少量管理员维护的单机环境尚可接受，但如果后续发展为多节点，需要重新评估存储和同步方式。
当前已验证内容
沙箱中已经完成以下检查：
- New API PostgreSQL schema 初始化。
- New API 连续启动迁移。
- New API 与 Sub2API 表空间隔离。
- CLIProxyAPI 读取认证文件。
- New API 通过内部 Key 访问 CLIProxyAPI。
- New API
/v1/models 返回模型列表。
- New API 和 Sub2API 页面探活。
- Hushsocks 建立上游连接。
- Linux 静态二进制在旧 glibc 环境下的兼容修复。
- 整体部署包的 SHA-256 和文件权限检查。
尚未完成或需要扩大验证的内容：
- 长时间并发稳定性。
- 所有模型和协议的逐项测试。
- 流式响应、工具调用和图片接口的完整回归。
- 与 Sub2API 一致的计费结果对比。
- 多用户额度和限流边界测试。
- 日志清理、数据库备份和恢复演练。
- 单服务故障时的独立恢复能力。
什么时候启用备用链路
这套组合更适合作为预案，而不是在当前系统正常时立即切换。
建议触发条件包括：
- Sub2API 无法在目标环境启动，短期内无法修复。
- Sub2API 发布包或依赖不可获得。
- 升级后核心接口出现阻断性问题，需要临时回避。
- 需要在修复主系统期间维持内部模型调用。
启用时可以分三步进行：
- 先由少量体验用户验证模型列表和基础请求。
- 再逐步签发 New API Key，观察错误率和日志。
- 主系统恢复后，根据实际情况选择回切或继续并行评估。
结论
New API + CLIProxyAPI 是一次面向故障场景的可行性验证。
它证明了当 Sub2API 暂时不可用时，可以通过两个现有项目重新拼出一条基本可用的内部 API 链路。但这套组合增加了服务数量，也带来了认证文件、跨服务日志、兼容性和故障联动等新的运维问题。
因此当前更准确的定位是：
一套已经跑通基础链路的 Sub2API 应急备选方案。
它是否值得长期保留，需要等并发、协议、计费和恢复演练完成后再决定。现在的价值主要是降低单一实现不可用时完全中断服务的风险。