自建Claude code镜像服务，同时支持Gemini cli、Codex中转，支持多账户切换、自定义API密钥、Claude API、OPENAI兼容格式、能有效规避封号，OAuth集成可快捷添加账号池。
类似项目还有：https://github.com/yushangxiao/claude2api
这些项目的核心需求是用户想让自己的账号转成 API 让更多人用，网上一些拼车也类似这些，如果有动手能力，可以试试，如果没有，可以去往上买现成的中转站
一、项目简介 & 核心定位
这个项目的中文说明写得比较直接：
“自建 Claude API 中转服务，支持多账户管理 … 一站式开源中转服务，让 Claude、OpenAI、Gemini、Droid 订阅统一接入，支持拼车共享，更高效分摊成本，原生工具无缝使用。” ([GitHub][1])
也就是说，其本质是一个「中继 / 代理 / 转发」服务（relay service），用于在你自己控制的服务器上搭建一个统一的入口，前端或客户端向这个中继服务发请求，中继再把请求转发给多个后端 AI 服务（Claude、OpenAI、Gemini、Droid 等）。这个中继还能做账户管理、流量/成本统计、智能切换等额外功能。
主要用途可以总结为：
- 把多个 AI 服务账号统一汇聚在一个 “relay” 节点里。
- 给不同使用者（或客户端）分配 API Key，由 relay 控制访问权限、速率、并发等。
- 实现 “拼车 / 多人共用一个订阅 / 账号池” 的目的，以分摊成本。
- 避免前端或用户直接暴露真正的后端账号（密钥暴露、滥用风险）。
- 提高稳定性：如果某个账户或节点异常，中继能自动切换或剔除。
- 允许统一监控、统计 token 使用、性能指标等。
二、主要功能 & 架构组件
基于项目的 README / 文档，这里是它的关键模块 /功能点：
| 模块 / 功能 | 作用 / 说明 |
|---|---|
| 多账户管理 | 可以在后台添加多个 Claude / Gemini / OpenAI 等账号，让中继服务从这些账号中轮换或智能选取 |
| API Key 管理 | 给使用者（客户端）发放中继层面的 API Key，用这个 Key 来访问中继服务。中继拿到请求后，用后端账号去实际调用 AI 服务。 |
| 访问控制 / 限流 / 并发控制 | 可以为每个使用者的 Key 设置访问速率、Token 限制、并发数等，控制滥用。 |
| 智能切换 / 容错 | 当某个后端账号不可用（如被封禁、到期、API 出错等），中继可以自动切换到另一个可用账号继续服务。 |
| 性能优化 / 连接池 / 缓存 | 减少延迟、提升吞吐能力。文档中提到“连接池、缓存”作为性能优化手段。 |
| 监控 / 使用统计 | 在 Web 界面上展示各账号 / 使用者的 token 使用、消耗费用、响应性能等指标。 |
| 安全控制 | 包括访问限制、速率控制、客户端限制（User-Agent 白名单 / 限定哪些客户端可用）等。 |
| 代理 / 网络支持 | 支持 HTTP / SOCKS5 代理，用以绕过网络限制或访问后端服务。 |
| 多种服务兼容 / 路由分发 | 根据不同路径（比如 /claude/、/openai/、/gemini/、/droid/claude/ 等）来识别请求的服务类型，转发到对应类型的账号池。 ([GitHub][1]) |
| 前端界面 / 管理后台 | 提供 Web 管理页面，让管理员添加账号、创建 API Key、看统计、调优设置等。 |
| 部署方式多样 | 支持脚本一键部署、Docker / docker-compose、反向代理（Caddy / Nginx）等。 |
三、使用场景 / 适合人群
从 README 的“这个项目适合你吗？”那段话看，作者明确提到以下几类人可能会用到这个项目：
- 地区被限制 / 访问 Claude 服务不便的用户。
- 想用多个账号拼车分摊成本的用户。
- 担心第三方镜像 / 公共中继泄漏对话内容，希望自己掌控中继节点。
- 对技术有一定基础，愿意自己维护部署中继服务。
- 需要稳定、长期的 Claude 访问，不愿意依赖公共镜像不稳定性。
也就是说，这个项目主要面向那些：
- 希望自己搭建一个代理 / 中继层，把 AI 服务集中管理；
- 有多个账号或多人共用账号池的需求；
- 想对访问、权限、成本做可控管理；
- 有一定运维能力，希望部署、监控、容错自己掌控。
四、优点 / 好处
这个中继 / relay 设计有一些很明显的优点：
- 安全性 & 隐私控制
用户对话不会直接暴露给公共镜像站点或第三方服务商，只流经你自己部署的中继节点。 - 分摊成本 / 多账号池
多人可以共享一个账号池，中继帮你做负载分配和切换，从而更经济高效。 - 统一入口 + 兼容多后端
前端统一调用你部署的中继服务，无需自己管理多个不同服务的接口、地址、鉴权方式等兼容问题。 - 控制能力
可以针对不同使用者、Key 做访问控制、限流、监控、使用统计等。 - 稳定性 / 异常恢复
如果某个后端账号出现异常，中继可以自动剔除或切换到备用账号，减少服务中断风险。 - 运维自控
你可以看到、管理所有中继层面的日志、状态、性能指标等，不依赖于公共服务商的透明度。
五、风险、挑战与限制
这个项目虽然功能丰富，但也有一些需要注意或可能的风险 / 限制：
- 违反服务条款风险
在 README 中就有警示：“使用本项目可能违反 Anthropic 的服务条款。使用本项目的一切风险由用户自行承担。”
换句话说，这种中继 / 拼车 / 转发方式在官方的用户协议或服务条款中可能不被允许。 - 账号封禁 / 被降权
如果多个用户共享账号池，若某个使用者行为违规，会有被封号 / 降权的风险，连带影响所有人。 - 中继性能瓶颈 / 延迟
虽然有连接池、缓存优化，但中继本身仍是一个额外的网络跳点，可能会带来延迟或吞吐瓶颈。 - 运维与维护成本
虽说最低配置不高（1 核、512 MB、30GB 硬盘等）就能跑，但要保障稳定性、高可用、数据备份、监控、异常恢复、升级回滚等运维工作。 - 网络访问 / 各地限制
从国内访问 Anthropic / Claude 的网络条件、跨境链路、被拦截的可能性都可能影响服务质量。文档中也提到在有些云商 /线路上可能被 Cloudflare 拦截访问等问题。 - 安全 / 加密风险
虽然中继可以做 API Key、加密、访问控制，但如果部署不当、秘钥管理不严密，也可能成为新的攻击面。 - 同步 / 版本兼容
后端服务（Claude、OpenAI、Gemini 等）的 API 协议、版本变动、鉴权方式更新等可能会导致中继要及时兼容更新。
六、技术细节 / 核心设计要点（高层次）
虽然我没有深入逐行代码调试，但根据文档和项目结构，可以推测其核心设计思路如下：
- 路由与路径识别
中继会根据请求的路径前缀（如/claude/、/openai/、/gemini/、/droid/...等）来确定这是调用哪类服务，从而选择相应的账户池进行转发。 - 请求封装 & 转换
前端请求到中继之后，中继会把请求按后端服务的需求重新封装（可能是 JSON body 转换、Header 调整、鉴权 token 注入等），然后转发给后端服务。 - 鉴权 / API Key 验证
使用者发给中继的请求必须带上由中继发放的 API Key。中继首先验证这个 Key，然后才允许访问并转发到后端。中继还能看 Key 的权限配置（速率限制、并发数、可访问模型等）来限制请求。 - 负载 / 轮询 / 切换策略
当有多个后端账号可用时，中继要决定如何分配请求：是轮询、加权、优先级、负载均衡、出错重试等。若某个账号出错、中断或被封禁，中继要剔除或切换到下一个账号。 - 监控 / 统计模块
中继会记录每个 Key / 每个账号的 token 消耗、请求次数、错误率、延迟等指标，并把这些数据显示在管理界面。 - 缓存 / 连接池 / 优化
可以缓存部分响应、复用 HTTP Keep-Alive 连接、管理连接池数、减少频繁建立连接的开销。 - 后台管理界面 + 前端 SPA
项目包含一个管理前端界面 (Admin SPA) 用于操作账号、Key、监控等。后台提供 API 支持这个界面。 - 配置 / 环境 /部署
支持.env、config 文件、Docker / docker-compose 部署方式，以及反向代理（Caddy / Nginx）接入等。
七、如何使用 / 部署流程（高层概要）
假设你要自己搭建这个中继服务，以下是典型流程（根据 README）：
- 环境准备：Linux 服务器，安装 Node.js 18+、Redis。
- 克隆代码，配置
.env和config。 - 安装依赖 (
npm install)，构建前端 (npm run build:web)。 - 初始化管理员账号 (
npm run setup)。 - 启动服务（守护进程 / 后台运行模式） (
npm run service:start:daemon)。 - 打开管理界面（浏览器访问
http://服务器:3000/web），登录管理员。 - 在后台添加后端账号（Claude、OpenAI、Gemini 等），完成 OAuth 授权 / 密钥配置。
- 在后台创建使用者的 API Key，并为其配置访问权限（速率、并发、模型限制等）。
- 外部客户端 / 前端或工具仅访问中继服务的 API 端点（替代直接调用 Claude / OpenAI），带上获得的 API Key。
- 中继内部根据路由、Key 权限、账号池做转发、监控与统计。
部署时通常配合反向代理（如 Nginx / Caddy）来加 HTTPS/SSL、域名绑定、日志与安全控制。
八、总结 / 对你是否有用
这个项目是一个很有意思的 “AI 服务中继 / 账号池管理” 工具。对于那些想自己管理 AI 接入、不想完全依赖公共镜像、希望把多个账号统一调度、希望监控 / 控制访问行为的人来说，非常有价值。但同时也不是 “即装即用、零风险” 的方案：它涉及运维、安全、合规风险。
