OpenClaw 多节点运维：Token 持久化、Gateway 冲突排障
系列文章：本文是「OpenClaw + 基础设施」系列的第 3 篇。
本文记录 OpenClaw 多节点部署后的运维排障，重点包括 Gateway token 持久化、token_mismatch 导致的 Node 集体掉线、同机双 Gateway 冲突，以及 Clash Verge 截断 Tailscale 流量。当前拓扑为 Gateway Mac mini + Node Linux 工作站 + VPS；运行环境由 OpenClaw、ZeroClaw 和 Tailscale 组成，其中 Mac mini 同时也是 AI 助手 Jarvis 的核心入口。
当前需要稳定的运行态要素主要有四项：
- 谁负责生成和持久化 token
- 同一台机器上是否只保留一个 Gateway
- Tailscale 流量是否被本机代理改道
- 记忆文件中的拓扑描述是否仍然和真实环境一致
拓扑长什么样
我现在这套 OpenClaw 拓扑很简单：
- Mac mini，Tailscale IP 是
100.100.1.3，跑 OpenClaw Gateway，也是 AI 助手 Jarvis 的核心入口 - Linux 工作站，
100.100.1.5，一台 Dell Precision 7920，作为主要 Node - 香港 1C1G VPS，跑 ZeroClaw，也一度接成 OpenClaw 的 Node
- 所有设备通过 Tailscale 在同一个 Tailnet 里通信
之前还有一台 Vision，IP 是 100.100.1.6。后来这台机器退役了，但 OpenClaw 和 ZeroClaw 的记忆 markdown 里还留着它，后面专门清了一次。
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 不稳定”。其实都不是。它只是所有 Node 都在很一致地拿着过期凭证连接新的 Gateway。
一台机器两个 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 已经够了。
Tailscale 流量被代理截断
另一次故障的表象是 Linux 工作站连不到香港 VPS。因为对端在香港，第一反应很容易放在出口质量或者 VPS 本身状态上；但继续测试后可以很快排除这一点，因为别的设备可以访问，只有这台 Linux 工作站不通，说明问题只在本机。
最后定位到 Clash Verge。它接管了本机流量，但规则里没有对白名单放行 Tailscale 的 overlay 流量，结果发往 Tailnet 的连接也被代理截断了。表面现象是“Linux 到香港 VPS 不通”，真实原因却是“本机代理把内网叠加层一起拦了”。
把 Tailscale 流量加入 Clash Verge 白名单之后，连接立刻恢复。这件事的经验很直接：只要机器上跑了透明代理，排查 Tailnet 时就不能只看 tailscale status，还得看流量有没有在本机被改道。
Token 怎么固定
为了避免每次重启 Gateway 都让 Node 配置失效，后面需要把 Gateway token 固定下来。
这一步一开始也容易走错。我先在 shell 里试了：
OPENCLAW_GATEWAY_TOKEN=
openclaw config get gateway.auth.token结果当然没用。前一行只是把当前 shell 变量设空，不等于持久化配置；后一行返回的又是 __OPENCLAW_REDACTED__，根本看不到明文。这里需要区分两件事：一个是“当前 token 是什么”，另一个是“配置里怎么引用它”。
后来正确的做法是：
- 先用
openclaw dashboard --no-open拿到当前 Gateway URL，从里面的#token=取出明文 token - 把这个 token 写进
~/.openclaw/.env - 在 Gateway 侧把
gateway.auth.token设成${OPENCLAW_GATEWAY_TOKEN}，让服务重启后继续从环境变量读取 - 在各台 Node 侧也统一写同一个
OPENCLAW_GATEWAY_TOKEN，然后重启 Node 服务
这样之后，token 的唯一来源就收敛到了 .env，而不是每次由 Gateway 启动时临时生成。config get 继续返回 redacted 其实没问题，因为那只是出于安全考虑不显示明文，不代表配置没生效。固定完之后，dashboard 也不一定再把 token 直接拼进 URL，这反而是正常现象。
清理废弃节点的记忆
这个问题不直接导致服务故障，但会持续污染判断。Vision 这台设备早就下线了，IP 是 100.100.1.6，可 OpenClaw 和 ZeroClaw 的记忆 markdown 里还留着它的设备信息。
后果是 AI 助手在回答拓扑、节点数量和设备分工时，会把一台已经不存在的机器也算进去。系统本身没坏，但它对系统的“认知”已经过时了。
我最后做了两件事：
- 把活跃工作区里的 Vision 相关记忆清掉
- 单独整理一个
TOPOLOGY.md作为拓扑的单一事实源，别再让USER.md、MEMORY.md、维护日志各写一套
这种清理看起来不像传统运维，但对 AI 驱动的工具链来说其实很必要。过时的记忆文件，本质上也是一种配置漂移。
多节点 OpenClaw 的稳定性，核心取决于单一 Gateway、可持久化的 token，以及不会截断 Tailnet 的本机代理。把这三项固定下来之后，Gateway 重启、Node 重连和跨节点访问都会回到可预测状态。