NewAPI 和 Sub2API 爆 0 计费漏洞：内容照拿，钱不扣

行业快讯

两款被中转圈广泛使用的开源网关 NewAPI 与 Sub2API 近期被曝出 0 计费 BUG，模型返回完整响应却不计入账单。Sub2API 的情况更棘手——连 usage 记录都不写，运营方几乎无从察觉。

NewAPI 和 Sub2API 爆 0 计费漏洞：内容照拿，钱不扣

这两天 linux.do 上一个帖子又把中转圈的老伤疤揭开了：有人用 NewAPI 搭的中转站让模型写了几千字小说，耗时 153 秒、首字 0.4 秒——换算下来是一次完整、健康的长文本调用——结果计费栏躺着一个干干净净的 0。顺手又测了一下 Sub2API，情况更微妙：500 字、3000 字两个请求内容全拿到了，后台连 usage 记录都没写进去。

对于靠差价吃饭的中转站站长来说，这基本等于账本出现了看不见的窟窿。

事情是怎么冒出来的

这不是一个新 BUG。翻 Sub2API 的 GitHub issue 列表，#1430（「当模型设置为 GPT 时，会出现计费 0 元的问题」）和 #1544（「系统中出现未配置的模型，并且计费为 0」）其实已经挂了有一阵子了，一直处于 Open 状态。上个月社区里就有人零星反馈，但真正让这事出圈的是 5 月初又有用户做了一轮系统性复现，把 NewAPI 和 Sub2API 两边的行为差异摊开来看。

复现路径大致是这样的：

  • 在客户端里指定一个「非标准」或者网关里没有显式配置的模型名（比如 gpt、gpt-4、某些带版本号后缀的别名）；
  • 请求打过去，网关居然没拒绝，上游依旧正常返回；
  • 回到后台看账单——NewAPI 这边会记一条 0 计费的日志，至少还能看到；Sub2API 干脆什么都没留下。

你可以把这理解成：收银系统放进来了一个它不认识的商品条码，既没报错也没报警，直接按 0 元过了账。

NewAPI 后台管理面板出现多条 0 计费调用记录的截图示意

两个网关的「漏法」不一样

从技术实现上看，NewAPI 和 Sub2API 属于同一条产品线的不同分支，都是围绕 One API 演化出来的多模型聚合网关，核心逻辑是：接收 OpenAI 兼容请求 → 根据模型名匹配渠道 → 转发到真实上游 → 按 token 数计费。

问题恰恰出在「模型名匹配」这一环。

NewAPI 的问题偏「兜底策略过于宽容」。 当请求的模型名没在渠道里显式配置时，它不会直接 404，而是走一个默认路径把请求转出去，同时因为找不到对应的价格条目，计费函数返回 0。好处是日志里至少还能看到这条 0 元记录，站长只要盯后台就能发现异常。

Sub2API 的问题更深一层。 按照反馈，它在命中某些未配置模型或者特定模型名（比如裸 gpt）时，不仅计费走 0 分支，连 usage 写入逻辑都被跳过了。这意味着：

  • 用户面板看不到；
  • 日使用记录里查不到；
  • 只有去翻上游渠道的原始账单，对比自己这边的聚合数据，才能发现「怎么下游花了钱，上游一分没收」。

对于挂了十几条甚至几十条上游渠道的中转站，这种对账几乎没法每天做。等到月底一把对出来，窟窿早就挖穿了。

为什么这个 BUG 能活这么久

说实话，这类漏洞在开源中转网关里不算稀罕。根本原因有三个：

一是模型名的混乱现实。 OpenAI、Anthropic、Google 这些厂商自己就在频繁改模型别名，社区又衍生出一堆自定义映射——gpt、gpt-latest、claude、claude-4.5-sonnet-20260215 之类五花八门。网关为了「用户体验好」，普遍会做一层模糊匹配或默认兜底，这个兜底一旦写得不严谨，就成了计费漏洞的温床。

