OpenClaw 云服务器集成 Mac 和 Windows 节点：从连通到常驻，一次讲清楚

如果你想把 OpenClaw 真正跑成一套“云端 Gateway + 本地设备节点”的可用系统，这篇文章可以直接当成一份从安装到接入的实操路线图来看。

很多人装好 OpenClaw 之后，第一反应通常是：能聊天了，接下来是不是就差不多了？

其实不是。

如果你真的想把 OpenClaw 用进自己的日常工作流，单纯把 Gateway 跑起来，只能算第一步。真正能把它变成“系统”的，是你能不能把本地设备也接进来，让云端的大脑和你手边的机器协同工作。

而这也是很多人真正开始踩坑的地方。

尤其是当你的架构变成：

• 云服务器 跑 OpenClaw Gateway

• 本地 Mac 作为节点接入

• 本地 Windows 也作为节点接入

这时候最常见的问题就不再是“怎么安装”，而是：

• 怎么让它们连通

• 怎么让它们断了能恢复

• 怎么让它们重启后还能常驻

• 怎么知道到底是隧道挂了、token 错了，还是 node 自己没起来

这也是为什么我更愿意把这件事叫做“搭系统”，而不是“装工具”。

所以这篇文章不只讲“怎么配”，还会按一个更稳的顺序，把 云端 Gateway、Mac 节点、Windows 节点 三部分拆开讲清楚。

先看重点

• 整体架构：云服务器负责跑 Gateway，本地 Mac 和 Windows 通过 SSH 隧道连接云端。

• 关键原则：节点不是直接连公网 Gateway，而是先连各自本地的隧道端口。

• Mac 常见问题：免密没配好、隧道没常驻、launchd 没跑起来。

• Windows 常见问题：token mismatch、计划任务没常驻、PowerShell 策略拦住脚本。

• 建议顺序：先打通一台节点，再扩第二台，不要一开始 Mac 和 Windows 一起配。

一、你最终要搭出来的是什么架构

先不要急着写命令，先把目标架构看懂。

你最终要搭出来的，其实是这样一套关系：

• 云服务器（AWS / VPS）：运行 OpenClaw Gateway

• 本地 Mac：通过 SSH 隧道，把本地端口转发到云端 Gateway，再运行 openclaw node

• 本地 Windows：也是先建 SSH 隧道，再运行 openclaw node

一句话概括就是：

云端负责“大脑”，本地 Mac 和 Windows 负责“手脚”。

而节点连接的关键，不是直接去打云端公网端口，而是：

先连自己本地的隧道端口，再通过隧道转到云端 Gateway。

这一步如果一开始没想明白，后面很多报错看起来会很玄，其实只是链路理解错了。

二、先把云端 Gateway 跑稳，再谈节点

在你开始配 Mac 或 Windows 节点之前，必须先确认云端 Gateway 是稳定的。

至少要先确认这些：

• OpenClaw 已经装好

• Gateway 能正常运行

• 配置文件能正常读取

• 模型可用

• dashboard / Control UI 能打开

如果你连云端这一层都还没跑稳，就别急着配节点。因为节点一旦连不上，你根本分不清到底是云端有问题，还是本地有问题。

云端最基本的检查

先看 Gateway 状态：

 openclaw gateway status  

再看整体状态：

 openclaw status  

查看健康情况：

 openclaw health  

如果你只是想先确认 Gateway 已经起来，最重要的就是把这一层先跑通。节点接入一定是第二阶段，不要倒过来。

三、Mac 节点：最容易踩坑的，其实不是 node，而是 SSH 隧道

很多人以为 Mac 节点连不上，是 openclaw node 自己的问题。实际上，在“云端 Gateway + 本地 Mac”这种架构里，最容易出问题的往往不是 node，而是 SSH 隧道。

你可以先把 Mac 这条链路理解成这样：

1. Mac 本地先建立 SSH 隧道

2. 本地端口 127.0.0.1:18790 转发到云端 127.0.0.1:18789

3.openclaw node 连接的是 Mac 本地的 18790，不是公网地址

这点非常重要。

第 1 步：先把 SSH 免密配好

这一条是必须的。因为如果你后面要用 launchd 把隧道做成常驻，后台进程不可能等你手动输入密码。

在 Mac 上生成密钥：

 ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""  

安装公钥到云服务器：

 ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<你的云服务器IP>  

验证免密：

 ssh -o BatchMode=yes -i ~/.ssh/id_ed25519 root@<你的云服务器IP> "echo ok"  

看到 ok 才算真正成功。

第 2 步：在 Mac 写 SSH 配置

推荐把常用参数直接写进 ~/.ssh/config，这样后面隧道和常驻会稳定很多。

核心思路是：

• 目标主机固定成一个别名

