2026年 OpenClaw 远程 Mac 双机拓扑实战：
CALMVPS Gateway + 本地 macOS Remote 与 18789 隧道排障

很多团队已经能在本地 Mac跑通 OpenClaw，但真正上生产时卡在另一组问题：Gateway 想 7×24 挂在机房级裸金属上，而 Canvas、录屏、相机与 system.run 又必须留在带 TCC 权限的本地 Mac。2026 年官方 macOS 文档把这条路线明确为 Remote 模式——远端只跑 Gateway，本地启动 node host，控制面经 SSH 隧道或 Tailscale 走默认 18789 端口。本文给出可复现的双机拓扑、对照决策表、六步接入流程与报错速查，机型与节点以 CALMVPS 定价页为准。

读完你应能回答三件事：① 你的场景该继续 Local 单机还是切 Remote 双机；② Gateway 放在哪类 CALMVPS 节点、本地 App 如何切 Remote 并拉起 node host；③ 隧道失败、18789 占用或 Gateway 显示 node IP 为 127.0.0.1 时先看哪几条命令。

01 双机拓扑要解决什么痛点

把「所有能力堆在一台 Mac 上」在演示环境很顺滑，进入生产后常见三类隐性成本：

  • 算力与权限绑死：Gateway 长连接、Cron 与多通道会话吃 CPU/内存；同时本机还要开屏幕录制与自动化，16GB 机器在夜间批任务时容易交换，TCC 弹窗还会打断无人值守流程。
  • 网络出口不可控：家庭宽带或办公室 NAT 对 WebSocket 长连接不友好，Channel 离线常被误判成「模型故障」，排障方向一开始就偏了。
  • 运维边界模糊：本地睡眠、系统更新、Spotlight 索引与 launchd 守护叠在一起，很难区分是 Gateway 挂了还是 macOS 把进程挂起了。

Remote 双机拓扑的核心收益是职责拆分：远端裸金属 Mac（如 CALMVPS 香港/新加坡/美西节点）承担 Gateway、通道与调度；本地 Mac只作为带 UI/TCC 的 Node，通过 node host 把 Canvas、Camera、Screen 与 system.run 暴露给远端 Gateway。控制面仍走 18789，但由 macOS App 自动维护 SSH 控制隧道，不必手写一堆端口转发脚本。

选型口诀：「Gateway 上云、Node 留本地、控制面只走 18789」——先把拓扑画清楚，再谈 M4 档位与租期。

02 Local 单机 vs Remote 双机决策矩阵

不是所有团队都需要立刻上双机。下面用一张对照表把「继续 Local」与「切 Remote」的边界说清楚，便于评审会上一次性对齐。

OpenClaw Local 单机 vs Remote 双机（2026 生产视角）
维度 Local（Gateway 在本机） Remote（Gateway 在 CALMVPS 裸金属）
适用阶段 个人验证、单通道 Bot 7×24 通道、多 Agent、跨时区 Cron
本机职责 Gateway + Node 一体 仅 Node（TCC、Canvas、system.run）
远端职责 无 Gateway、launchd 常驻、日志落盘
控制面接入 127.0.0.1:18789 直连 SSH -L 或 Tailscale MagicDNS + App 隧道
典型风险 睡眠/更新打断、内存争抢 隧道健康、版本不对齐、Token 不同步
推荐租期 自有设备即可 Gateway 节点月/季租；本地无需增购

若你还需要多区域 Hub-and-Spoke（Gateway 在用户密集区、Worker 在次密集区），Remote 双机是前置条件；节点区域对照可参考站内 OpenClaw 远程 Mac 节点选型文，本文聚焦「一台远端 Gateway + 一台本地 Node」的最小可生产拓扑。

03 在 CALMVPS 裸金属上部署 Gateway

远端节点建议选与用户/通道出口最近的 CALMVPS 区域（香港、日本、韩国、新加坡、美东、美西），Gateway 仅监听 loopback，由 SSH 或 Tailscale 暴露控制面，避免把 Web UI 直接绑公网。安装命令以 OpenClaw 官方安装脚本为准（发版后请再次打开链接核对）：

https://openclaw.ai/install.sh

macOS 平台说明（Local/Remote 模式、launchd 标签 ai.openclaw.gateway）见官方文档：

https://docs.openclaw.ai/platforms/macos

REMOTE_GATEWAY_SETUP.SH 
# 在 CALMVPS 裸金属 Mac 上执行（示例）
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
openclaw gateway status
launchctl kickstart -k gui/$UID/ai.openclaw.gateway
# Gateway 默认 WS 端口 18789，建议仅绑定 127.0.0.1
  • Node 运行时：官方推荐 Node 作为 Gateway 运行时；裸金属上请固定主版本，避免 launchd 与交互 shell 各用一套 Node。
  • 状态目录：勿把 OPENCLAW_STATE_DIR 放在 iCloud 同步路径；推荐 ~/.openclaw，与 openclaw doctor 告警一致。
  • 磁盘预留：日志、Cron 历史与 Memory 落盘会持续增长；生产 Gateway 建议至少预留 80GB 专用于 OpenClaw 目录，必要时选 1TB/2TB 档位或并联资源拆队列。

04 本地 macOS App 切换 Remote 与 SSH/Tailscale 六步

