Clawdbot 多端配对实录：用 Tailscale Serve 暴露 Gateway 并接入 Node

2026年1月29日 | Ruichen Zhou | 约 9 分钟阅读

TailscaleClawdbot

要解决的问题与适用场景

这篇文章记录我部署 Clawdbot 多端配对的过程：在服务器上跑 Gateway，用 Tailscale Serve 暴露到 Tailnet，再把桌面端的 Node 配对接入。最终效果是可以在 Tailnet 内远程管理机器、执行命令。

适用场景：

想用 Clawdbot 远程管理一台机器
希望访问入口收敛在 Tailnet 内，不对公网暴露
需要多端接入并用 UI 审批配对与执行策略

背景与环境

本次部署信息：

Clawdbot：2026.1.24-3
Gateway 端口：18789，绑定 127.0.0.1（loopback）
Tailscale Serve：暴露 https://<machine>.ts.net:18789/（tailnet only）
Node 端：桌面机上以 systemd user service 方式运行

在服务器端部署 Gateway

启动 Gateway：loopback + token

在 Clawdbot 的 onboarding 中，我选了这些配置：

端口：18789
bind：Loopback (127.0.0.1)
auth：Token

选 loopback 的原因是 Gateway 不直接对公网暴露，后续让 Tailscale 负责远程入口。token 提供最基本的鉴权。

启动后可以用 curl 验证 HTTP 可用：

curl -I http://127.0.0.1:18789/ | head -n 1
# 预期：HTTP/1.1 200 OK

也可以确认端口监听：

sudo ss -ltnp | grep 18789
# 预期：127.0.0.1:18789 被 clawdbot-gateway 监听

用 Tailscale Serve 暴露到 Tailnet

接下来用 tailscale serve 把 loopback 的 Gateway 以 HTTPS 形式发布到 Tailnet。

我踩过一个坑：直觉上以为 tailscale serve tcp 18789 ... 或 tailscale serve 18789 ... 能用，但参数格式不对，会报 invalid number of arguments。实际可用的命令形态是：

sudo tailscale serve --bg --https=18789 127.0.0.1:18789

执行成功后，Tailscale 会输出 tailnet only 的访问 URL：

Available within your tailnet:
https://<machine>.ts.net:18789/
|-- proxy http://127.0.0.1:18789

确认状态：

sudo tailscale serve status

这样 Tailnet 内的设备就可以通过 https://<machine>.ts.net:18789/ 访问 Control UI 和 wss，避免了公网开端口、配置反向代理、处理 TLS 证书的额外复杂度。

在桌面端部署 Node 并完成配对

安装并启动 Node

在桌面机上安装 Node host，以 systemd user service 方式运行。关键参数：

--host <machine>.ts.net
--port 18789
--tls（对应 wss/https）
--display-name <name>（便于识别）

clawdbot node install

# 查看状态
systemctl --user status clawdbot-node.service --no-pager
journalctl --user -u clawdbot-node.service -n 200 --no-pager

首次连接时，Node 日志会出现：

pairing required
gateway closed (1008): pairing required

这其实不是网络问题——它说明链路和鉴权都已经通了，只是 Gateway 侧还没批准配对。

在 UI 批准配对

进入 Gateway 的 Control UI（本机 127.0.0.1:18789 或 tailnet 域名都行），在 Nodes 页面批准 Node 的配对请求。

批准后：

Gateway 侧：clawdbot nodes pending 显示 No pending pairing requests.
UI 侧：Node 状态从 pending 变为 paired / connected
Node 侧：systemd service 不再频繁重启，稳定 active (running)

配置 Exec approvals（命令白名单）

远程执行命令默认需要审批，频率太高会影响可用性。我的做法是在 UI 配置 allowlist，把常用的低风险命令加入白名单。

配置入口：

Control UI → Nodes → Exec approvals
选择目标（Host / Node），再选 Scope（Defaults / main）
在 Allowlist 添加 pattern，保存

备注：我试过用 clawdbot config set system.execApprovals... 写入配置，但遇到 schema 校验失败（Unrecognized key: "system"）。最后发现当前版本的 CLI 不支持这个路径，用 UI 配置更稳定。

验证方式是触发一个被加入 allowlist 的命令，看是否还弹审批。配置会写入 ~/.clawdbot/exec-approvals.json。

其他踩过的坑

Gateway 端口被占用导致重启风暴

一度我的 Gateway 日志反复出现：

gateway already running (pid XXXXX)
Port 18789 is already in use
systemd restart counter 持续增加

原因是同一台机器上有一个手动启动的旧进程在监听 127.0.0.1:18789，同时 systemd 又尝试启动新的 Gateway 实例。

解决方法是统一监管者：要么保留现有进程并关闭 systemd，要么停掉旧进程让 systemd 接管。关键验证：

sudo ss -ltnp | grep 127.0.0.1:18789
# 确认只有一个 clawdbot-gateway 监听

Gateway 调用 tailscale serve 权限不足

Gateway 日志里出现过 serve config denied / Use 'sudo tailscale serve...'。原因是 Gateway 以普通用户运行时没权限写入 tailscaled 的 serve 配置。

我的处理方式是在外部用 root 单独运行 tailscale serve ...，Gateway 只负责本机 loopback 监听。

小结

这次部署最终达成了三件事：

Gateway 绑定 loopback，通过 Tailscale Serve 提供 Tailnet 内的 HTTPS 入口，避免了公网端口管理和 TLS 证书的额外工作
桌面端 Node 配对成功，可以在 UI 审批并管理多端接入
通过 UI 配置 Exec approvals allowlist，减少日常命令的重复审批

几个教训：

Node 报 pairing required 时优先判断这不是网络问题，往往只差 UI 上的批准
同一服务只留一个监管者（手动进程 or systemd），否则端口占用会导致重启风暴
CLI 改配置不一定比 UI 稳定，对 schema 校验严格的工具，优先用官方 UI