返回博客列表

OpenClaw 多节点运维：Token 持久化、Gateway 冲突排障

2026年3月20日| 更新于 2026年8月1日| Ruichen Zhou| 约 8 分钟阅读
OpenClawTailscale运维排障

历史说明（2026-08-01）：本文是 2026 年 3 月的历史记录，写的是当时那套 OpenClaw 多节点部署的排障过程（Gateway 在 Mac mini，Node 是实验室 Linux 工作站和一台香港 VPS）。后来的告警诊断换成了另一个项目 hermes-agent，两者不是同一个项目，现状见《服务器报警了不用我爬起来查》。正文按当时状态保留。

2026 年 3 月，OpenClaw 多节点部署跑起来之后，接连处理了四个问题：Gateway token 持久化、token_mismatch 导致的 Node 集体掉线、同机双 Gateway 冲突、Clash Verge 截断 Tailscale 流量。拓扑是 Gateway Mac mini + Node Linux 工作站 + VPS，运行环境由 OpenClaw、ZeroClaw 和 Tailscale 组成，Mac mini 同时是 AI 助手 Jarvis 的入口。

1. 拓扑长什么样

当时这套拓扑很简单：

  • Mac mini，跑 OpenClaw Gateway，也是 AI 助手 Jarvis 的入口
  • Linux 工作站，一台 Dell Precision 7920，作为主要 Node
  • 香港 1C1G VPS，跑 ZeroClaw，也一度接成 OpenClaw 的 Node
  • 所有设备通过 Tailscale 在同一个 Tailnet 里通信

之前还有一台 Vision，后来退役了，但 OpenClaw 和 ZeroClaw 的记忆 markdown 里还留着它的设备信息，后面专门清了一次。

2. Node 集体掉线

Gateway 重启后，Linux 工作站和 VPS 两台 Node 同时离线。这个现象很容易先怀疑 Tailscale 或 VPS 本身，但两个 Node 在 Gateway 重启后同时失联，时间点过于一致，更像是 Gateway 侧的统一问题，而不是链路抖动。

翻 Gateway 日志，信息很直接：

reason=token_mismatch
unauthorized: gateway token mismatch (provide gateway auth token)

问题不在链路，在鉴权。表面上是 Node 一起掉线，实际上是 Gateway 重启后重新生成了 token，而 Node 端仍拿着旧 token，全部认证失败。这类故障很容易误判成“Node 自己挂了”或“Tailnet 不通”，其实都不是。

3. 一台机器两个 Gateway

Mac mini 上随后出现另一个问题：OpenClaw 一直报告检测到了别的 gateway-like service。日志如下：

Other gateway-like services detected (best effort):
- ai.openclaw.mac (user, plist: /Users/ruichen/Library/LaunchAgents/ai.openclaw.mac.plist)
Recommendation: run a single gateway per machine for most setups.

排查后确认，/Applications/OpenClaw.app 不只是桌面管理界面，还会自动注册一个 LaunchAgent。同一台机器上于是同时存在两个 Gateway：

  • 手动安装和管理的 ai.openclaw.gateway
  • OpenClaw.app 自己带起来的 ai.openclaw.mac

两个实例都会尝试接管端口、状态和服务生命周期，表现为端口和状态竞争、日志反复告警、Gateway 行为不可预测。

处理不是判断“哪个进程更对”，而是只保留一个监管者：保留手动配置的 Gateway，把桌面应用自动注册的 LaunchAgent 清掉。对个人部署来说，一台机器跑一个 Gateway 就够了。

4. Tailscale 流量被代理截断

另一次故障的表象是 Linux 工作站连不到香港 VPS。因为对端在香港，第一反应容易放在出口质量或 VPS 状态上；但别的设备都能访问，只有这台工作站不通，说明问题只在本机。

最后定位到 Clash Verge。它接管了本机流量，但规则里没有放行 Tailscale 的 overlay 流量，发往 Tailnet 的连接也被代理截断了。表面是“Linux 到香港 VPS 不通”，实际是本机代理把内网叠加层一起拦了。

把 Tailscale 流量加入 Clash Verge 白名单后，连接立刻恢复。之后的经验：只要机器上跑了透明代理，排查 Tailnet 就不能只看 tailscale status，还得看流量有没有在本机被改道。

5. Token 怎么固定

为了让 Gateway 重启不再让 Node 配置失效，需要把 token 固定下来。

这一步一开始走过弯路。我先在 shell 里试了：

OPENCLAW_GATEWAY_TOKEN=
openclaw config get gateway.auth.token

前一行只是把当前 shell 变量设空，不等于持久化配置；后一行返回的又是 __OPENCLAW_REDACTED__，看不到明文。这里要区分两件事：一个是“当前 token 是什么”，另一个是“配置里怎么引用它”。

正确的做法是：

  1. 用 openclaw dashboard --no-open 拿到当前 Gateway URL，从里面的 #token= 取出明文 token
  2. 把这个 token 写进 ~/.openclaw/.env
  3. 在 Gateway 侧把 gateway.auth.token 设成 ${OPENCLAW_GATEWAY_TOKEN}，让服务重启后继续从环境变量读取
  4. 各台 Node 侧统一写同一个 OPENCLAW_GATEWAY_TOKEN，然后重启 Node 服务

这样 token 的唯一来源收敛到 .env，不再由 Gateway 启动时临时生成。config get 继续返回 redacted 没有问题，那只是安全考虑不显示明文，不代表配置没生效。固定完之后，dashboard 不再把 token 直接拼进 URL，这也是正常现象。

6. 清理废弃节点的记忆

这个问题不直接导致服务故障，但会持续污染判断。Vision 这台设备早就下线了，可 OpenClaw 和 ZeroClaw 的记忆 markdown 里还留着它的设备信息。后果是 AI 助手在回答拓扑、节点数量和设备分工时，会把一台已经不存在的机器也算进去——系统本身没坏，但它对系统的“认知”已经过时。

处理是两件事：

  • 把活跃工作区里 Vision 相关的记忆清掉
  • 单独整理一个 TOPOLOGY.md 作为拓扑的唯一参考，不再让 USER.md、MEMORY.md、维护日志各写一套

对 AI 驱动的工具链来说，过时的记忆文件也是一种配置漂移。

评论