本地 Mac 安装 OpenClaw.app 并完成 TCC 权限清单后，按下面六步切换到 Remote 模式（行为描述依据官方 macOS 文档，版本升级后请以文档为准）：

  1. 确认远端 Gateway 健康：在 CALMVPS 节点执行 openclaw gateway status，确保 18789 在 loopback 可探活。
  2. 准备 SSH 免密或密钥：本地 App 建立控制隧道时使用 BatchMode；为运维账号配置密钥登录，避免交互密码导致隧道半启动。
  3. （可选）接入 Tailscale：若团队已在 tailnet 内，优先用 MagicDNS 主机名发现 Gateway，tailnet IP 变化时比裸 IP 更稳。
  4. App 内切换 Remote 模式：在 OpenClaw.app 选择 Remote，填入远端主机；App 会复用或重建 ssh -N -L 18789:127.0.0.1:18789 形态的控制隧道，不在本机 spawn Gateway 子进程。
  5. 启动本地 node host：Remote 模式下 App 会启动 node host 服务，使远端 Gateway 能调用本机 Canvas、Camera、Screen 与 system.run（经 App 内 Exec approvals 策略）。
  6. 用调试 CLI 对照：在本地仓库 apps/macos 下可运行 swift run openclaw-mac connect --json 与 discover --timeout 3000 --json，与 App 同一套发现/握手逻辑对拍，快速区分「隧道问题」还是「Gateway 配置问题」。

macOS 远程访问专题（Direct ws/wss 与真实客户端 IP 上报）见：

https://docs.openclaw.ai/platforms/mac/remote

CONTROL_TUNNEL_MANUAL.SH 
# 手工验证控制隧道（与 App 行为一致，官方文档示例）
ssh -N -L 18789:127.0.0.1:18789 user@your-calmvps-node
curl -fsS http://127.0.0.1:18789/healthz
# 隧道走 loopback 时 Gateway 侧 node IP 可能显示 127.0.0.1；需真实 IP 时用 Direct ws/wss

05 18789 控制隧道与常见报错速查

双机拓扑里，80% 的「连不上」集中在控制隧道与版本对齐，而不是模型供应商。下面整理可引用的硬参数与报错对照。

  • 默认 Gateway WebSocket 端口：18789（官方 macOS 远程连接说明）；控制隧道本地端口与远端保持一致，App 会复用健康隧道而非随机本地端口。
  • LaunchAgent 标签：ai.openclaw.gateway（使用 OPENCLAW_PROFILE 时为 ai.openclaw.<profile>）；排障可用 launchctl kickstart -k gui/$UID/ai.openclaw.gateway。
  • Exec approvals 路径：本地 system.run 策略位于 ~/.openclaw/exec-approvals.json，与远端 Gateway 配置分离，迁移节点时勿漏备份。
Remote 双机常见现象与首选处理
现象 优先检查 首选修复
App 显示 Gateway 不可达 SSH 隧道是否存活、18789 是否被占用 重启 App 隧道；远端 lsof -i :18789 查冲突
健康检查 OK 但 Channel 离线 Gateway 与 CLI/App 版本是否一致 两端 openclaw --version 对齐后重启 Gateway
node IP 始终 127.0.0.1 是否经 SSH 隧道接入 预期行为；需真实 IP 时改 Direct ws/wss（见 remote 文档）
Canvas/相机无响应 本地 node host 是否运行、TCC 是否授予 Remote 模式下确认 node host；重走权限清单
Tailscale 发现失败 MagicDNS 是否启用、主机名是否变更 用 MagicDNS 名称重配；避免写死 tailnet IP

真实工作流案例：某 iOS 团队把 Gateway + Discord/Telegram 通道放在 CALMVPS 新加坡节点（月租 M4 24GB），本地 MBP 仅作 Node 跑 screen.record 与 Xcode 旁路脚本；高峰用并联资源加一台周租 Worker 跑批量构建，Gateway 不动，通道会话不中断。该拆法比「本地单机扛一切」更少夜间告警。

06 M4 档位、存储、租期与采购清单

双机拓扑下，资源配置要按角色而不是按「整机一刀切」：

  • 远端 Gateway（CALMVPS）：多通道 + Cron 建议 M4 24GB 起；Hub 节点或本地模型兜底选 M4 Pro；磁盘 1TB 验证、2TB 生产更省心。
  • 本地 Node Mac：以 TCC 与 UI 工具为主，16GB 通常够用；瓶颈多在权限与网络，而非 Gateway 算力。
  • 并联资源：一次性数据回灌或并行构建用日/周租 Worker，避免抬升 Hub 档位。
  • 租期组合：Gateway 节点月/季租锁算力，脉冲任务用日/周租并联，总成本往往低于单机顶配长线租用。

把 Gateway 留在个人笔记本或家庭 NAS 上，常见短板是长连接抖动、睡眠打断与无法审计的 Token 混用；纯云端 Linux VPS 又缺少 macOS TCC 与 Apple 工具链，Remote 双机里的「本地 Node」无法替代。对需要稳定 18789 控制面、跨区域裸金属与可复现排障的团队，CALMVPS 多区域裸金属 Mac更适合作为 Gateway 宿主：独占 Apple Silicon、7×24 在线、约 120 秒交付，配合 M4 Pro 与并联资源可在不升档的前提下吃下通道与会话尖峰。采购与节点列表见 CALMVPS 定价页。