夜雨聆风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：从连通到无感常驻的实操手册》
