NewAPI 接入 Luna 模型报错排查指南：为什么 Sub-API 能跑 NewAPI 却不行？

最近在折腾 AI 服务中转的时候，遇到了一个挺典型也挺让人头秃的问题。

问题描述其实很简单：

我手里有一个 5.6 版本的 Luna 模型 API。我用惯用的 Sub-API (sub2api) 去挂载这个渠道，测试一切顺利，连接顺畅，能跑通。但是，当我换成了目前社区里很火、功能也更强大的 NewAPI 去挂载同一个 API 地址时，系统直接给我弹出了错误提示。

这就很离谱了，同一个源，为啥这扇门能进，那扇门就被堵住了？今天就借着这个案例，和大家聊聊这类问题通常出在哪，以及怎么排查解决。

一、 先别急着骂软件，检查“基础配置”

遇到“这个能跑那个不能”的情况，第一步往往不是软件本身的 Bug，而是配置项的细微差异。NewAPI 的功能比 Sub-API 更细致，这既是优点，也容易成为坑点。

1. 渠道类型（Channel Type）是否选对？

NewAPI 创建渠道时，类型非常多（OpenAI、Anthropic、自定义等等）。如果 Luna 的接口是兼容 OpenAI 格式的，务必选 “OpenAI” 类型。如果它有自己的特殊格式，可能需要选择对应的其他类型或者“自定义”。

• 排查建议： 即使你知道它是类 OpenAI 的，也试着切换一下渠道类型看看。有时候某个小版本的接口变动，可能导致分类不符。

2. Base URL 和 API Key 的“尾巴”问题

这是最容易出错的地方。Sub-API 有时候比较智能，能自动处理末尾的斜杠 / 或者路径拼接。但 NewAPI 对路径的匹配要求更严格。

• Base URL： 确保没有多余的斜杠，或者缺少必需的路径。比如 Luna 的接口可能需要 /v1 后缀。
• API Key： 检查有没有不小心复制到了空格。NewAPI 对 Key 的校验有时非常敏感，一个空格都能导致鉴权失败。

3. 模型名称（Model Name）映射

NewAPI 有一个很强的功能叫“模型映射”或“模型重写”。如果你的 Luna 请求的模型名和后端实际返回的不完全一致，NewAPI 可能会拦截。

• 排查建议： 在渠道配置里，把“模型映射”这一栏填清楚，或者先暂时设置为“通配符/允许所有模型”进行测试，排除是名字匹配的问题。

二、 深入一点：检查“自定义转换”

NewAPI 之所以强大，是因为它允许你在请求转发前后做预处理。但如果你之前的配置是从别处导进来的，可能带了不兼容的预处理脚本。

检查“预设指令”或“预处理”：

看看你的 NewAPI 渠道设置里，有没有勾选一些高级选项，比如“强制模型”、“自定义请求头”或者“请求体替换”。

Luna 5.6 可能对某些 Request Header 比较敏感。如果 NewAPI 强制塞进去了一些 Header（比如 X-Api-Version 之类），可能会导致后端拒接。

操作： 暂时关掉所有自定义的高级设置，把它还原成最简模式，只保留 URL 和 Key，再测一次。

三、 终极排查：看日志（Log）！

如果上面两步都试过了还是报错，这时候就别猜了，直接看日志。这是程序员解决问题的唯二真理之一（另一个是重启）。

NewAPI 日志怎么看？

1. 进入 NewAPI 的管理后台。
2. 找到“日志”或者“渠道日志”菜单。
3. 发起一次测试请求，立刻捕捉那条红色的报错记录。
4. 关键点来了： 点击详情，看 响应体（Response Body）。

这里通常会明明白白写着 Luna 的服务端到底为什么不满足。比如：

• 401 Unauthorized：那是 Key 错了。
• 400 Bad Request：那可能是参数格式不对，或者 NewAPI 传了 Luna 不支持的参数（比如 stream: false 的处理差异）。
• 403 Forbidden 或 429：可能是限流或者是 IP 封禁。

有了具体的错误信息，你甚至可以直接把那段英文丢给 AI 或者去搜索引擎查，解决方案一目了然。

总结

Sub-API 能跑不代表 NewAPI 一定就要用同样的配置。NewAPI 因为功能更丰富，对配置的规范性要求也更高。遇到这种“一个能转一个不能”的情况，通常就是路径、模型名或者请求头的不匹配导致的。

下次再遇到别慌，先清配置，再看日志，基本都能找到原因。希望这篇小教程能帮你省点掉头发的功夫！