其中的模型表 空了，空了，是gpt 拿走了？？？ 3 个帖子 - 3 位参与者 阅读完整话题
model_provider = "cliproxyapi" model = "gpt-5.4" model_reasoning_effort = "xhigh" service_tier = "fast" 上面是我codex 模型配置，我看cpa日志，是不会用gmini和claude的供应商，有啥办法在codex会话里面切换或者让cpa自动切换吗 随便再问一下，cpa里面ai供应商的那个前缀配置怎么用啊 2 个帖子 - 2 位参与者 阅读完整话题
昨天，在群里小伙伴的提醒下，我了解到通过反代 Codex 也可以进行图片的生成和编辑了。随即我进行了一番实验，使用 GPT-Image-1.5 成功生成了如下图片： 技术原理：工具调用（Tool Calling） 与 Gemini 使用专用图片模型（如 NanoBanana 系列）的逻辑不同，在 Codex 中，生图功能是通过 调用工具 实现的，并不依赖特定的模型名称。 基于这一特性，我们可以利用 CLIProxyAPI 的 模型别名 配合 Payload 重写 功能，自定义一套专属的“文生图模型”。下面我分享一下自己的配置思路和使用方法，希望能起到抛砖引玉的作用。 PS：下文前提是已经安装配置好 CLIProxyAPI 并添加了 Codex 的 OAuth 凭证。 1. 配置文件修改 在 CLIProxyAPI 的配置文件中添加以下内容。这里我们将 gpt-5.4-mini 映射为不同分辨率的生图模型，并通过 Payload 强制开启 image_generation 工具。 oauth-model-alias: codex: - name: gpt-5.4-mini alias: gpt-image-1024x1024 fork: true - name: gpt-5.4-mini alias: gpt-image-1024x1536 fork: true - name: gpt-5.4-mini alias: gpt-image-1536x1024 fork: true payload: override-raw: - models: - name: gpt-image-1024x1024 protocol: codex params: tools: '[{"type":"image_generation", "size": "1024x1024", "quality": "high", "background": "auto"}]' tool_choice: '{"type": "image_generation"}' - models: - name: gpt-image-1024x1536 protocol: codex params: tools: '[{"type":"image_generation", "size": "1024x1536", "quality": "high", "background": "auto"}]' tool_choice: '{"type": "image_generation"}' - models: - name: gpt-image-1536x1024 protocol: codex params: tools: '[{"type":"image_generation", "size": "1536x1024", "quality": "high", "background": "auto"}]' tool_choice: '{"type": "image_generation"}' 添加完成后，我们就可以直接调用 gpt-image-1024x1024 、 gpt-image-1024x1536 和 gpt-image-1536x1024 这三个自定义模型了。 2. 快速调用脚本 (PowerShell) 由于目前我还未找到好用的生图客户端，我编写了一个简单的 Windows PowerShell 脚本供大家参考。 使用方法： 修改脚本前四行的 apiUrl 、 apiKey 等参数。 将完整脚本粘贴至 PowerShell 窗口运行。 等待约数十秒，即可在当前运行路径下看到生成的图片。 $apiUrl = "https://你的CLIProxyAPI地址/v1/responses" $apiKey = "你的CLIProxyAPI的apikey" $model = "gpt-image-1536x1024" $text = "画一张赛博朋克的香港，要有汉字" $bodyObject = @{ model = $model instructions = "You are a helpful assistant." input = @( @{ type = "message" role = "user" content = @( @{ type = "input_text" text = $text } ) } ) parallel_tool_calls = $true reasoning = @{ effort = "high" summary = "auto" } stream = $true store = $false include = @( "reasoning.encrypted_content" ) } $body = $bodyObject | ConvertTo-Json -Depth 100 -Compress $outBase = "generated" $utf8NoBom = New-Object System.Text.UTF8Encoding($false) $tempBodyFile = Join-Path $env:TEMP ("response-body-" + [guid]::NewGuid().ToString("N") + ".json") [System.IO.File]::WriteAllText($tempBodyFile, $body, $utf8NoBom) try { curl.exe --silent --show-error --no-buffer ` -X POST $apiUrl ` -H "Content-Type: application/json" ` -H "Authorization: Bearer $apiKey" ` --data-binary ("@" + $tempBodyFile) | ForEach-Object -Begin { $eventType = $null $dataLines = [System.Collections.Generic.List[string]]::new() function Save-Bytes { param([string]$Path, [string]$Base64) [System.IO.File]::WriteAllBytes($Path, [Convert]::FromBase64String($Base64)) Write-Host "Saved $Path" } function Save-ImageGenerationCallResult { param([object]$ImageCall) if (-not $ImageCall) { return } if ($ImageCall.type -ne "image_generation_call") { return } if (-not $ImageCall.result) { return } $ext = if ($ImageCall.output_format) { [string]$ImageCall.output_format } else { "png" } $path = Join-Path (Get-Location) "$outBase.$ext" Save-Bytes -Path $path -Base64 ([string]$ImageCall.result) } function ConvertFrom-JsonCompat { param([string]$Json) if ($PSVersionTable.PSVersion.Major -ge 6) { return $Json | ConvertFrom-Json -Depth 100 } return $Json | ConvertFrom-Json } function Flush-SseEvent { param([string]$Type, [System.Collections.Generic.List[string]]$DataLines) if (-not $Type -or $DataLines.Count -eq 0) { return } $json = ($DataLines -join "`n").Trim() if (-not $json -or $json -eq "[DONE]") { return } try { $obj = ConvertFrom-JsonCompat -Json $json } catch { return } switch ($Type) { "response.output_item.done" { Save-ImageGenerationCallResult -ImageCall $obj.item } "response.completed" { $imageCall = @( $obj.response.output | Where-Object { $_.type -eq "image_generation_call" -and $_.result } ) | Select-Object -First 1 Save-ImageGenerationCallResult -ImageCall $imageCall } } } } -Process { $line = [string]$_ if ($line.StartsWith("event:")) { if ($eventType -or $dataLines.Count -gt 0) { Flush-SseEvent -Type $eventType -DataLines $dataLines $dataLines = [System.Collections.Generic.List[string]]::new() } $eventType = $line.Substring(6).Trim() return } if ($line.StartsWith("data:")) { $dataLines.Add($line.Substring(5).TrimStart()) return } if ([string]::IsNullOrWhiteSpace($line)) { Flush-SseEvent -Type $eventType -DataLines $dataLines $eventType = $null $dataLines = [System.Collections.Generic.List[string]]::new() } } -End { Flush-SseEvent -Type $eventType -DataLines $dataLines } } finally { if (Test-Path -LiteralPath $tempBodyFile) { Remove-Item -LiteralPath $tempBodyFile -Force } } 相关资源 如需了解更详细的参数调整可以参考 OpenAI 官方文档 5 个帖子 - 4 位参与者 阅读完整话题
使用Claude code接入cliproxyapi反代的gpt模型使用，在cc switch把所有的能设置的模型全部设置成了gpt-5.4(xhigh)[1m]，结果claude code运行时创建的所有的worker都是opus-4-6模型，全部API ERROR。导致任务完全推进不下去。 目前不知道怎么解决，有碰见过同样问题的佬吗？你们是怎么解决的呢？ 1 个帖子 - 1 位参与者 阅读完整话题
大家是会把 CPA 部署到哪里呀？本机吗还是闲置电脑/服务器？ 前两天在阿里云租了 69/年的轻量云服务器来玩，突然想是不是可以把 CPA 部署上去，问了问 AI，想到国内的服务器转发不了请求。 想看看大家都是怎么部署的/有没有什么建议? 我的设备是一台 MBA（随身）和游戏本（固定在宿舍），不过校园里只敢使用热点访问外网。所以不太能在游戏本部署。阿里云有两个服务器，一个轻量云一个 ECS，都在国内。 其实我的用途主要就是用来方便用 codex（不用每次登出登入），cc-switch 也需要注意额度然后quit 会话再打开。 请各位佬友出出主意。第一次在社区发帖，如果有不符合社区规范的请告知我 QAQ。 PS：我好喜欢社区的这个表情，哈哈。 19 个帖子 - 11 位参与者 阅读完整话题
背景： 昨天偶然在一个群里看到有人犹豫公司内部使用反代的项目选型，刚好自己也想了解为什么L站论坛里有人用 CPA 有人用 sub2api，到底个人和小团队使用哪一个更适合，直觉之外是否有技术指标来辅助做决策。 过程： 1.在 windows11的虚拟机里，用 Antigravity 的 Claude Sonnet 4.6 ，把 CLIProxyAPI 和 sub2api 项目 clone 到本地，并根据项目代码做了一下分析。 2.一共用了三组提示词，先用下面第一组提示词直接生成了 Markdown 版本的分析报告，然后又追加了第二第三组提示词，对分析做了一些补充。 3.第一组提示词： 请比较分析 CLIProxyAPI 与 sub2api 两个项目，从安全性，代码效率，以及其它这两个项目里包含相同的功能可以比较的地方，逐一分析比较，做一个 markdown 格式的专业研究分析报告。请先研究一下如何分析，做个计划 ，然后再严格按照计划去实施。 4.第二组提示词： 请比较单用户使用和100个用户使用的情况下，如果 AI 提供商凭证总数在 1k 级别，两个项目分别在什么配置运行可以覆盖极端较大并发的情况。 5.第三组提示词： 请对这两个项目的用户请求服务器响应速度做个对比。 6.合并提示词： 请把刚才讨论的内容添加到已经完成的对比分析研究报告里，谢谢！ 结论 ：如果个人使用，CPA 较优，小团队使用，sub2api 较优。 附： TL;DR 3 个帖子 - 1 位参与者 阅读完整话题
用 Antigravity 的 Claude Sonnet 4.6 对 CPA 和 sub2api 做了一下分析，看起来个人用 CPA 是较优选。 尝试上传 markdown 文件，文件格式不允许，就先直接贴一下试试，980行。TL;DR # CLIProxyAPI vs Sub2API — 专业技术对比分析报告 > **报告日期** ：2026-04-15 > **分析版本** ：CLIProxyAPI v6（go module: `github.com/router-for-me/CLIProxyAPI/v6`）/ Sub2API latest（go module: `github.com/Wei-Shaw/sub2api`） > **分析范围** ：安全性、代码效率、架构设计、功能重叠对比、容量规划、响应速度 > **报告语言** ：中文 — ## 目录 1. [项目概述与定位]( #1-项目概述与定位 ) 2. [技术架构对比]( #2-技术架构对比 ) 3. [安全性深度分析]( #3-安全性深度分析 ) 4. [代码质量与效率]( #4-代码质量与效率 ) 5. [共有功能逐项对比]( #5-共有功能逐项对比 ) 6. [可扩展性与运维]( #6-可扩展性与运维 ) 7. [综合评分与适用场景建议]( #7-综合评分与适用场景建议 ) 8. [服务器容量规划（CPU / 内存）]( #8-服务器容量规划cpu –内存) 9. [请求响应速度深度对比]( #9-请求响应速度深度对比 ) — ## 1. 项目概述与定位 ### 1.1 设计哲学差异 | 维度 | CLIProxyAPI | Sub2API | |------|-------------|---------| | **核心定位** | 轻量级 OAuth 代理（CLI 工具优先） | 企业级 SaaS AI API 网关分发平台 | | **目标用户** | 个人开发者、小团队、AI 编程工具用户 | API 服务商、商业运营者、多租户环境 | | **商业模式** | 开源免费工具 | 开源 + 可商业化部署（内置支付系统）| | **运行模式** | 本地 / 单节点运行为主 | 云端多节点服务为主 | | **配置复杂度** | 单 YAML 文件，5 分钟上手 | Web 向导 + 数据库，专业运维 | | **生态规模** | 20+ 社区周边项目引用 | 企业级插件，官方 Demo 站点（ demo.sub2api.org ）| ### 1.2 功能边界 ``` CLIProxyAPI 解决的问题： “我有 Gemini/Claude/Codex 的 OAuth 账号，如何让我的 AI 编程工具（Cline/Cursor/Amp）使用？” Sub2API 解决的问题： “我有大量 AI 订阅账号，如何以 SaaS 形式分发给用户、管理配额、收取费用？” ``` 两个项目的重叠区间在于： **API 网关代理层** ------ 都负责将客户端请求转发至上游 AI 服务，并处理多账号调度。但抵达这一核心功能的路径、所承载的业务目标截然不同。 — ## 2. 技术架构对比 ### 2.1 整体架构 ``` CLIProxyAPI（单体轻量架构）： ┌──────────────────────────────────────────────────────┐ │ Client (Cline/Cursor/Amp/API) │ └──────────────────────┬───────────────────────────────┘ │ HTTP/WS ┌──────────────────────▼───────────────────────────────┐ │ Gin HTTP Server + WebSocket Relay │ │ ├── Auth Handler（OAuth Token 管理） │ │ ├── Gateway Handler（请求路由 + 翻译） │ │ └── Management API（本地访问，bcrypt 鉴权） │ ├──────────────────────────────────────────────────────┤ │ 内存存储（Registry + Cache） │ │ 文件系统（~/.config/CLIProxyAPI/auths/） │ └──────────────────────┬───────────────────────────────┘ │ HTTPS + TLS 指纹 Gemini / Claude / Codex / Qwen / iFlow ``` ``` Sub2API（分层 SaaS 架构）： ┌──────────────────────────────────────────────────────┐ │ Client（用户 API Key 调用） │ └──────────────────────┬───────────────────────────────┘ │ HTTP/WS/H2C ┌──────────────────────▼───────────────────────────────┐ │ Gin HTTP Server（Nginx 反向代理 + TLS 终止） │ │ ├── Auth Handler（JWT + TOTP + OAuth + Turnstile） │ │ ├── Gateway Handler（账号调度 + 计费 + 并发控制） │ │ ├── Payment Handler（Stripe/支付宝/微信） │ │ ├── Admin Handler（WebSocket 实时仪表板） │ │ └── WebSocket Admin（QPS 监控） │ ├──────────────────────────────────────────────────────┤ │ PostgreSQL（Ent ORM，主数据层） │ │ Redis（速率限制 + 缓存 + 会话 + 并发控制） │ └──────────────────────┬───────────────────────────────┘ │ HTTPS Gemini / Claude / Codex / Qwen / Antigravity ``` ### 2.2 技术栈详细对比 | 组件 | CLIProxyAPI | Sub2API | 点评 | |------|-------------|---------|------| | **Go 版本** | go 1.26.0 | go 1.26.2 | 相同世代 | | **HTTP 框架** | Gin v1.10.1 | Gin v1.9.1 | CLIProxyAPI 版本更新 | | **数据库** | 无（文件系统） | PostgreSQL 15+ via Ent ORM | 完全不同层次 | | **缓存/队列** | 内存（自研）| Redis 7+ | Sub2API 更强 | | **ORM** | 无 | entgo.io/ent v0.14.5 | Sub2API 有完整 ORM | | **依赖注入** | 无（手动）| Google Wire v0.7.0 | Sub2API 工程化更规范 | | **日志库** | Logrus v1.9.3 | Zap v1.24.0 | Zap 性能更优 | | **JWT** | 无（API Key 校验）| golang-jwt/jwt v5 | Sub2API 有完整 JWT | | **WebSocket** | gorilla/websocket v1.5.3 | coder/websocket + gorilla | Sub2API 双实现 | | **JSON 解析** | gjson/sjson + goccy | gjson/sjson + goccy | 相同核心工具 | | **TLS 指纹** | refraction-networking/utls | refraction-networking/utls | 相同 | | **配置管理** | gopkg.in/yaml.v3 | viper（多格式） | Sub2API 更灵活 | | **前端** | 无（TUI via Bubbletea）| Vue 3.4 + Vite 5 + TailwindCSS | 完全不同 | | **TOTP/2FA** | 无 | pquerna/otp v1.5.0 | Sub2API 独有 | | **支付集成** | 无 | Stripe + 支付宝 + 微信支付 | Sub2API 独有 | | **Cron 调度** | 自研 watcher | robfig/cron v3 | Sub2API 标准化 | | **监控** | 内存统计 | gopsutil + OpenTelemetry | Sub2API 更完整 | ### 2.3 依赖复杂度分析 ``` CLIProxyAPI go.mod 直接依赖：约 31 项 Sub2API go.mod 直接依赖：约 50 项（+62%） Sub2API 间接依赖总数大幅领先，主要来源： - AWS SDK（多层传递依赖，~15 个包） - Testcontainers（Docker 集成测试） - Stripe SDK - OpenTelemetry 完整套件 - gRPC 生态（Protobuf、grpc-gateway） ``` **评分** ：CLIProxyAPI 依赖更精简，供应链攻击面更小；Sub2API 依赖复杂度更高，但每个依赖都有明确的业务目的。 — ## 3. 安全性深度分析 ### 3.1 认证机制对比 #### CLIProxyAPI 认证体系 ``` 外部访问认证： ├── API Keys（YAML 配置静态列表，支持多 Key） │ └── 明文存储于 config.yaml（ 潜在风险） ├── WebSocket 认证（ws-auth: true 时启用） └── Remote Management Key（bcrypt 哈希存储 ） OAuth Token 管理（上游认证）： ├── Gemini CLI OAuth → 文件系统（auth-dir） ├── Claude Code OAuth → 文件系统 ├── OpenAI Codex OAuth → 文件系统 ├── Qwen Code OAuth → 文件系统 └── iFlow OAuth → 文件系统 ``` **安全亮点** ： - `remote-management.secret-key` 在首次启动时****自动 bcrypt 哈希化****并写回 config.yaml（自动密钥保护 ） - TLS 指纹伪装（`refraction-networking/utls`）降低上游识别风险 - 管理端点默认****仅限 localhost 访问****（`allow-remote: false`） **安全隐患** ： - 客户端 API Key 以****明文****存储于 YAML 文件（无加密 ） - OAuth Token 文件存于文件系统，权限依赖 OS 级别保护 - 无用户系统，无法细粒度控制访问权限 #### Sub2API 认证体系 ``` 用户认证： ├── Email/Password + bcrypt 哈希 ├── TOTP（两步验证，pquerna/otp） ├── OAuth 登录 │ ├── Linux.do OAuth（社区账号） │ └── OIDC 标准协议（任意 OIDC Provider） ├── Cloudflare Turnstile 人机验证（注册/登录防爆破） └── JWT Token 鉴权（golang-jwt/jwt v5） API Key 管理： ├── 用户自助生成（`sk-` 前缀格式） ├── 数据库存储（PostgreSQL，有索引） └── API Key 缓存（Redis，减少 DB 查询） 速率限制（auth 端点）： ├── /auth/register：Redis Lua 原子计数 + fail-close 模式 ├── /auth/login：同上 ├── /auth/login/2fa：同上 └── /auth/send-verify-code：同上 ``` **安全亮点** ： - TOTP 密钥使用独立 `TOTP_ENCRYPTION_KEY` 加密存储 - 注册/登录端点有服务端兜底限流 + Redis 故障时 **fail-close** （故障即拒绝，不开放） - Turnstile 在 Release 模式强制启用 - JWT 密钥与 TOTP 密钥独立（`JWT_SECRET` ≠ `TOTP_ENCRYPTION_KEY`） - CORS 白名单精确配置 ### 3.2 速率限制实现对比 #### CLIProxyAPI — 速率限制 CLIProxyAPI **无标准 IP 级速率限制中间件** 。限流策略完全依赖： - 账号级配额冷却（Quota Cooling，内存实现） - 上游 429 错误的重试/回退逻辑 - 无 Redis，无分布式限流 ```go // CLIProxyAPI 的"限流"本质是账号调度层的冷却逻辑 // 没有针对客户端请求的 IP 级速率限制 ``` #### Sub2API — Redis Lua 原子速率限制 ```go // sub2api/backend/internal/middleware/rate_limiter.go var rateLimitScript = redis.NewScript(` local current = redis.call(‘INCR’, KEYS[1]) – 原子递增 local ttl = redis.call(‘PTTL’, KEYS[1]) local repaired = 0 if current == 1 then redis.call(‘PEXPIRE’, KEYS[1], ARGV[1]) – 首次设置 TTL elseif ttl == -1 then redis.call(‘PEXPIRE’, KEYS[1], ARGV[1]) – 修复孤儿键 repaired = 1 end return {current, repaired} `) ``` **技术亮点** ： - Lua 脚本在 Redis 服务端****原子执行****，无竞态条件 - 支持 `fail-open`（Redis 故障时放行，保障服务）和 `fail-close`（Redis 故障时拒绝，保障安全）两种策略 - 自动修复 TTL 为 `-1` 的孤儿键 - 速率限制 key 格式 `rate_limit:{type}:{ip}`，支持按 IP + 类型组合 **对比结论** ：Sub2API 速率限制实现更专业、更安全，具备分布式能力；CLIProxyAPI 在这一维度基本缺失。 ### 3.3 网络层安全对比 | 安全特性 | CLIProxyAPI | Sub2API | |---------|-------------|---------| | **HTTPS/TLS** | 原生 TLS 服务器（cert + key 配置）| Nginx 反向代理终止 TLS | | **TLS 指纹伪装** | utls（模拟 Chrome/Firefox 指纹）| utls（相同库）| | **URL 白名单** | 无 | `security.url_allowlist`，默认拒绝 HTTP URL | | **响应头过滤** | 无 | `security.response_headers`，可配置响应头白名单 | | **私有 IP 防护** | 无 | `allow_private_hosts` 开关，默认拒绝私有 IP | | **SSRF 防护** | 无 | URL 白名单 + 私有 IP 阻断 | | **CSP 头** | 无 | `security.csp` 可配置 | | **上游响应限制** | 无 | `gateway.upstream_response_read_max_bytes`（默认 8MB）| | **pprof 防护** | 独立端口，需配置才启用 | 无内置 pprof | **重要发现** ：Sub2API 明确提示并防范了 **SSRF（服务端请求伪造）攻击** ，这在 CLIProxyAPI 中完全缺失。当 CLIProxyAPI 接受用户配置的 `base-url` 时，理论上存在 SSRF 风险（但通过 localhost-only 管理端口缓解）。 ### 3.4 机密管理安全评分 | 评估项 | CLIProxyAPI | Sub2API | 权重 | |--------|-------------|---------|------| | 管理密钥保护 | bcrypt 自动哈希 | JWT Secret + 独立 TOTP Key | 高 | | 客户端 API Key 保护 | YAML 明文 | DB 存储（可加密） | 高 | | OAuth Token 保护 | 文件系统 | DB 加密存储 | 中 | | 2FA/TOTP | 无 | 完整实现 | 高 | | 密钥轮换机制 | 手动 | 支持 （部分）| 中 | | 审计日志 | 无 | ops 系统日志 | 中 | **安全性综合得分** ：CLIProxyAPI （3/5）| Sub2API ½（4.5/5） — ## 4. 代码质量与效率 ### 4.1 代码规模与模块化 ``` CLIProxyAPI internal/ 模块数：23 个子目录 ├── access, api, auth, browser, buildinfo, cache ├── cmd, config, constant, interfaces, logging ├── managementasset, misc, registry, runtime ├── store, thinking, translator, tui, usage ├── util, watcher, wsrelay sub2api/backend/internal/ 模块数：15 个子目录 ├── config, domain, handler, integration ├── middleware, model, payment, pkg ├── repository, server, service, setup ├── testutil, util, web （注：sub2api service/ 目录内有 450+ 个 Go 文件， CLIProxyAPI 模块分布更碎，service/ 相当于其 internal/ 顶层） ``` **模块化设计评价** ： - **CLIProxyAPI** ：模块数量多但每个模块职责清晰（如 `auth/gemini`、`auth/claude` 独立包），遵循单一职责原则，但 `internal/api` 作为入口层可能存在职责混杂 - **Sub2API** ：标准的分层架构（handler → service → repository），Wire 依赖注入保证了层间解耦，代码可测试性更强 ### 4.2 测试覆盖对比 #### CLIProxyAPI 测试特点 ``` 测试文件分布（service/ 层）： ├── 单元测试：config/、auth/ 各模块 ├── 集成测试：OAuth 流程 ├── Benchmark：JSON 优化、账号调度 └── 快照测试：Codex CLI 行为 ``` ``` 典型测试示例（gateway_helper_hotpath_test.go - 11.7KB）： 测试热路径优化（fast-path / hot-path 分支） ``` #### Sub2API 测试特点 ``` service/ 层测试文件（共 455 个文件，其中大量是 _test.go）： ├── 单元测试：account_service_test.go, api_key_service_test.go ├── 集成测试（Testcontainers）：rate_limiter_integration_test.go（Docker 链接真实 Redis） ├── 账号调度测试：openai_account_scheduler_test.go（32.7KB） ├── WebSocket 测试：openai_ws_forwarder_xxx_test.go（50-93KB，极其详细） ├── 支付测试：billing_service_test.go（31KB） ├── 安全测试：auth_service_register_test.go, turnstile_register_test.go └── 并发测试：concurrency_service_test.go ``` | 测试维度 | CLIProxyAPI | Sub2API | |---------|-------------|---------| | 单元测试密度 | 中等 | 极高（每核心服务均有完整测试）| | 集成测试 | 有（无 Docker）| Testcontainers（真实 Redis/PG）| | Benchmark | 有 | 有（JSON 优化、WS 热路径）| | 并发安全测试 | 有 | 更系统化 | | 支付流程测试 | N/A | 完整支付生命周期测试 | **结论** ：Sub2API 测试更系统、覆盖更广，使用 Testcontainers 接近生产环境测试；CLIProxyAPI 测试质量在轻量工具中属中等偏上水平。 ### 4.3 并发模型对比 #### CLIProxyAPI 并发设计 ```go // 并发控制手段： // 1. goroutine + channel（标准 Go 模式） // 2. sync.Map 用于 token 缓存 // 3. 内存 Registry 保护 OAuth token 状态 // 4. 无外部并发协调（单节点） // 5. ssreader buffer pool（sse_scanner_buffer_pool.go） ``` #### Sub2API 并发设计 ```go // 多层并发控制： // 1. Worker Pool（alitto/pond v2）------ 用量记录异步化 // 2. Redis 原子操作（Lua 脚本）------ 分布式并发安全 // 3. 用户级 + 账号级并发限制（concurrency_service.go） // 4. 时间轮（timing_wheel_service.go）------ 延迟任务调度 // 5. singleflight（billing_cache_service_singleflight_test.go）------ 防缓存击穿 // 6. 数据库 Advisory Lock（ops_advisory_lock.go）------ 分布式锁 // 7. PostgreSQL LISTEN/NOTIFY（WebSocket 推送） ``` **关键差异** ：Sub2API 通过 Redis + DB 实现的****分布式并发控制****，可在多节点部署时正确工作，CLIProxyAPI 仅限单节点内存级并发控制。 ### 4.4 日志系统对比 | 维度 | CLIProxyAPI（Logrus）| Sub2API（Zap）| |------|---------------------|----------------| | **性能** | ~基线 | 比 Logrus 快 4-10 倍（零分配路径）| | **结构化日志** | `log.WithFields` | `zap.Field` | | **日志轮转** | lumberjack | lumberjack | | **错误日志分离** | `ErrorLogsMaxFiles` | 运维日志 + 系统日志分离 | | **日志级别** | Debug/Info/Warn/Error | Debug/Info/Warn/Error/Fatal | | **性能影响** | 中等 | 极低（结构体复用）| ### 4.5 错误处理模式 **CLIProxyAPI** ： - 错误向上透传（`fmt.Errorf(“…: %w”, err)`），保留错误链 - 操作错误分类（`ops_errors.go` 中枚举错误类型） - 错误回退（failover）逻辑完善（`failover_loop.go`） **Sub2API** ： - 统一错误响应格式（Gin 中间件统一处理） - 数据库错误与业务错误分离 - 支付失败使用 circuit breaker 模式（`billing.circuit_breaker`） - 上游响应错误有独立日志表（`ops_error_logger.go`，35KB） ### 4.6 JSON 处理效率 两个项目均使用相同的高性能 JSON 工具链： - `github.com/tidwall/gjson`：只读 JSON 解析，零分配 - `github.com/tidwall/sjson`：写入 JSON 字段 - `github.com/goccy/go-json`：drop-in encoding/json 加速替换 这一层面两项目技术选型一致，性能相当。 — ## 5. 共有功能逐项对比 ### 5.1 多账号负载均衡 #### CLIProxyAPI ```yaml # 配置示例 routing: strategy: “round-robin” # 或 “fill-first” gemini-api-key: api-key: “AIza…” priority: 10 api-key: “AIzb…” priority: 5 ``` - 支持 `round-robin` 和 `fill-first` 两种策略 - 支持 `priority` 权重（高优先级优先被选中） - 支持 `prefix` 模型命名空间隔离 - 冷却机制：账号触发 429/配额超限后进入冷却期，自动跳过 - 跨账号会话隔离（`generate_session_hash_test.go` — 36KB，非常详细） #### Sub2API ```yaml # 数据库动态管理，无需重启 # 支持： # - 智能账号选择（基于负载因子） # - 粘性会话（sticky session，session_id 绑定账号） # - 并发限制（账号级 + 用户级） # - 账号健康度评分 ``` - 粘性会话（通过 `session_id` 请求头，Nginx 需 `underscores_in_headers on`） - 基于账号负载因子的智能选择（非简单轮询） - 实时账号可用性监控（`ops_account_availability.go`） - 支持账号分组隔离（`gateway_group_isolation_test.go`） **胜者** ：Sub2API，功能更丰富；CLIProxyAPI 在轻量场景下的 round-robin 已足够。 ### 5.2 OAuth Token 管理 | 特性 | CLIProxyAPI | Sub2API | |------|-------------|---------| | Gemini OAuth | | | | Claude OAuth | | | | OpenAI Codex OAuth | | | | Qwen Code OAuth | | | | iFlow OAuth | | | | Antigravity OAuth | | | | **Token 自动刷新** | （后台 goroutine）| （含失效检测）| | **Token 缓存** | 内存（Map）| Redis（分布式）| | **Token 加密** | （文件系统明文）| （DB 加密字段）| | 刷新策略配置 | `refresh_policy.go` | `token_refresh_service.go` | | 刷新失败回退 | | | | **多账号 Token 轮换** | | （更精细）| ### 5.3 流式响应（SSE / Stream） 两个项目均支持 SSE 流式响应，实现思路一致： - 设置 `Content-Type: text/event-stream` - 逐块 flush 响应体 - 支持流式 failover（流开始后切换账号） **CLIProxyAPI 特有** ： - `sse_scanner_buffer_pool.go` ------ Buffer Pool 复用，减少 GC 压力 - 流式响应中间件截获测试（`gateway_handler_intercept_test.go`） **Sub2API 特有** ： - SSE Buffer Pool（`sse_scanner_buffer_pool.go` 同样有） - 流式计费（token 实时统计） ### 5.4 WebSocket 代理 #### CLIProxyAPI WebSocket 实现 ``` wsrelay/ 模块： ├── 基础 WebSocket 中继 ├── 认证可选（ws-auth 配置项） openai_ws_forwarder.go（134KB！）： ├── Codex Realtime API WebSocket 全双工代理 ├── 账号粘性（ws_account_sticky） ├── 协议解析（ws_protocol_resolver） ├── 连接池（ws_pool）------ 复用 WebSocket 连接降低延迟 ├── Fallover 支持 └── 速率限制信号（ratelimit_signal） ``` **这是 CLIProxyAPI 技术含量最高的模块** ，单文件 134KB 足以说明其复杂度。包含完整的连接池、会话隔离、协议协商逻辑。 #### Sub2API WebSocket 实现 ``` handler/ 层： ├── gateway_handler.go（66KB）------ 包含 WebSocket 代理逻辑 └── WebSocket 实时 Admin QPS 推送 service/ 层： ├── openai_ws_forwarder.go（134KB） 极其相似！ ├── openai_ws_pool.go（40KB） └── openai_ws_state_store.go（12KB） ``` > **关键发现** ：两个项目的 `openai_ws_forwarder.go` 均为约 134KB，极其相似！高度怀疑存在代码共享或相互参考的情况，或来源于共同的上游实现。 ### 5.5 模型别名与映射 #### CLIProxyAPI ```yaml # 全局 OAuth 模型别名 oauth-model-alias: gemini: - name: "gemini-3-pro" alias: "gemini-3" fork: true # 同时保留原始模型名 # 每个 API Key 独立别名 gemini-api-key: api-key: “AIza…” models: name: “gemini-2.5-pro” alias: “gpt-4o” # 伪装成 OpenAI 模型名！ ``` - 支持全局别名 + per-credential 别名 - `fork: true` 允许同时暴露原始名和别名 - Amp CLI 专属模型映射（`AmpModelMapping`，支持正则） - 模型前缀命名空间（`prefix: “teamA/”`） #### Sub2API - 数据库动态配置模型信息（Ent ORM 管理） - 通过 Admin Web 界面在线修改 - 无需重启 **胜者** ：功能接近，CLIProxyAPI 的配置更灵活多样，Sub2API 更易运维管理。 ### 5.6 管理 API #### CLIProxyAPI Management API ``` 访问控制： ├── 默认仅限 localhost（allow-remote: false） ├── bcrypt 哈希密钥认证 └── 可选开放远程访问（需显式配置） 功能： ├── 账号状态查看 ├── Token 刷新触发 ├── 配置热重载（watcher） └── 管理面板（自动从 GitHub 下载最新版） ``` #### Sub2API Admin API ``` 访问控制： ├── JWT Token 鉴权（管理员角色） ├── WebSocket 实时 QPS 数据推送 └── Turnstile 人机验证 功能： ├── 完整用户管理（CRUD） ├── API Key 管理 ├── 账号管理（上游账号增删改） ├── 计费与余额管理 ├── 支付订单管理 ├── 公告系统 ├── 备份/恢复（backup_service.go，32KB） ├── 系统操作锁（防止并发管理操作） ├── 在线升级 └── 数据管理（gRPC datamanagementd） ``` **胜者** ：Sub2API，管理功能远超 CLIProxyAPI。 ### 5.7 Docker 部署 | 特性 | CLIProxyAPI | Sub2API | |------|-------------|---------| | Dockerfile | | | | docker-compose | （单服务）| （含 PostgreSQL + Redis）| | 一键安装脚本 | | `install.sh`（systemd 服务）| | 在线升级 | | （Web 界面 + Docker pull）| | ARM64 支持 | （goreleaser 多平台）| | | 数据迁移 | 简单（单文件）| （本地目录版，tar 打包）| | GoReleaser | （含 .goreleaser.yml）| （含 .goreleaser.yaml）| — ## 6. 可扩展性与运维 ### 6.1 水平扩展能力 **CLIProxyAPI** ： - **不支持水平扩展** （内存状态 + 文件系统 Token 无法共享） - 单节点最大性能取决于单台服务器资源 - 适合：个人/小团队 **Sub2API** ： - **设计上支持水平扩展** - Redis 作为共享状态（速率限制、并发控制、缓存） - PostgreSQL 作为持久化中心 - 无状态 HTTP 层（API 服务器可多实例） - gRPC `datamanagementd` 解耦数据管理 - 需解决的问题：WebSocket 连接亲和性（session 粘性需 Nginx upstream hash） ### 6.2 可观察性对比 | 维度 | CLIProxyAPI | Sub2API | |------|-------------|---------| | 应用日志 | Logrus + 文件轮转 | Zap + 文件轮转 | | 结构化日志 | | | | 实时 QPS | | （WebSocket Dashboard）| | 请求详情记录 | （可选）| （ops_request_details）| | 错误统计 | （内存）| （DB + 实时告警）| | 指标导出 | | （ops_metrics_collector，类 Prometheus）| | OpenTelemetry | | （间接依赖）| | pprof | （独立端口）| （无内置）| | 健康检查 | `/health` | `/health`（h2c 支持验证）| | 告警系统 | | （ops_alert_evaluator_service，25KB）| | 定时统计报告 | | （ops_scheduled_report_service，18KB）| ### 6.3 移动端支持 **CLIProxyAPI** ：无官方移动端，社区有基于其 API 的桌面 GUI 应用（如 Quotio、CodMate） **Sub2API** ：官方生态项目 [`sub2api-mobile`]( GitHub - ckken/sub2api-mobile · GitHub )（Expo + React Native，跨平台 iOS/Android/Web），支持用户管理、账号管理、监控看板 — ## 7. 综合评分与适用场景建议 ### 7.1 维度评分表 | 评估维度 | CLIProxyAPI | Sub2API | 说明 | |---------|:-----------:|:-------:|------| | **安全性** | | ½ | Sub2API 有完整的多层安全体系 | | **代码质量** | | ½ | 两者均高，Sub2API 测试更系统 | | **学习成本** | | | CLIProxyAPI 简单易上手 | | **功能丰富度** | | | Sub2API 功能远超 | | **性能（单节点）** | | | CLIProxyAPI 无 DB 开销更快 | | **可扩展性** | | | Sub2API 天生分布式 | | **运维友好度** | | | Sub2API Web 管理 + 一键升级 | | **依赖精简度** | | | CLIProxyAPI 依赖少、供应链更小 | | **多租户支持** | | | Sub2API 天生多租户 | | **商业化就绪** | | | Sub2API 内置支付 + 计费 | ### 7.2 适用场景推荐 ``` 选择 CLIProxyAPI 当你： ├── 个人开发者，需要快速给 AI 编程工具（Claude Code/Cursor/Cline）复用 OAuth 账号 ├── 小团队内部使用，不需要多租户和计费 ├── 对简单性和低资源占用有要求（单二进制，无数据库） ├── 需要最大程度的 OAuth 提供商覆盖（Gemini/Claude/Codex/Qwen/iFlow/Antigravity） └── 希望嵌入 Go SDK 到自己项目中（提供 sdk/ 包） 选择 Sub2API 当你： ├── 打算运营一个 AI API 中转服务（商业或社区） ├── 需要向用户分发 API Key 并管理用量 ├── 需要计费和支付系统（Stripe/支付宝/微信） ├── 需要多租户、权限控制、管理后台 ├── 团队规模较大，需要系统化运维和可观察性 └── 有水平扩展需求（多节点部署） ``` ### 7.3 关键技术差异总结 ``` 最重要的三点差异： 1. 存储架构：无数据库（CLIProxyAPI）vs PostgreSQL + Redis（Sub2API） → 决定了两者能承载的业务复杂度上限 2. 用户模型：单密钥访问（CLIProxyAPI）vs 多用户体系（Sub2API） → 决定了能否商业运营 3. 速率限制：无 IP 级限制（CLIProxyAPI）vs Redis Lua 原子分布式限制（Sub2API） → 在面向公网时，这是重要的安全边界差异 ``` ### 7.4 代码复用发现 > **值得注意** ：两个项目均存在 `openai_ws_forwarder.go`（各约 134KB）和 `sse_scanner_buffer_pool.go` 等高度相似的文件，以及相同的 JSON 工具链选型（gjson/sjson/goccy）和 TLS 指纹库（utls）。这表明两个项目可能有共同的技术基因，部分核心实现可能来自同一作者群体或相互参考。 — ## 附录 ### A. 关键文件规模对照 | 文件 | CLIProxyAPI | Sub2API | 说明 | |------|-------------|---------|------| | 最大服务文件 | `gateway_service.go` (313KB) | `antigravity_gateway_service.go` (165KB) | CLIProxyAPI 核心更集中 | | WebSocket 转发 | `openai_ws_forwarder.go` (134KB) | `openai_ws_forwarder.go` (134KB) | **完全相同大小** | | 账号服务 | — | `account.go` (54KB) | Sub2API 独有 | | 配置管理 | `config.go` (69KB) | `setting_service.go` (87KB) | 各有侧重 | | 认证服务 | — | `auth_service.go` (45KB) | Sub2API 独有 | | ORM Schema | 无 | `ent/schema/` 整目录 | Sub2API 独有 | ### B. 共同依赖 | 依赖包 | 版本（CPA）| 版本（S2A）| 用途 | |--------|-----------|-----------|------| | GitHub - gin-gonic/gin: Gin is a high-performance HTTP web framework written in Go. It provides a Martini-like API but with significantly better performance—up to 40 times faster—thanks to httprouter. Gin is designed for building REST APIs, web applications, and microservices. · GitHub | v1.10.1 | v1.9.1 | HTTP 框架 | | GitHub - google/uuid: Go package for UUIDs based on RFC 4122 and DCE 1.1: Authentication and Security Services. · GitHub | v1.6.0 | v1.6.0 | UUID 生成 | | GitHub - tidwall/gjson: Get JSON values quickly - JSON parser for Go · GitHub | v1.18.0 | v1.18.0 | JSON 读取 | | GitHub - tidwall/sjson: Set JSON values very quickly in Go · GitHub | v1.2.5 | v1.2.5 | JSON 写入 | | GitHub - gorilla/websocket: Package gorilla/websocket is a fast, well-tested and widely used WebSocket implementation for Go. · GitHub | v1.5.3 | v1.5.3 | WebSocket | | GitHub - refraction-networking/utls: Fork of the Go standard TLS library, providing low-level access to the ClientHello for mimicry purposes. · GitHub | v1.8.2 | v1.8.2 | TLS 指纹 | | The Go Programming Language | v0.45.0 | v0.48.0 | 密码学 | | gopkg.in/natefinch/lumberjack | v2.2.1 | v2.2.1 | 日志轮转 | | gopkg.in/yaml.v3 | v3.0.1 | v3.0.1 | YAML 解析 | — ## 8. 服务器容量规划（CPU / 内存） > **场景设定** ：凭证总数 1000 个上游 AI 账号；单用户（5 流并发）vs 100 用户极端并发（峰值 200 流） ### 8.1 内存计算基准 ``` Go goroutine 内存工作集（实测参考）： ├── 初始栈：2KB（Go 1.21+） ├── 普通代理 handler 工作期：~32-64KB ├── WebSocket / SSE 流 handler：~64-128KB（含 Scanner buffer） └── 计费/DB 操作额外（仅 Sub2API）：+50KB ``` ### 8.2 CLIProxyAPI 容量模型 ``` CLIProxyAPI 内存组成（1000 凭证基础） ───────────────────────────────────────── Go 二进制 + runtime 基础 ~25 MB 1000 OAuth Token（内存缓存） ~3 MB (2.5KB/token x 1000) 账号注册表（调度状态+冷却） ~1 MB (500B/账号 x 1000 x 2) HTTP Transport 连接池（上游） ~5 MB (100空闲连接 x 50KB) SSE buffer pool（复用） ~4 MB (64个64KB buffer) Logrus 日志 buffer ~2 MB GC headroom (30%) ~12 MB ───────────────────────────────────────── 空载基础内存合计 ~52 MB 每并发流额外内存： goroutine 栈（SSE 流） ~80 KB 上游 TLS 连接状态 ~40 KB 请求/响应 buffer ~8 KB 每并发流约 ~128 KB ``` | 场景 | 并发流估计 | 内存计算 | **推荐配置** | |------|-----------|----------|-------------| | **单用户** | 5 并发流 | 52 + 5×0.13 ≈ 53 MB | **1 vCPU / 256 MB** | | **100用户极端** | 200 并发流 | 52 + 200×0.13 ≈ 78 MB | **2 vCPU / 512 MB** | | **100用户+峰值余量** | 300 并发流 | 52 + 300×0.13 ≈ 91 MB | **2 vCPU / 1 GB** 推荐 | > **CPU 说明** ：CLIProxyAPI 是 IO 密集型，99% 时间等待上游 AI 响应。200 并发流下实际 CPU 占用率 < 30%，2 核完全够用。 ### 8.3 Sub2API 容量模型（三层架构分层计算） **层 1：Go 应用服务** ``` Sub2API Go 服务内存组成（1000 凭证基础） ───────────────────────────────────────── Go 二进制 + runtime ~38 MB Usage Worker Pool（默认128 goroutine）~6 MB (来源：usage_record_worker_pool.go) Ristretto 内存缓存（API Key等） ~32 MB PGX 数据库连接池（20连接） ~2 MB Redis 连接池（20连接） ~1 MB 调度器快照缓存（1000账号） ~5 MB (scheduler_snapshot_service) 计费缓存（billing_cache_service） ~8 MB Zap 日志 buffer ~2 MB GC headroom (30%) ~28 MB ───────────────────────────────────────── 空载基础内存合计 ~122 MB 每并发流额外内存（含计费管道）： goroutine 栈（SSE 流） ~80 KB JWT 解析 + Redis 并发槽操作 ~20 KB 计费中间计算（token计数） ~40 KB 上游 TLS 连接状态 ~40 KB 请求/响应 buffer ~8 KB 每并发流约 ~188 KB ≈ 200 KB ``` **层 2：PostgreSQL（1000 账号负载）** ``` shared_buffers（账号+API Key热表） 256 MB（推荐配置值） work_mem x 20连接（峰值） 320 MB WAL buffer + 维护内存 64 MB PG 进程基础 30 MB ───────────────────────────────────────── PostgreSQL 推荐内存 512 MB ~ 1 GB ``` **层 3：Redis（1000凭证 + 100用户）** ``` 并发槽（ZSET, 1000账号x5槽） ~2 MB (AcquireAccountSlot) 用户并发槽（100用户x队列） ~1 MB 速率限制计数器（100用户x10端点） ~0.5 MB API Key 认证缓存 ~1 MB Token/JWT 黑名单 ~0.5 MB ───────────────────────────────────────── Redis 推荐内存 128 MB ~ 256 MB ``` **Sub2API 配置推荐汇总（单机部署）** | 场景 | Go服务 | PostgreSQL | Redis | OS | **单机总配置** | |------|--------|-----------|-------|-----|---------------| | **单用户** | 200MB | 512MB | 128MB | 256MB | **2 vCPU / 2 GB** | | **100用户极端** | ~202MB | 1GB | 256MB | 512MB | **4 vCPU / 4 GB** | | **极端+峰值余量** | 同上 | 同上 | 同上 | 同上 | **4 vCPU / 8 GB** 推荐 | **生产级分离部署方案** ``` ┌───────────────┬────────┬─────────┬───────────────────────┐ │ 节点 │ vCPU │ 内存 │ 职责 │ ├───────────────┼────────┼─────────┼───────────────────────┤ │ Go 应用 x1 │ 2 │ 1 GB │ API网关 + 业务逻辑 │ │ PostgreSQL │ 2 │ 2 GB │ 主数据库（1000账号） │ │ Redis │ 1 │ 512 MB │ 缓存+限流+并发锁 │ ├───────────────┼────────┼─────────┼───────────────────────┤ │ 合计 │ 5 │ 3.5 GB │ │ └───────────────┴────────┴─────────┴───────────────────────┘ ``` ### 8.4 两项目配置终极对比 ``` 单用户 100用户极端 项目 vCPU / 内存 / 参考月费 vCPU / 内存 / 参考月费 ───────────────────────────────────────────────────────────────── CLIProxyAPI 1核 / 256MB / ~$3 2核 / 1GB / ~$10 Sub2API（单机） 2核 / 2GB / ~$15 4核 / 8GB / ~$40 Sub2API（分离） 5核 / 3.5GB / ~$45 6核 / 6GB / ~$60 ───────────────────────────────────────────────────────────────── （月费参考 AWS/阿里云按需价格，仅供参考） ``` > **费用差距解析** ：Sub2API 每个请求需额外执行 3 次 Redis RTT（速率限制 + 获取并发槽 + 释放槽），以及维持 128 个常驻 Worker goroutine（`usage_record_worker_pool.go` 默认配置），这是以资源成本换取限流、计费、并发控制能力的合理代价。 — ## 9. 请求响应速度深度对比 ### 9.1 核心公式 ``` 用户总感知延迟 = 【网关处理耗时】 + 【上游 AI 模型响应延迟】 可以优化的部分 不可控制（500ms\~5000ms） ``` ### 9.2 CLIProxyAPI 请求处理管道 ``` 用户请求 │ ▼ [1] Gin 路由匹配 ~0.01ms ▼ [2] API Key 校验（内存 map 查找） ~0.001ms ▼ [3] 账号调度（round-robin，内存 Registry） ~0.01ms ▼ [4] 请求 JSON 转换（gjson/sjson） ~0.2ms ▼ [5] 上游连接 │ keep-alive 复用： ~0ms │ 新建 TLS 握手： ~50-100ms ▼ [6] 等待上游首 token（不计入网关耗时） ▼ [7] 流式回传响应 ~0.1ms/chunk 网关自身总开销（连接复用时）: ~0.3ms 网关自身总开销（新建连接时）: ~50-100ms ``` ### 9.3 Sub2API 请求处理管道 ``` 用户请求 │ ▼ [1] Nginx 反向代理（可选） ~0.5ms ▼ [2] Gin 路由 + 中间件链 ~0.02ms ▼ [3] JWT Token 验证（HMAC-SHA256） ~0.15ms ▼ [4] API Key 查找 │ Redis 缓存命中（热路径）： ~0.5ms │ Redis miss → PostgreSQL： ~2~5ms ▼ [5] Redis 速率限制（Lua 脚本原子执行） ~0.5~1ms ▼ [6] Redis 并发槽获取（ZADD） ~0.5~1ms ▼ [7] 账号调度（Snapshot缓存+Redis负载查询） ~0.5~2ms ▼ [8] 请求 JSON 转换（gjson/sjson） ~0.2ms ▼ [9] 上游连接 │ keep-alive 复用： ~0ms │ 新建 TLS 握手： ~50-100ms ▼ [10] 等待上游首 token（不计入网关耗时） ▼ [11] 流式回传响应 ~0.1ms/chunk ▼ [12] 【异步，不阻塞响应路径】 Release 并发槽（Redis） \~1ms（后台） 提交计费任务到 Worker Pool \~0.01ms（enqueue即返回） 网关自身总开销（Redis 本地，连接复用）: ~2.4ms 网关自身总开销（Redis 远程，连接复用）: ~6~12ms ``` ### 9.4 各步骤耗时对比 | 处理步骤 | CLIProxyAPI | Sub2API | 差距 | |---------|-------------|---------|------| | 认证校验 | ~0.001ms（内存）| ~0.15ms（JWT 计算）| x150 | | 限流检查 | 无 | ~0.7ms（Redis Lua）| — | | 并发控制 | 无 | ~0.7ms（Redis ZADD）| — | | 账号调度 | ~0.01ms（内存）| ~1ms（内存+Redis）| x100 | | JSON转换 | ~0.2ms | ~0.2ms | 相同 | | 计费结算 | 无 | ~0ms（异步队列，不阻塞）| — | | **网关总开销** | **~0.3ms** | **~2.4~12ms** | **x8~40** | ### 9.5 实际 TTFT 感知影响 | 上游AI响应时间 | CLIProxyAPI 总延迟 | Sub2API 总延迟 | 差距 | 人类感知 | |--------------|-------------------|--------------|------|----------| | 100ms（快速响应）| 100.3ms | 105ms | 4.7ms | 高频调用可感知 | | 500ms（轻量推理）| 500.3ms | 505ms | 4.7ms | 不明显 | | 800ms（典型对话）| 800.3ms | 805ms | 4.7ms | 无感知 | | 3000ms（复杂生成）| 3000.3ms | 3005ms | 4.7ms | 完全无感 | > 对于 AI 代理场景， **网关延迟差异在绝大多数情况下对用户体验无影响** ，差异主要体现在高频 API 批量调用的累积效应上。 ### 9.6 吞吐量（RPS）对比 ``` 单核 CPU 理想极限 RPS（不计上游等待时间）： CLIProxyAPI: 理论上限：1s / 0.3ms = ~3300 RPS 实际（goroutine 调度开销）：约 1000~2000 RPS Sub2API（本地 Redis）: 理论上限：1s / 2.4ms = ~416 RPS 实际（Redis 连接池限制）：约 200~400 RPS Sub2API（远程 Redis，RTT=1ms/次）: 理论上限：1s / 8ms = ~125 RPS 实际：约 80~150 RPS ``` ### 9.7 P99 尾延迟稳定性 | 场景 | CLIProxyAPI P99 | Sub2API P99 | 原因 | |------|----------------|-------------|------| | 空闲系统 | ~1ms | ~5ms | Sub2API Redis RTT | | 100并发流量 | ~2ms | ~15ms | Redis 队列积压 | | Redis AOF/RDB 触发 | 影响极小 | +50~200ms 尖峰 | 强依赖 Redis | | 上游账号全忙 | 快速失败/轮换 | 排队等待（最多+20槽等待）| Sub2API 体验更好 | > **Sub2API 的 Redis 尾延迟风险** ：Redis 触发 AOF 刷盘或 RDB 持久化快照时，延迟短暂升至 20-100ms，直接影响所有并发请求的 P99。CLIProxyAPI 的内存操作无此风险。 ### 9.8 速度综合结论 ``` 在 AI 代理场景下，速度差异几乎不影响用户体验 因为上游 AI 响应延迟（500ms~5s）远超网关开销 CLIProxyAPI 速度优势体现在： 极低 P50 延迟（~0.3ms 网关开销） 高 RPS 吞吐（无 Redis 瓶颈，~1000+ RPS/核） 零尾延迟抖动（无外部 I/O 依赖） Sub2API 多付的 2~12ms 换来了： 用户级精细限流与并发控制 Token 级精确计费（异步不阻塞响应路径） 排队机制（20个等待槽，比直接拒绝更友好） 选择建议： 极致速度 + 高频调用 → CLIProxyAPI 公平调度 + 商业可靠性 → Sub2API ``` — *本报告基于源代码静态分析（含 `concurrency_service.go`、`usage_record_worker_pool.go`、`rate_limiter.go`、`config.go` 等核心文件），部分结论为推断性质，建议结合实际负载测试验证关键性能指标。* *报告生成：2026-04-15 | 最后更新：2026-04-15 | 分析工具：源码遍历 + go.mod 依赖树分析 + 请求管道推导* 2 个帖子 - 2 位参与者 阅读完整话题
CLIProxyAPI 在使用OAuth点击Codex 登录，显示认证失败: failed to start callback server. 查看日志：failed to start codex callback forwarder error=failed to listen on 0.0.0.0:1455: listen tcp 0.0.0.0:1455: bind: An attempt was made to access a socket in a way forbidden by its access permissions. 在本机执行 命令 netsh int ipv4 show excludedportrange protocol=tcp 显示 端口1455 在tcp 端口排除范围内。需要另指定端口。 使用命令 ./cli-proxy-api.exe --help CLIProxyAPI Version: 6.9.24, Commit: c4459c43, BuiltAt: 2026-04-12T06:27:52Z cli-proxy-api.exe -oauth-callback-port int Override OAuth callback port (defaults to provider-specific port) 的确有一个参数 oauth-callback-port 是可以更改callback port的，但这个参数是如何使用？ .\cli-proxy-api.exe -oauth-callback-port=12334 这样开启以后，仍然显示端口使用1455 请问大佬们遇到这个问题了吗？是如何解决的。 2 个帖子 - 2 位参与者 阅读完整话题
我已经安装好 CLI Proxy API，并且已经生成了 Key 和 Base URL，在 Codex 当中可以调用。 我发现问题是，在 Codex 当中使用到 CLI Proxy API 的这个能力时，它好像没有直接工作，而是在不断反复地陈述一些任务，但没有执行编码。 反观我在codex直接用chatgpt账号的时候，就马上开始代码了。这是怎么回事呢？这种体感差异非常明显。 sub2api 在codex就表现很正常。 我在cliproxyapi上反馈得到的回复是： CPA之负责转发、翻译数据包，并不会参与Agent的实际工作。 如果你觉得转发的数据包异常，建议开始request log，并尝试对比转发前后的报文。 1 个帖子 - 1 位参与者 阅读完整话题
具体错误是：额度获取失败：Codex 凭证缺少 ChatGPT 账号 ID 大佬，一般这个错误啥情况呀？ 看到论坛里面之前有个类似帖子说：更新CLIProxyAPI服务 ，不太 明白啥意思， 重启了也没效果。 5 个帖子 - 2 位参与者 阅读完整话题
我想知道sub2api和CLIProxyAPI这俩是一样的功能吗，小白求解惑。 8 个帖子 - 6 位参与者 阅读完整话题
cliproxy_to_sub2api_sync.py.zip (5.0 KB) CLIProxyAPI → Sub2API 同步脚本 因为使用了大佬的自动化脚本，而我却是sub2api的使用者，就写了一个脚本转换，直接无痛 大佬的自动化脚本在这： https://linux.do/t/topic/1928372/7 一、这是通用逻辑 读取 CLIProxyAPI 的 codex auth JSON 文件。 解析 token claim，并转换成 Sub2API 的 accounts 记录。 支持 insert / update / skip 三种同步动作，并用指纹去重。 支持单次同步（ --once ）和后台轮询（ --interval N ）。 二、下面这些默认值是按我当前服务器环境写的 源 auth 目录默认是 /root/cliproxyapi-deploy/app/auths 。 PostgreSQL 容器默认是 sub2api-postgres 。 数据库默认是 sub2api 。 数据库用户默认是 sub2api 。 导入后的账号默认绑定 group id (3, 1) 和 (2, 2) 。 导入后的 privacy_mode 默认是 training_off 。 三、如果要迁移到别的服务器，必须先检查 auth 源目录是否一致。 Docker 容器名、数据库名、数据库用户是否一致。 Sub2API 的 accounts / account_groups 表结构是否一致。 目标服务器里的 group id 是否还是 (3, 1) 和 (2, 2) 。 四、不要默认别的服务器和我这台机器完全一样 如果环境不同，请先改顶部常量或对应环境变量，再执行同步。 1 个帖子 - 1 位参与者 阅读完整话题
antigravity 模型额度提供太少，有没有能让模型列表支持gpt 5.4的方法？ 结合本地部署的cliproxyapi 实现gpt5.4开发。 11 个帖子 - 7 位参与者 阅读完整话题