• 本地转发 18790 -> 云端 18789

• 保持连接活跃

第 3 步：先手动验证隧道

在 Mac 上执行：

 ssh -N remote-gateway  

这个命令会占住终端，是正常现象。另开一个终端检查本地 18790 是否在监听：

 lsof -nP -iTCP:18790 -sTCP:LISTEN  

如果能看到监听，就说明隧道这一步是通的。

第 4 步：安装 Mac node 服务

在 Mac 上执行：

 openclaw node install --force --host 127.0.0.1 --port 18790 --display-name "Master-Mac"  

然后重启 node：

 openclaw node restart  

查看状态：

 openclaw node status  

这里最关键的是：

• --host 127.0.0.1

• --port 18790

只要这两个没对上，后面大概率就会出现 ECONNREFUSED 这类错误。

第 5 步：把隧道做成常驻

如果你希望 Mac 节点长期在线，单纯手动开一个终端跑隧道是不够的。更稳的方式是用 launchd 做常驻。

核心思路很简单：

• 写一个 LaunchAgent

• 开机或登录后自动启动 SSH 隧道

• 隧道断了之后自动拉起

可选：直接用一键脚本把 Mac 节点跑起来

如果你不想手动一条条敲命令，也可以直接用一键脚本把 SSH 配置、隧道常驻、Node 服务安装与重启 一次做完。

你只需要先把脚本顶部这两个参数换成自己的：

• AWS_IP

• AWS_USER

然后在 Mac 上执行：

 bash ~/openclaw_mac_node_setup.sh  

这个脚本做的事情，本质上就是把前面几步自动串起来：

• 生成或复用 SSH key

• 验证 / 配置 SSH 免密

• 写入 ~/.ssh/config

• 生成 tunnel 的 LaunchAgent

• 安装并重启 openclaw node

• 做一轮基础自检

如果你的目标是“尽快把 Mac 节点稳定跑起来”，这类脚本会比手动逐条操作更省心。

但要注意两点：

• 第一次跑之前，最好先自己看一遍脚本内容

• 先确认云端 Gateway 已经正常运行，不要在云端还没稳的时候就直接跑自动化脚本

如果脚本跑完后，你还想确认是否真的接通，最直接的方式是回到云端执行：

 openclaw nodes status  

以及：

 openclaw nodes run --node Master-Mac -- sw_vers  

只要这两步正常，说明 Mac 节点这条链路已经基本打通了。

Mac 最常见的坑

• ECONNREFUSED 127.0.0.1:18790

• 免密没配好，后台 SSH 起不来

• 端口 18790 被旧进程占用

• Node 服务还在，但隧道实际上已经断了

如果你在 Mac 上只想抓一个关键点记住，那就是：

先看 18790 有没有监听，再看 node 状态。

不要一上来就怀疑 OpenClaw 本身。

四、Windows 节点：真正麻烦的，通常是 token 和常驻

Windows 节点的逻辑和 Mac 一样，也是先通过 SSH 隧道连接云端 Gateway，再让 openclaw node 连接本地隧道端口。

但 Windows 这条线跟 Mac 最大的不同在于：

• 它更容易卡在 PowerShell 执行策略

• 更容易卡在计划任务常驻

• 更容易出现 gateway token mismatch

所以 Windows 的重点，不只是“连通”，而是“能不能稳定常驻”。

第 1 步：先确认 PowerShell 环境没拦你

如果 PowerShell 默认策略太严，有些脚本就算你写对了也跑不起来。

可以先执行：

 Set-ExecutionPolicy -Scope CurrentUser RemoteSigned -Force  

然后确认 OpenClaw CLI 正常：

 openclaw --version  

第 2 步：配置 SSH 免密

Windows 这一步和 Mac 的思路一样。

生成密钥：

 ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\id_ed25519 -N ""  

然后把公钥追加到云服务器的 authorized_keys。

验证免密：

 ssh -o BatchMode=yes -i $env:USERPROFILE\.ssh\id_ed25519 root@<你的云服务器IP> "echo ok"  

第 3 步：先手动把隧道打通

在 Windows 上执行：

 ssh -N -L 18790:127.0.0.1:18789 remote-gateway-win  

然后在另一个 PowerShell 窗口验证：

 Test-NetConnection 127.0.0.1 -Port 18790  

如果 TcpTestSucceeded : True，说明隧道链路没问题。

第 4 步：安装 Windows node 服务

在 Windows 上执行：

 openclaw node install --force --host 127.0.0.1 --port 18790 --display-name "Master-Win"  

然后重启：

 openclaw node restart  

查看状态：

 openclaw node status  

第 5 步：重点处理 token mismatch

Windows 节点最常见的一个错误，是：

unauthorized: gateway token mismatch

