OpenClaw + cpolar 实战：远程 NAS、分享小游戏、RDP，再配置公网 AI 入口

前言

OpenClaw 真正部署成功以后，我反而觉得最容易卡住的不是安装，而是"接下来到底拿它做什么"。只在本机对话当然能用，但如果它还能帮我把家里的 NAS 服务临时开放到外网、写一个小游戏后直接分享、给 Windows 远程桌面建立连接，甚至把 OpenClaw 自己也变成一个可以从手机打开的 Web 入口，那它才开始从"装好了"变成"真的进入日常使用"。不过这种玩法越往外延伸，越不能只盯着"一句话完成"这几个字：本地服务、cpolar 隧道、OpenClaw 网关、Origin 白名单、Token 和设备授权，其实分别承担不同职责。对我来说，AI 真正有用的地方不是把这些环节藏起来，而是把原本分散的操作串成一条更顺手的任务链，同时让我还能看清每一步到底是谁在工作。

这次我按现有环境把几条链路都实际走了一遍：先安装 cpolar，再让 OpenClaw 配合它为飞牛 NAS 上的 OpenList 创建公网入口；接着生成一个贪吃蛇小游戏并分享；然后把 Windows 3389 远程桌面映射成 TCP 公网地址；最后再把 OpenClaw 自己的 18789 Web 页面开放到公网，并依次处理 allowedOrigins、网关令牌和设备配对。随机地址跑通后，再切换到固定二级子域名 openclaw。我更看重的是这些链路能不能一层层解释清楚，而不是把"AI 会操作工具"写成所有网络配置都自动、安全、无需判断。

1. 先分清 OpenClaw 和 cpolar 各自负责什么

OpenClaw 在这套玩法里更像一个可以执行任务、生成内容并调用本地工具的操作入口。

我会把它的作用理解成：

接收自然语言需求；
生成 HTML 等内容；
在当前环境里执行相应操作；
根据任务继续调用已经安装好的工具。

至于 cpolar，职责更单一：

把本地或局域网里的 Web / TCP 服务建立公网访问入口。

所以这篇后面的几种玩法，本质上都在重复同一个逻辑：

OpenClaw 负责理解和执行任务，cpolar 负责网络入口。

把这两层分开以后，很多看起来"AI 一句话搞定"的动作就容易理解了。

2. 先把 cpolar 安装好

2.1 下载并确认安装

下载安装包并完成安装以后，在 CMD 中执行：

shell 复制代码

cpolar version

看到版本信息以后，说明当前 cpolar 已经可以使用。

3. 注册并进入 cpolar Web UI

先完成 cpolar 账号注册。

进入注册页面。

注册完成以后，在浏览器打开：

shell 复制代码

http://127.0.0.1:9200

然后使用刚才注册的账号登录。

登录成功后就可以在 Web UI 里查看和管理隧道。

4. 第一种玩法：让 OpenClaw 帮我把 NAS 上的 OpenList 暴露到公网

这次家里的飞牛 NAS 上已经有一个 OpenList 服务。

局域网里可以正常访问。

当前 OpenList 地址是：

如果人在家里，这个地址直接用就行；但离开局域网以后，内网地址自然不能直接从外部访问。

这时候我直接把需求告诉 OpenClaw：

shell 复制代码

我的OpenList服务部署在局域网中的飞牛Nas上，OpenList的访问地址为<http://192.168.50.228:5244>,我的电脑上有cpolar，请你用cpolar穿透局域网的这个服务，给我一个公网地址，我要在外面进行访问我的OpenList看电影

当前流程里，OpenClaw 根据这个需求调用 cpolar，并返回了一个公网地址：

shell 复制代码

https://54e9cc9b.r3.nas.cpolar.cn

打开以后：

页面已经可以访问 OpenList。

继续登录并播放测试。

这条链真正跑通的是：

OpenClaw 接收需求 → cpolar 为提供公网入口 → 外部浏览器访问 OpenList。

这里 OpenList 仍然负责 NAS 文件和媒体内容，cpolar 只负责公网访问地址。

5. 第二种玩法：让 OpenClaw 写一个小游戏，再直接分享出去

比起"AI 能写代码"，我更在意写完以后是不是马上能用。

这次直接给 OpenClaw 一个比较具体的需求：

shell 复制代码

