NexAIX-官方博客
答案是：在 One API 后台进入「渠道」→「添加新的渠道」，渠道类型选「OpenAI」，「代理」一栏填兼容服务的端点地址，「密钥」填该服务签发的 Key。模型栏手动录入上游接受的准确模型名，并取消无关的默认模型。保存后在渠道列表点「测试」，看到返回的耗时就说明通了。
无论上游是第三方中转、开源模型推理节点还是自建网关，只要它实现了 OpenAI 协议，都走这条路。不需要二次开发，也不需要装插件。下面按表单顺序说明每一项怎么填，再讲测试报错的排查方法。
动手前先准备三样东西
- 上游的 Base URL：兼容服务对外的端点地址。
- 上游的 API Key：由兼容服务签发，不是 One API 自己的令牌。
- 上游的准确模型名：大小写、连字符、版本后缀都要和上游一致，最好直接从服务商的模型列表复制。
以 NexAIX 为例，它的 OpenAI 兼容端点是 https://api.nexaix.net/v1。Key 在官网导航的「获取 API Key」里创建。模型标识可以在模型清单里查，每个模型页都标明了供给方式：开源权重模型部署在自有算力上，闭源模型走厂商官方授权渠道。模型名直接从模型页复制，不要凭记忆手打。
添加渠道：逐项填写
1. 渠道类型：选「OpenAI」
这里的「OpenAI」指的是协议，不是厂商。选了它，One API 会按 OpenAI 的接口格式原样转发请求，对接任何兼容端点都用这个类型。
2. 名称
自己起名，写清是哪个上游、做什么用，比如「xx 兼容端点-生产」，方便以后在渠道列表里区分。
3. 代理 / Base URL：最容易出错的一项
One API 默认把 OpenAI 类型的请求发往 https://api.openai.com。填了代理字段后，请求会改发到你填的地址。
难点在于末尾要不要带 /v1。One API 和它的各个衍生分支（比如 New API）在路径拼接上有差别：有的版本会自动在后面接 /v1/chat/completions，有的允许你自己带上 /v1。建议这样处理：
- 先填不带
/v1的根地址，比如https://api.nexaix.net，保存后测试； - 如果测试返回 404，再改成带
/v1的完整地址重新测； - 以测试的实际结果为准，不要照搬别的版本的教程。
地址末尾不要多加斜杠，也不要把 /chat/completions 写进去。
4. 密钥
粘贴上游签发的 Key。一个渠道可以填多个 Key，每行一个，One API 会在这些 Key 之间轮询，用来分摊配额和并发。注意这些 Key 必须属于同一个上游、同一个 Base URL，不同服务商的 Key 混在一个渠道里，轮询到错误的那把就会 401。
如果上游按 Key 隔离额度（比如 NexAIX 每把 Key 有独立的配额、权限和用量账单），那么在渠道里放多把 Key，额度和账单也会按 Key 分开统计。
5. 模型
选了 OpenAI 类型后，模型栏会预选一批官方模型名。接第三方兼容服务时要做两件事：
- 手动输入上游的模型标识并回车添加。下拉列表里找不到开源模型或自定义模型名是正常的；
- 取消勾选上游实际不提供的默认模型。否则客户端请求这些模型名时，One API 可能把请求路由到这个渠道，然后被上游拒绝。
6. 模型映射：没有必要就留空
模型映射是一段 JSON，作用是把客户端请求的模型名改写成上游的模型名。比如你的应用里写死了某个旧模型名，又不想改代码，就可以用它。
One API 官方文档明确建议非必要不开启。开启后网关会重新构造请求体，不再原样透传，一些 One API 没有正式支持的扩展字段可能会丢失。如果上游的某些特有参数突然不生效，先检查是不是开了映射。能在客户端直接改模型名的话，就别用映射。
7. 提交
其他选项（分组等）先保持默认，确认能跑通之后再调整。
点「测试」，按报错定位问题
保存后回到渠道列表，点这个渠道的「测试」按钮。
- 返回耗时（ms）：连通性、鉴权和路径都没问题。
- 404：大多是代理地址末尾的
/v1多写了或漏写了，按上面的方法换一种写法再测。如果路径确认无误，再检查测试用的模型名在上游是否存在。 - 401：Key 错误、已失效或没有权限。检查复制时有没有带上空格或换行，多 Key 渠道里是不是混进了别家的 Key。
- Connection refused：网络不通，或被防火墙拦截。接本地或内网的推理服务时最常见。如果 One API 跑在 Docker 里，代理地址写的
localhost/127.0.0.1指向的是容器自己，不是宿主机，需要改成宿主机或推理服务实际可访问的地址，同时确认推理服务监听的不只是本机回环地址、端口已经放行。
其他状态码的含义和重试策略，可以参考 AI API 错误码怎么看。
测试通过后，从业务侧再验证一次
渠道测试只能说明 One API 到上游这一段是通的。业务调用走的是另一段：
- 客户端的
base_url指向你部署的 One API 地址（通常带/v1）； api_key用 One API 里创建的令牌，不是上游的 Key；model填你在渠道里录入的那个模型名，如果开了映射，就填映射前的名字。
用最小的一次对话请求确认能正常返回，再接入正式业务。客户端这一侧怎么改 base_url，见 OpenAI 兼容接口怎么用。如果下游是 Dify 这类平台，它对 /v1 的处理规则又不一样，可以参考 Dify 添加 OpenAI 兼容模型。
几个容易忽略的边界
- 一个上游对应一个渠道。不同服务商的 Base URL 和 Key 不要混在同一个渠道里，按上游分开建，出问题时才能定位到具体是哪一家。
- 模型名以上游为准。上游的模型清单会变，下线或改名后渠道测试就会报错。定期对照服务商的模型页更新渠道里的模型列表。
- 版本差异以实测为准。本文按 One API 主线的表单字段来写。衍生分支的字段名称和路径拼接规则可能不同，不确定时就用「测试」按钮的结果来判断。
评论(0)