这说明 Windows 节点本地记录的 token，和云端 Gateway 当前 token 不一致。

这类问题最烦的地方在于：表面看像网络问题，实际上是认证问题。

所以如果你看到这个报错，不要在隧道上浪费太多时间，优先去对 token。

第 6 步：把隧道和 node 都做成常驻

Windows 上最稳的方式通常是：

• 用计划任务常驻 SSH 隧道

• 再用计划任务常驻 node 进程

这样重启之后，它还能尽量自动恢复。

可选：把 Windows 这一套也做成“一键常驻”

如果你不想在 Windows 上手动一步步建隧道、建计划任务、重启 node，也可以把这些动作收敛成一套固定脚本来执行。

这类脚本的目标不是“帮你少敲几条命令”这么简单，而是把 Windows 节点最容易出问题的三件事一次处理掉：

• SSH 隧道是否真的起来

• OPENCLAW_GATEWAY_TOKEN 是否和云端一致

• 计划任务能不能在重启或登录后自动恢复

如果你已经把：

• PowerShell 执行策略

• SSH 免密

• 隧道手动连通

这些步骤都验证过一遍，那么后面再把它们做成脚本化流程，会比长期手动维护稳定得多。

Windows 这一侧更适合脚本化的地方主要是：

• 注册 SSH 隧道计划任务

• 注册 node 常驻计划任务

• 设置或更新 Gateway token

• 跑完后做一轮本地连通性检查

如果脚本跑完后，你想确认 Windows 节点是不是真的在线，最直接的方式还是回云端执行：

 openclaw nodes status  

以及：

 openclaw nodes run --node Master-Win -- "hostname && whoami"  

只要这两步正常，说明 Windows 这一侧的“连通 + 常驻 + token”三件套就基本到位了。

Windows 最常见的坑

• gateway token mismatch

• 计划任务看起来存在，但实际上没跑起来

• 隧道没起，Test-NetConnection 18790=False

• 模式: 就绪 一直不变，任务启动后立刻退出

• OpenClaw 装好了，但脚本策略把执行给拦了

如果你在 Windows 这条线上只记一个重点，那就是：

先检查 token，再检查隧道，再检查计划任务。

顺序反了，很容易越查越乱。

五、云端怎么验收 Mac 和 Windows 节点都在线

本地配置完之后，最终还是要回到云端看结果。

在云服务器上，你至少要做三类检查：

1）看有没有待审批节点

 openclaw nodes pending  

首次接入时，通常需要审批。

2）批准节点

 openclaw nodes approve <requestId>  

3）看节点状态

 openclaw nodes status  

理想情况下，你会看到：

• Master-Mac paired · connected

• Master-Win paired · connected

4）做远程执行验收

测试 Mac：

 openclaw nodes run --node Master-Mac -- sw_vers  

测试 Windows：

 openclaw nodes run --node Master-Win -- "hostname && whoami"  

只要这两条都跑通，说明这套“云端 Gateway + 本地双节点”的架构已经基本成型了。

六、为什么我建议你别一开始就同时配两台节点

很多人会觉得，既然我最后就是要连 Mac 和 Windows，那不如一开始一起配。

但实际经验是：

• 这样做并不会更快

• 只会让问题更难定位

因为一旦两边都没连上，你会同时怀疑：

• 云端 Gateway

• SSH 免密

• 隧道

• token

• 常驻服务

• 计划任务

• launchd

这时候几乎没有排查效率可言。

更稳的方式是：

1. 先配通 Mac 或 Windows 其中一个

2. 确认整条链路真正在线

3. 再用同样的思路扩第二台

只要第一台跑通，第二台其实就只是“复制一条已经验证过的方法”，而不是从零重新试错。

写在最后

如果你只是把 OpenClaw 装起来，它其实还只是一个能跑的系统。

但当你把云端 Gateway、Mac 节点、Windows 节点真正连起来之后，它才开始变成一个更完整的工作流基础设施。

这也是为什么我会建议你，把这件事看成“搭系统”，而不是“装工具”。

工具装上就结束了；系统搭起来之后，才会在你每天的工作里持续发挥价值。

所以更稳的思路始终是一样的：

先把云端跑稳，再接一台节点；先把一台节点跑稳，再扩第二台。

只要你按这个节奏来，这件事其实没有看起来那么复杂。

如果你接下来准备先把 Mac 节点 单独打通，我建议继续看下一篇更细的实操手册：

《OpenClaw 云端 Gateway + 本地 macOS Node：从连通到常驻的完整实操手册》

那一篇会把 SSH 免密、隧道常驻、一键脚本、验收和常见报错展开得更完整。如果你准备接的是 Windows 节点，我也写了一篇对应的：

《OpenClaw 云端 Gateway + 本地 Windows Node：从连通到无感常驻的实操手册》