二是计费和日志是两套代码路径。 很多聚合网关的计费逻辑是 hook 在 token 统计回调里的，而 usage 记录写入是另一条链路。一旦在某个异常分支里提前 return，两条链路都会被跳过，结果就是请求成功、内容正常返回、但系统里查无此调。

三是测试覆盖盲区。 站长部署网关时通常只会测自己配过的模型，没人会专门去测「如果我传了一个没配置的模型名会怎样」。这种边界 case 只有在被人恶意或者无意触发后才会暴露。

谁在吃这个亏

明面上是中转站运营方在吃亏，但真实影响链更长。

下游用户如果用的是这种有漏洞的中转，短期看起来是白嫖——请求照常发，内容照常拿，但账户余额没动。问题是一旦上游发现异常调用量而中转站本身收不上钱，轻则渠道被封、服务中断，重则整个中转直接跑路，用户充的钱也跟着打水漂。

中转站这边更被动。你不能指望所有用户都老实按你定价付费，只要漏洞存在，就一定会有人写脚本批量刷。特别是 Sub2API 这种「静默 0 计费」的情况，运营方可能直到上游账单爆炸才意识到问题。

再往上，这件事会让真正正规运营的中转进一步被波及——当市场上出现一批「意外便宜」甚至「免费」的接口，用户的心理价格锚就被拖下去了。这是整个 API 聚合生态反复出现的老问题。

站长应该做什么

如果你正在用 NewAPI 或者 Sub2API，哪怕只是自用，这几件事现在就可以做：

  • 马上去后台翻近 30 天的调用日志，重点看 0 计费记录。 NewAPI 这边能直接过滤出来，Sub2API 得更费点劲，建议直接到数据库里跑一遍 SELECT 对比。
  • 关掉「未配置模型自动兜底」之类的开关。 如果网关有这类配置项，务必设置为严格模式：模型没配，就直接拒绝请求，别想当然地转发。
  • 给每个渠道设置兜底价格。 哪怕是一个极小的默认 per-token 价格，也比 0 强——至少能触发计费写入，留下痕迹。
  • 做上下游账单对账脚本。 每天跑一次，把自己网关的计费总额和上游渠道后台的消耗对齐，发现差距超过阈值就告警。
  • 盯住 GitHub 上的 issue 和 commit。 两个项目的 issue #1430、#1544 暂时还没合并修复 PR，建议订阅更新，有补丁第一时间打上。

如果你是中转的下游使用者，想提醒一点："这家怎么这么便宜"背后往往不是技术红利，而是有人在替你（暂时）扛单。用短期福利换长期稳定性，账其实不划算。对接口稳定性有要求的团队，老老实实选可对账、合规计费的聚合方更省心——像 OpenAI Hub 这类平台的好处恰恰在于账单透明、一个 Key 打通 GPT / Claude / Gemini / DeepSeek 全主流模型，不用在多个开源网关之间自己打补丁救火。

顺带提一句行业的状态

过去一年，中转圈其实已经从「野蛮生长」过渡到「运维密集」阶段了。上游厂商在持续收紧 API 风控、打击代理、调整模型命名，中间那层的工程复杂度比两年前高出一个数量级。NewAPI、Sub2API 这类开源项目以一己之力扛了不少场景，值得尊重，但它们本质上是社区维护项目，响应速度、测试覆盖、对抗恶意流量的能力都有上限。

这次的 0 计费 BUG 说到底是一个提醒：聚合网关不是装好就完事的东西。模型名的别名、渠道配置的兜底、计费和日志的原子性——任何一个环节上松了，都会变成账单上看不见的洞。自建中转在成本模型上有吸引力，但别忘了背后的隐性运营成本，特别是对账这件事，绝对不能只靠网关自己说了算。

目前两个项目的维护者还没有针对这波反馈发布正式修复，感兴趣的同学可以直接去原 issue 下面跟进进度，或者先按上面的建议临时做兜底处理。等补丁合并之后，也建议再完整测一轮——毕竟这种涉及计费路径的修改，一不小心还可能引入新的边界问题。

参考来源