如果同一个AI模型要接给OpenClaw、聊天工具和自动化工作流,每个客户端都直接填写上游 API 地址与密钥,初次配置不算难,但后期增加提供商、切换模型或更新密钥时,维护工作会逐渐变多.我希望保留绿联 NAS 作为长期运行的基础设备,把不同模型渠道放到统一的代理层中,再给下游客户端提供固定的调用入口.这样既能清楚区分上游凭据和客户端使用的 Key,也方便后续扩展其他兼容接口.我还希望出现问题时能按上游、代理和客户端三个环节分别排查,不再把模型不可用与地址填错混为一谈.本文以CLI Proxy API 为核心,在绿联NAS上先准备Docker与SSH环境,使用原文的一键脚本完成部署;之后注册NVIDIA 账号、生成 API Key,通过OpenAI 兼容提供商方式加入上游模型,并在Windows的OpenClaw中填写NAS 地址、统一 API Key 和 Model ID 进行验证.局域网调用确认无误后,再安装cpolar,分别演示随机公网地址和固定二级子域名的配置.每一步都会保留原有操作截图、命令和关键参数,方便对照复现.需要说明的是,NAS 在这里运行的是代理服务,推理由NVIDIA 上游完成;公网访问也不等同于可以忽略管理权限、密钥保护和访问控制.
目录
1.CLI Proxy API是什么:先理解这层“统一入口”
开源项目地址：https://github.com/router-for-me/CLIProxyAPI
CLI Proxy API 不是大模型本体,也不负责在NAS上运行推理.它位于模型提供商和实际使用模型的客户端之间:上游连接不同服务,下游通过兼容API访问同一个代理入口.项目提供 OpenAI、Gemini、Claude、Codex 等兼容接口,具体可用能力应以所部署的版本和对应上游为准.
我看中的是把重复配置集中到一处处理.以前客户端各自保存一套上游地址和凭据,新增模型就要逐个改;现在可以先在代理中配置上游,再给 OpenClaw 或其他兼容客户端提供统一的地址和调用密钥.它并不会让所有模型自动具备相同能力,但能把接口管理集中起来.
原文涉及的功能可以归纳为以下几项：
- 兼容多种接口风格：提供 OpenAI、Gemini、Claude、Codex 等兼容 API,方便使用相应协议的工具接入.
- 部分提供商支持 OAuth：例如文档列出的 OpenAI Codex、Claude Code 接入方式,具体以项目版本为准.
- 多账号调度：在受支持的上游上,可使用多账号轮询等能力.
- 请求能力：项目文档列有流式与非流式响应、工具调用,以及文本和图片输入等功能;实际支持情况仍取决于所选模型.
- 兼容上游扩展：可配置OpenAI-compatible 提供商,本文连接 NVIDIA 使用的就是这一入口.
- Web 管理界面：支持通过
management.html进入管理页面,维护代理设置、密钥、凭据和使用记录等.
所以,我把 CLI Proxy API 看成自己的模型接口管理层,而不是一个新的聊天软件.先把它放到 NAS 上,再接入具体模型,后面的客户端才能真正利用这个统一入口.
2.先准备环境:绿联NAS的Docker与SSH
我这次不在电脑上临时启动代理,而是让绿联 NAS 承担长期运行的任务.正式部署前需要确认两项基础条件：Docker 用来运行服务容器,SSH用来进入NAS终端执行命令.
如果你已经安装 Docker、能够通过SSH登录NAS,可以直接跳到第3节.
2.1在应用中心安装Docker
先打开绿联 NAS 首页,在应用中心找到 Docker：
搜索 Docker,选择相应应用并安装：
安装后桌面会出现 Docker 图标：
建议先打开一次 Docker,确认应用可以正常进入,再继续后面的部署操作.
2.2开启SSH,连接NAS终端
接下来需要从电脑端连接 NAS.先在绿联系统中开启 SSH 服务：
依次进入控制面板 → 终端机：
勾选 SSH 功能并应用.SSH登录凭据需要妥善保管,尤其不要把管理端口直接对陌生公网开放：
在电脑端打开终端.Windows可以使用PowerShell,macOS 或 Linux 可以使用系统终端.下面的用户名和 IP 为原文演示值,实际执行时请换成你自己的 NAS 信息：
# ssh 你的绿联NAS用户名@你的绿联NAS访问IP地址
ssh [email protected]
SSH 连接成功后,按原文演示切换到root用户,后续执行部署命令：
sudo -i
做到这里,Docker 和 SSH 两个基础条件就准备好了.
3.用部署脚本启动CLI Proxy API
基础环境确认正常后,就可以把代理服务放到 NAS 上.
原文使用一条脚本命令完成初始部署,省去了逐个创建目录和手动填写基础配置的过程.我保留这一部署方式,方便对应截图复现.它是第三方脚本,不等同于CLI Proxy API 官方安装器,执行前应检查脚本内容与来源.
进入前面连接好的终端,执行原文命令：
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】,也可以回车采用默认项;其余配置按自己的实际情况填写,不清楚的参数先不要随意修改：
完成镜像拉取和容器配置后,终端会输出部署信息：
复制终端显示的管理页面地址,在浏览器中打开：
再使用终端给出的管理登录信息进入后台.若脚本生成了默认凭据,正式使用前应更换并妥善保存：
此时只能说明代理服务的管理入口已经部署出来,模型上游还没有接入.下一步要准备 NVIDIA 的 API Key.
4.注册NVIDIA,生成上游API Key
在代理里添加模型之前,需要先拥有上游服务的调用凭据.我选择NVIDIA Build演示,拿到的 Key 将保存在 CLI Proxy API 的上游配置中,不直接交给 OpenClaw.
4.1注册或登录NVIDIA账号
英伟达模型页：https://build.nvidia.com/
打开上方 NVIDIA Build 页面,按平台当前展示的注册与验证流程准备账号.不同账号的验证步骤可能有所差异,以下是原文截图对应的操作路径.
点击右上角 Login：
已有账号直接登录;第一次使用则输入邮箱,按提示创建账号：
设置账户密码,完成页面要求的校验：
如果收到邮件验证码,打开注册邮箱完成验证：
继续补齐页面要求的账号信息：
若右上角仍显示 Verify,按提示继续完成验证：
原文示例使用了手机号验证.能否使用某个地区号码、是否还需其他验证,以自己账号页面实际提示为准：
验证完成后就搞定啦！
4.2创建NVIDIA API Key
账号验证完成后,就可以进入 Key 管理页面.
点击头像,选择 API Keys：
选择 Generate API Key,填写用途名称并按需设置有效期：
生成后立即妥善保存.这是访问 NVIDIA 上游的凭据,不要放进公开文章、截图、前端页面或仓库：
后面需要回到 CLI Proxy API,使用这把上游 Key 完成提供商配置.
5.添加NVIDIA作为OpenAI兼容上游
NVIDIA 的调用凭据已经准备好,接下来让 CLI Proxy API 知道去哪里请求模型.这里使用 OpenAI 兼容提供商,而不是把 NVIDIA 当成一个直接部署在 NAS 上的模型.
进入管理后台左侧的 AI 提供商,找到 OpenAI 兼容提供商,点击 添加提供商：
为提供商填写一个便于识别的名称,并在 Base URL 处输入原文的 NVIDIA 接口地址：
https://integrate.api.nvidia.com/v1
接着点击 从 /models 获取：
如果模型列表未立即出现,可以检查网络、Key 和接口地址后再次获取.列表显示后,选择要使用的模型并点击添加;原文演示为全选.
继续滚动到 API Key 输入框,填写上一节生成的 NVIDIA Key.随后选择一个已经添加的模型进行连接测试,原文以 gpt-oss-120b 为例：
出现 密钥测试通过 后,说明该测试请求获得了有效响应;再点击底部 保存.可调用的模型及额度以 NVIDIA 账号当前开放情况为准.
代理后台的上游测试完成后,还需要从真正的客户端发起一次请求,才能确认“客户端 → 代理 → NVIDIA”这条链路按预期工作.
6.接入OpenClaw,验证统一接口能否真正调用
我接下来用 Windows 上已经安装好的 OpenClaw 做客户端.这样可以验证的就不只是代理后台能否测试上游,而是实际工具能否经由 NAS 里的统一入口获取模型响应.
以后如果还要接入 Cherry Studio、Open WebUI 或其他兼容工具,方法也是分别配置它们所需的 API 地址、凭据和模型标识;并不是所有客户端都能无条件复用同一套界面选项.
下面以OpenClaw的设置界面为准完成一次配置.
6.1取得CLI Proxy API的客户端调用密钥
先回代理后台准备给客户端用的 Key.这里的 Key 与 NVIDIA 上游 Key 不是同一把,也不要用管理后台的密钥代替调用密钥.
进入配置面板 → 认证配置,在 API 密钥列表中复制已有调用密钥,或为该客户端新增一条： 
我还在系统配置中启用了使用统计,保存后方便观察后续调用记录.不过统计开关不是 API 调用成功的必要条件：
复制好统一调用密钥,再去OpenClaw填写配置.
6.2在OpenClaw中设置代理地址、密钥和模型
这一步在已经安装 OpenClaw 的 Windows 电脑上操作,CLI Proxy API 仍运行在 NAS 上.
打开CMD或PowerShell,运行配置向导：
openclaw configure
进入向导后,按原文截图选择 Local → Model → Custom Provider（自定义提供商）： 
接下来分别填写服务地址、调用密钥、协议兼容类型以及模型 ID：
-
API Base URL：填写绿联 NAS 上代理服务的地址,末尾保留
/v1.
原文局域网示例：http://192.168.50.99:8317/v1 -
API Key：填写 CLI Proxy API 里复制的统一调用密钥.
-
Endpoint compatibility：选择 OpenAI-compatible.
-
Model ID：填写代理后台已经添加、且当前可用的模型标识.
各项参数填写后的界面如下： 
这里最容易混淆的有两项：
第一，OpenClaw 使用的是代理发给客户端的 Key,而非 NVIDIA 的原始上游 Key.
第二，Model ID 要与代理中实际可用的模型名称对应,不要直接照搬截图里的示例.
若向导显示 Verification successful.，表示这一组连接参数通过了当前验证.选择 Continue (Done) 保存.
配置保存后，继续做真实对话测试,不要只凭验证提示判断整个使用场景已经完成.
6.3发起一轮实际对话测试
如果当前会话还在用旧模型,可以先在 OpenClaw 中切换到新配置;必要时按原文方式重启网关或发送 /new 开启新会话.
我在测试时输入了下面这段提示词：
你运行在什么操作系统上，当前接入的是什么模型？你可以干什么？
原文的测试截图如下：
从截图可以看到,OpenClaw 收到了回答,且响应中出现了本次配置相关的模型信息.这能证明当次请求已经返回,但模型对自身环境的口头描述不应当作独立的系统检测结果.
原文记录的回答示例如下,保留原样便于对照：
我运行在 Windows 11（内部版本 10.0.22621） 的 64 位环境上，GPU 是 RTX 2080 Ti。当前使用的模型是ustom‑192‑168‑50‑99‑8317/openai/gpt‑oss‑120b，这也是系统默认的模型。
我可以直接在工作区里读取、编辑和创建文件，执行 shell 命令，调度 cron 任务，搜索并抓取网页内容，控制浏览器进行交互，管理子会话（如代码生成子代理），以及使用 TTS、消息发送等工具。还有一些专门的技能（coding‑agent、healthcheck、weather 等）可以按需调用。有什么需要我帮忙的，尽管告诉我！
结合上游连接测试和这次客户端对话,可以确认原文所展示的这次接入流程具备实际调用结果.后续增加模型时,我会优先从代理后台维护上游配置,再检查客户端模型标识是否需要调整.
7.需要外出使用时,再部署cpolar
在 NAS 的局域网地址下,我们已经完成服务部署、上游接入和 OpenClaw 请求测试.到这里就可以先用于同一网络中的设备,无须为了演示而立即开放公网.
如果还想在家外使用,就需要给代理准备能从外部访问的入口.本文沿用原文的cpolar方案,在 NAS 上建立到本地代理端口的隧道.
建议先确认局域网调用没问题,再做外网访问.尤其这套服务包含 API 调用能力与管理页面,不能仅因为获得 HTTPS 地址,就忽略访问权限.
7.1cpolar在这套方案中的作用
- cpolar 用来把 NAS 上的本地 Web/API 服务映射为公网访问地址;它不提供模型推理,也不会替代 CLI Proxy API 的认证.
- 可以在相应平台安装客户端.本文使用 Linux 安装方式,将服务运行在绿联 NAS 上.
7.2在NAS上安装cpolar
我继续沿用之前的 NAS 终端,不需要把安装命令放到 Windows 本机执行.
在 SSH 连接的绿联 NAS 终端中运行：
sudo curl https://get.cpolar.sh | sh
安装结束后检查 cpolar 服务状态：
sudo systemctl status cpolar
看到 active (running) 表示服务进程正在运行,下一步还需要检查管理界面和隧道是否正常.
在浏览器中输入以下地址：
绿联 NAS 的局域网 IP 地址 + 9200 端口
即可打开 cpolar 的 Web UI：
能打开页面后,使用自己的cpolar 账号登录;尚未注册则按页面提示注册.
8.创建CLI Proxy API的公网访问隧道
我先建立一条随机地址隧道,确认公网确实能够转发到 NAS 上的代理端口,再考虑要不要换成固定域名.
登录 cpolar Web UI,进入 隧道管理 → 隧道列表 → 创建隧道：
给隧道取一个易识别的名称,例如 cpa，并填写原文演示参数：
-
协议：
http. -
本地地址：填写 CLI Proxy API 实际运行的端口.
原文使用8317,因此填写：8317 -
地区：
China Top.
核对参数后点击 创建：
完成后进入 状态 → 在线隧道列表,查看系统生成的公网访问地址.原文截图中同时展示了 HTTP 与 HTTPS 地址：
复制 HTTPS 公网地址.如果要访问原文的管理页面,应在地址后拼接以下路径：
/management.html
例如：
https://你的公网地址/management.html
浏览器测试界面如下：
页面能加载说明隧道与网页资源已接通;随后还应检查管理鉴权是否正常,而不是把“能打开登录页”视为已经安全：
公网管理提醒： CLI Proxy API 的远程管理还受自身配置与管理密钥约束。建议仅在确有需要时开放管理访问，使用独立强密钥并限制可访问人员；普通客户端只需调用 API，不一定要对所有人开放管理后台。
9.改用固定二级子域名,减少客户端改地址
随机公网地址适合先验证配置,但长期接入客户端时,一旦域名变化,保存的 Base URL 也需要跟着修改.
所以,我在确认随机隧道可用后,再为同一个服务保留固定二级子域名.这里的“固定”指域名可以长期保留,不代表 NAS 断电、隧道离线或上游不可用时服务仍可访问.
登录cpolar控制台,进入预留 → 保留二级子域名,选择地区并填写名称和备注：
https://dashboard.cpolar.com/reserved
截图对应的操作如下：
原文示例保留的名称是 cpatest01.这个名称需要未被占用,具体以自己账号实际保留结果为准.
回到本地cpolar Web UI,进入隧道管理 → 隧道列表,找到 cpa 隧道：
点击 编辑,将域名类型改为二级子域名,在 Sub Domain 填入刚才保留的名称,然后点击 更新：
进入状态 → 在线隧道列表,确认显示的地址已从随机域名变为保留的二级子域名：
使用固定地址时,打开管理页仍需按原文拼接 /management.html：
如果域名可以访问、管理鉴权也符合预期,再用实际客户端测试公网 API 地址.最后记得把长期使用的客户端 Base URL 更新成新的 HTTPS 公网地址,并保留正确的 /v1 路径.
10.总结:让模型渠道在一处管理
这次我从绿联 NAS 的 Docker 和 SSH 环境开始,先部署 CLI Proxy API,再接入 NVIDIA 的兼容模型接口,并通过 OpenClaw 发起实际请求.局域网内把调用链跑通之后,又用 cpolar 配置了公网访问和固定二级子域名.过程中最重要的收获,不是“模型变多了”,而是上游模型和下游客户端各自承担的角色更清楚了.
- 部署层：NAS 持续运行 Docker 容器,CLI Proxy API 负责统一接收与转发模型请求.
- 上游层：NVIDIA 提供模型接口和上游 API Key,具体调用资格、配额及服务状态仍由上游决定.
- 客户端与网络层：OpenClaw 用代理调用密钥接入;cpolar在需要时提供公网入口,固定域名减少地址变更.
以后再接新模型,我可以先在 CLI Proxy API 中添加提供商,再检查客户端是否需要切换 Model ID.这样的价值是少做重复配置,而不是宣称所有客户端、模型和网络环境都会无条件兼容.正式长期使用时,仍要做好密钥保管、管理界面访问限制,以及NAS上相关配置的备份.
敬请期待下一篇文章内容
每日心灵鸡汤: 当情绪跑在事实前面,自媒体时代最危险的传播陷阱!
现在世界进入了一个“一句话就可能影响很多人”的时代.不是因为这个人的能力突然变强了,而是媒体从中心化进入了自媒体时代:任何个体,只要他的表达恰好代表了足够多人的情绪、立场和想象,就可能迅速形成共鸣,并被算法继续放大.于是一个普通人,也可能在极短时间内获得过去只有媒体机构才拥有的传播能力.问题在于,传播权已经大众化了,但事实核验、责任意识和判断能力并没有同步大众化.所以今天真正危险的,不只是有人说错话,而是一个未经证实的叙事,一旦成为群体立场,就可能先于事实形成结论,甚至直接改变另一个人的现实命运.
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2401_87629362/article/details/166786464