帮我写一个贪吃蛇小游戏，要好看一点，用HTML写，写完后帮我在本地起一个服务，让我能在浏览器里直接玩

当前流程里，OpenClaw 生成了一个 HTML 贪吃蛇小游戏，并在本地启动 Web 服务。

到这里游戏已经能在当前电脑浏览器里打开。

接下来我继续告诉它，希望把这个本地游戏分享给朋友：

shell 复制代码

这个游戏太好玩了，我想分享给朋友一起玩，请你用cpolar帮我把这个游戏的本地服务穿透到公网，给我一个公网链接

随后得到公网链接：

从浏览器直接打开：

小游戏页面可以正常访问。

这条链和前面的 NAS 很像：

OpenClaw 生成内容并启动本地服务 → cpolar 把服务提供到公网 → 朋友通过浏览器打开。

所以真正方便的并不是"AI 替你省掉所有网络知识"，而是生成内容和建立访问入口可以放在同一条任务链里完成。

6. 第三种玩法：远程连接家里的 Windows 电脑

如果家里的 Windows 已经启用远程桌面，另一个很实际的需求就是人在外面时远程回去。

先在：

设置 → 系统 → 远程桌面

打开远程桌面。

当前使用默认端口：

3389

然后把需求交给 OpenClaw：

shell 复制代码

我想在外面远程控制我家里的这台Windows电脑，我的电脑已经开启了远程桌面，端口是默认的3389，请你用cpolar帮我把3389端口穿透到公网，给我一个公网地址，让我在外面可以远程连接

当前返回的 TCP 公网地址为：

在外部 Windows 电脑上按：

Win + R

输入：

mstsc

打开远程桌面连接。

填写公网地址时，需要去掉前面的：

tcp://

随后输入家里电脑的用户名和密码。

当前测试可以进入家里的 Windows 桌面。

这里真正需要分清的是：

OpenClaw 负责根据需求创建操作，cpolar 负责把 3389 建立成 TCP 公网入口，Windows RDP 自己负责远程桌面会话。

三层不是一回事。

7. 前面都能远程了，为什么 OpenClaw 自己还只能本机用？

前面的玩法都发生在部署 OpenClaw 的这台电脑上。

如果人在外面还想继续直接和 OpenClaw 对话，总不能每次先 RDP 回家再开页面。

所以最后一条链更直接：

把 OpenClaw 自己的 Web 控制界面提供到公网。

先进入 cpolar Web UI：

页面默认已有两条隧道：

remoteDesktop → 3389 / TCP；
website → 8080 / HTTP。

这次编辑 website 隧道，把本地地址改成 OpenClaw 的：

18789

协议使用：

http

地区：

China Top

更新以后，到在线隧道列表查看公网地址。

当前页面里显示的是：

astrbot-6185

隧道名称。

这里和后面使用的 openclaw 隧道名称并不一致，我不把这两处强行合并。真正操作时，应以实际指向 OpenClaw 18789 的那条隧道为准。

8. 第一次公网打开 OpenClaw，为什么会报 Origin 不允许？

通过生成的公网 HTTPS 地址访问以后，页面确实能打开，但首先出现：

shell 复制代码

# "来源（Origin）未被允许（请从网关所在的主机打开控制界面，或在 gateway.controlUi.allowedOrigins 配置项中允许该来源）"
origin not allowed (open the Control UI from the gateway host or allow it in gateway.controlUi.allowedOrigins)

当前环境里，OpenClaw 控制界面对来源做了限制，因此新的公网域名需要加入：

gateway.controlUi.allowedOrigins

在 Windows 中按：

Win + R

输入：

cmd

然后执行：

shell 复制代码

# 注意替换其中的穿透域名改为自己穿透出来的随机域名地址
openclaw config set gateway.controlUi.allowedOrigins "[\"https://75de4fe1.r1.cpolar.top\"]" --strict-json

openclaw gateway restart

这里一定要把示例里的：

https://75de4fe1.r1.cpolar.top

替换成自己当前真正生成的公网域名。

配置完成并重启网关以后，再重新打开公网地址。

这时候 Origin 错误已经改变，说明前一层来源限制已经处理。

9. Origin 放行以后，为什么还不能直接聊天？

第二层问题是：

没有携带网关令牌。

回到本地 OpenClaw 界面的【概览】页面复制网关令牌。

然后在公网访问页面中同样进入【概览】，粘贴 Token 并连接。

