1. 三个 Key 三套配置，绿联 NAS 上到底乱在哪

我一开始的用法很原始：OpenAI 一个 Key、Claude 一个 Key、NVIDIA 又一个 Key，每个平台一套 Base URL，每个客户端里各填一遍。桌面备忘录里躺着七八条地址，换台设备就得重新翻。问题不是模型不够用，而是入口太散——你每接一个新平台，就要把所有下游客户端改一遍。

这套场景放到绿联 NAS 上会更明显。NAS 本来就是个 7×24 小时开机的设备，你完全可以让它当"AI 网关"，但前提是得有一个统一入口层。CLI Proxy API 就是干这个的：它本身不是模型，而是夹在上游模型服务和下游客户端之间的一层代理，对外提供 OpenAI / Gemini / Claude / Codex 兼容的 API 形式。上游可以接 OpenAI、Gemini、Claude，也能通过 OpenAI-compatible 方式接入 NVIDIA 这类平台；下游不管是聊天客户端、脚本还是知识库，只认你这一个地址和一把 Key。

对个人自用来说，它比较实用的能力有几项：兼容多种接口风格，方便不同客户端统一接入；支持 OAuth 登录（OpenAI Codex、Claude Code 这类）；支持多账号轮询做负载分担；支持流式输出、工具调用和多模态输入；内置管理页面，能管配置、API Keys、凭据、日志和用量。

说白了，你要的是"改中间一层，下游全不动"。这篇就按这个思路，在绿联 NAS 上用 Docker 把 CLI Proxy API 跑起来，接一个 NVIDIA 上游，再用客户端验证整条链路。适合谁：手里有绿联 NAS、装了 Docker、被多平台 Key 管理搞烦的人。下面每一步都能直接复制跟做。

2. 前置准备：绿联 NAS 装 Docker、开 SSH、拿 NVIDIA Key

这一节把三样东西备齐：Docker（跑服务）、SSH（进终端执行命令）、NVIDIA API Key（当上游）。前两样如果之前配过，直接跳到 2.3。

2.1 在绿联 NAS 上安装 Docker

进入绿联 NAS 首页，打开应用中心，搜索 Docker，找到后点安装，等它装完。装好后桌面会多出一个 Docker 图标，顺手点进去确认能正常打开——后面 CLI Proxy API 的部署、启动、运行都靠它。

2.2 开启 SSH 并连接 NAS

进控制面板，点终端机图标，勾选 SSH 功能后点应用。这里提醒一句：SSH 密码就是你的登录密码，公网环境下务必设强密码。

然后在电脑端开终端。Windows 按 Win + X 选"终端（管理员）"，macOS / Linux 用自带终端。执行：

# ssh 你的绿联NAS用户名@你的绿联NAS访问IP地址 ssh susu@192.168.50.99

连上后切到 root：

sudo -i

2.3 注册 NVIDIA 并获取 API Key

打开 NVIDIA Build 页面（build.nvidia.com），点右上角 Login。有账号直接登，没有就输邮箱按提示注册，设密码、完成验证、创建账户。系统会发验证邮件，去邮箱拿验证码完成验证。之后页面可能要求补充账号名称等基础资料，按提示填。如果右上角出现 Verify 提示，继续按引导填手机号验证，支持 +86。

验证完成后，点右上角头像，菜单里找 API Keys 进管理页，点 Generate API Key，起个名字、选有效期、生成。页面会给出一串 Key，复制保存好，下一步配置上游要用。

3. 可复制配置：一键脚本部署 + NVIDIA 上游接入

这一节是全文的核心操作区，分两步：先把 CLI Proxy API 用 Docker 跑起来，再把 NVIDIA 作为 OpenAI 兼容上游接进去。

3.1 一键脚本部署 CLI Proxy API

手动搭要建目录、处理权限、准备配置文件，太啰嗦。这里用一键脚本把基础环境先跑起来。在 NAS 终端执行：

curl -fsSL https://gitee.com/jun-wan/script/raw/master/cliproxyapi_deploy/cpa_docker_deploy.sh -o /tmp/cpa_docker_deploy.sh && chmod +x /tmp/cpa_docker_deploy.sh && /tmp/cpa_docker_deploy.sh

执行后终端进入脚本初始化界面，选1或直接回车用默认配置。后面几步同理，不改默认参数就一路回车。脚本跑完会输出部署结果，复制终端里显示的管理页面登录地址，粘到浏览器打开，用终端输出的管理员账号密码登录后台。

如果你更想手动控制容器，下面这份docker-compose.yml片段可以直接参考（路径按你 NAS 实际目录调整）：

services: cli-proxy-api: image: ghcr.io/router-for-me/cliproxyapi:latest container_name: cli-proxy-api restart: unless-stopped ports: - "8317:8317" volumes: - /volume1/docker/cliproxyapi/config:/app/config - /volume1/docker/cliproxyapi/logs:/app/logs environment: - TZ=Asia/Shanghai

注意：端口 8317 是后面客户端要填的地址端口，别和 NAS 上已有服务冲突。挂载目录先建好，权限给足，否则容器起不来。

3.2 在后台添加 NVIDIA 上游

回到 CLI Proxy API 后台，左侧菜单找"AI 提供商"，滚到最下方"OpenAI 兼容提供商"，点右侧"添加提供商"。

先给提供商起个名方便区分，然后在 Base URL 填 NVIDIA 接口地址：

https://integrate.api.nvidia.com/v1

填好后点右侧"从 /models 获取"，程序会尝试拉取可用模型列表。没自动显示就再点一次，然后全选模型列表点添加。滚到页面底部，在 API Key 位置填入前面 NVIDIA 后台生成的密钥，任选一个刚添加的模型（推荐 gpt-oss-120b）做连接测试。页面提示"密钥测试通过"就说明这条上游可用，点底部"保存"完成添加。

这里有个关键点：Base URL 和 Key 必须成对。Base URL 填 NVIDIA 的，Key 就得是 NVIDIA 的；等你在客户端里填的时候，Base URL 要换成 CLI Proxy API 的地址，Key 换成 CLI Proxy API 的统一密钥。两套东西别混。

4. 验证请求：客户端接入与成功结果确认

上游接好了，得用真实客户端验证整条链路。这里以 OpenClaw 为例，思路对 Cherry Studio、Open WebUI 都一样。

4.1 先拿 CLI Proxy API 的统一密钥

进后台左侧"配置面板"→"认证配置"，能看到当前 API 密钥列表，复制其中一条。想给某个客户端单独建密钥也可以在这里新增。顺手把页面下方"系统配置"里的"使用统计"开关打开，点保存，后面能看请求记录和用量。

4.2 在 OpenClaw 里填地址和 Key

在 Windows 的 CMD 或 PowerShell 执行：

openclaw configure

进向导后选 Local → Model → Custom Provider（自定义提供商），然后填三件套：

两个坑要特别注意：第一，API Key 填的是 CLI Proxy API 的统一调用密钥，不是 NVIDIA 后台生成的原始 Key；第二，Model ID 别照抄示例，填你后台实际接入成功的模型名。界面出现Verification successful.就说明这组配置验证通过，选 Continue (Done) 保存退出。

4.3 对话测试确认链路

配置完如果当前会话没切到新模型，重启一下网关，或在网页端改当前会话模型，再发/new开新会话。然后输入：

你运行在什么操作系统上，当前接入的是什么模型？你可以干什么？

能正常返回、且回复里识别出当前模型信息，就说明统一入口生效了。返回内容大致会提到运行环境、当前模型名（形如custom-192-168-50-99-8317/openai/gpt-oss-120b）以及可用能力。到这一步，OpenClaw 已经通过 CLI Proxy API 接上了 NVIDIA 上游。

5. 本篇常见错排查：401、local proxy failed、reading choices

配置过程中最容易卡在几个报错上，逐个对照。

401 Unauthorized：九成是 Key 填错层了。客户端里填的必须是 CLI Proxy API 的统一密钥，不是 NVIDIA 原始 Key；后台上游里填的才是 NVIDIA Key。两边搞反就 401。另外检查密钥有没有多余空格，复制时容易带上换行。

local proxy failed / connection refused：客户端连不上 CLI Proxy API。先确认容器在跑（docker ps看状态），再确认 Base URL 里的 IP 和端口对——NAS 的局域网 IP + 8317，末尾/v1别漏。如果客户端和 NAS 不在同一网段，或者走了公网地址，检查穿透隧道是否在线。

reading choices / 返回结构解析失败：多半是 Endpoint compatibility 选错，或者 Model ID 填了后台不存在的模型。回后台确认模型列表里确实有这个名字，客户端兼容模式选 OpenAI-compatible。

OAuth 相关报错：如果你用的是 Codex 或 Claude Code 的 OAuth 接入方式，注意 OAuth 凭据和 API Key 是两套机制，别在需要 OAuth 的地方填 API Key。OAuth 登录失败时，重新走一遍授权流程，确认回调地址可达。

容器起不来 / 权限报错：挂载目录没建或权限不足。SSH 里ls -l看下目录属主，必要时chmod给足权限，再docker restart。

排查顺序建议：先看容器状态 → 再看后台上游测试是否通过 → 最后看客户端三件套。哪一层断了就在哪一层修，别一上来就重装。

6. 长期用下去：统一入口 + 稳定地址的 CTA

局域网里跑通之后，如果你想让这套入口在公司、外出时也能用，可以再叠一层内网穿透，把 CLI Proxy API 的页面和接口映射出去，并配一个固定的二级子域名，这样客户端里配一次地址就不用老改。

不过对多数人来说，真正省事的核心还是"统一入口"这四个字：上游在 CLI Proxy API 这一层统一管，下游不管接 OpenClaw、Hermes 还是 Cherry Studio，都是同一套地址和 Key。后面想加新平台，后台接一下上游就行，客户端不动。

如果你不想自己维护这套代理层，也可以直接用托管方案：模型对话入口在 https://taotoken.net/api ，接入文档和 API Keys 在控制台里拿，长期编码或跑 Agent 的场景可以看 Coding Plan。把 Base URL、Key、Model ID 三件套填对，链路就通了。

实测下来最值的两个场景：一是多平台轮着用不用再翻备忘录找 Key；二是统一调用后在后台看用量统计，哪个模型用了多少次一目了然。整套搭下来一两个小时，长期看是划算的。