这时还会提示：

此设备需要网关主机的配对批准。

也就是说，Origin、Token、设备授权是三层不同检查，不是改完一个白名单就全部结束。

10. 批准公网设备

回到 CMD 或 PowerShell，执行：

shell 复制代码

openclaw devices list

# 注意需要将 <requestId> 替换成 Request 中的id字符串
openclaw devices approve <requestId>

其中：

<requestId>

要替换成 Request 中实际出现的 ID。

审批以后，再回到 OpenClaw 页面。

当前健康状态已经显示：

正常

继续实际发送消息。

页面可以正常对话。

到这里，随机公网地址这一整条链才真正跑通：

cpolar 公网入口 → Origin 放行 → 网关 Token → 设备批准 → OpenClaw 正常对话。

11. 随机地址能用以后，再换成固定二级子域名

如果只是临时测试，随机公网地址已经足够。

如果准备长期在手机或其他设备上访问，再配置固定地址更省事。

进入 cpolar 预留页面：

shell 复制代码

https://dashboard.cpolar.com/reserved

当前保留记录为：

地区：China Top
二级域名：openclaw

二级域名以自己账号实际保留成功的结果为准。

接着回到【隧道管理 → 隧道列表】，找到：

openclaw

隧道并编辑。

把域名类型修改成：

二级子域名

并填写前面保留的名称。

更新后，在在线隧道列表中可以看到固定二级子域名形式的地址。

使用 HTTPS 地址访问。

12. 换了固定域名以后，allowedOrigins 也要跟着换

固定域名和前面的随机域名是两个不同的 Origin。

所以切换以后，再执行：

shell 复制代码

# 注意替换其中的穿透域名改为自己配置的二级子域名穿透出来的地址
openclaw config set gateway.controlUi.allowedOrigins "[\"https://openclaw.cpolar.top\"]" --strict-json

openclaw gateway restart

然后继续按照前面的流程：

填写网关 Token；
对新设备完成授权。

完成以后，就可以通过固定二级子域名继续访问 OpenClaw。

13. 公网开放 OpenClaw，最需要认真看的是权限边界

前面这些操作确实让 OpenClaw 的使用场景扩大了，但公网访问不是"地址能打开"就结束。

如果当前 OpenClaw 已经被授予文件读取、命令执行、桌面控制或其他高权限能力，那么：

网关 Token；
设备批准；
公网地址；
账号和系统权限；

都会直接影响访问边界。

所以我不会建议把 Token、授权信息或长期入口随意发到公开群组，也不会把"朋友能打开链接"默认等同于"适合共享整个 OpenClaw 控制界面"。

前面分享小游戏只是开放一个具体 Web 服务；而开放 OpenClaw 本身，权限范围明显更大，这两种场景需要分开看。

总结

这次真正让我觉得 OpenClaw"开始好用"的，不是单纯能在本地聊天，而是它可以把自然语言任务和已经存在的工具串起来。

这次实际跑通了四条比较具体的链路：

OpenList 公网访问 → AI 生成小游戏并分享 → Windows RDP 远程桌面 → OpenClaw 自身公网访问。

其中最完整的一条 OpenClaw 公网链路是：

OpenClaw 18789 → cpolar HTTP 隧道 → 随机公网 → gateway.controlUi.allowedOrigins → 网关 Token → openclaw devices approve → 正常对话 → 固定二级子域名 openclaw → 更新 allowedOrigins → 再次完成 Token / 设备授权。

几个边界值得一直记住：

OpenClaw 负责理解和执行任务，不等于它本身承担公网穿透；
cpolar 负责 Web / TCP 公网入口，不负责 OpenList、小游戏、RDP 或 OpenClaw 的业务逻辑；
外部能打开 OpenClaw 页面以后，仍然要经过 Origin、Token 和设备配对；
固定域名改变以后，对应的 allowedOrigins 也要使用新的域名；
页面里曾出现 astrbot-6185 与后续 openclaw 的隧道命名差异，真正复现时应以指向 18789 的实际隧道为准。

对我来说，这套组合最有意思的地方不是"AI 什么都能做"，而是很多原本要自己来回切工具的操作，可以先用一句自然语言把任务说明白，再看 OpenClaw 和具体工具各自把哪一部分做完。自动化越强，越要把工具职责和权限边界看清楚。