2026-05-06 OpenClaw 双网关：端口、OPENCLAW_STATE_DIR 与 nginx 上游灰度（租用 Apple Silicon 云 Mac，香港 / 东京 / 首尔 / 新加坡 / 美国）

不少团队希望在同一台租用的 Mac mini M4上并行两套 OpenClaw 网关：一套生产、一套灰度模型白名单，或 staging 与生产 Webhook 签名轮换节奏不同。若做错——端口重复、共用 ~/.openclaw、nginx 权重在请求中途抖动——会出现看似“模型挂了”的502 风暴，实则全是 plumbing。本 2026-05-06 指南按顺序讲清互不冲突的回环端口、彼此独立的 OPENCLAW_STATE_DIR 目录树、带 slow_start 的 nginx upstream，以及健康探测，让你在香港、东京、首尔、新加坡、美国机房间 drain 流量而不靠 SSH 临场发挥。衔接 nginx 反向代理与 Webhook 入口、健康探测与就绪、launchd 环境变量优先级，并在多仓读盘场景配合 文件工具与分块纪律，避免两套助手踩同一工作副本。

什么时候值得为复杂度买单

预算允许时优先第二台 Mac作旁路——见 定价 评估 witness 节点。若财务坚持单机，双网关仍有价值：

• 模型白名单在受监管流量与试验流量之间必须硬隔离。
• Webhook 签名密钥在 staging 与 prod 轮换周期不同。
• 无法做 CPU pinning，但仍希望灰度与生产会话的爆炸半径分开。

拓扑：并排 active/active 与主备

并排 active/active 适合你能随机化客户端或完全掌控 nginx 权重的场景；主备适合需要确定性排障、同一时间只有一套网关对共享 git 镜像做重度写操作的团队。把选择与 launchctl 标签写进同一份 README，避免交接时口头传说。

模式	优点	代价
Active / active	吞吐高；可在真实并发下 soak	需要幂等 Webhook 与去重副作用
Primary / standby	日志更简单；回滚路径短	备机闲置 CPU，除非跑合成探测

端口、绑定地址与 launchd 标签

不要只靠一次 lsof“猜端口”——写进 plist 与 nginx。示例（按你的语义化版本调整）：

export OPENCLAW_GATEWAY_PORT_PRIMARY=18789 export OPENCLAW_GATEWAY_PORT_CANARY=18890

两套都绑定 127.0.0.1，公网 0.0.0.0:443 交给 nginx。若灰度绑 ::1 而 upstream 只写 IPv4，会出现“幽灵连接重置”——地址族策略请对齐 出站 DNS/TLS 韧性 一文。

状态目录：为何禁止共用 ~/.openclaw

每套网关需要独立 OPENCLAW_STATE_DIR（例如 /var/lib/openclaw-prod 与 /var/lib/openclaw-canary）。共享主目录会在其中一套轮换 API key 时污染会话与缓存。若 launchd 用同一 UID 跑两套作业，也必须目录隔离——不要共享 sqlite 或会话根。

nginx upstream：权重、slow_start、max_fails

从 反向代理指南 复制已验证的 server 块，再复制 upstream：

upstream openclaw_primary { server 127.0.0.1:18789 max_fails=3 fail_timeout=20s; } upstream openclaw_canary { server 127.0.0.1:18890 max_fails=1 fail_timeout=10s slow_start=30s; }

用 split_clients 或与风险偏好一致的加权 proxy_pass。proxy_read_timeout 仍要对齐你允许的最长模型往返——拆网关不会缩短 LLM 延迟。reload 时记得 worker_connections 与 keepalive 池是 per-worker：upstream 翻倍却不抬上限，会在 Webhook 突发回放时顶满吞吐。能采集 stub_status 就采；否则从 access log 拆上游响应时间——若 reload 后 p95 立刻跳 35%+，多半是 worker 饿死而非 OpenClaw 配错。TLS 重负载时让 staging 与 prod 的 cipher 套件一致，避免灰度链 accidentally 走更慢路径。务必把可回滚的 nginx tarball与 OpenClaw 状态快照放一起；很多人只快照 Node 树不快照 nginx，两行 map $http_x_forwarded_proto 笔误会让两套网关一起 parser fail closed。

健康探测：切流量前先证明两套都绿

把 就绪探测 里的 curl 矩阵分别打到两个本机端口，reload 后再打经 nginx 的路径。HTTP 状态、上游连接耗时、TLS 握手耗时分开记日志，才能区分 nginx 回归与 OpenClaw 回归。

八步割接清单

1. 快照 plist、nginx 与两棵状态目录。
2. 安装第二套网关，二进制或 npm pin 与生产完全一致。
3. 分别在每棵树跑 openclaw doctor 独立校验。
4. nginx 先把灰度权重设为 0（就绪前黑洞）。
5. 用 staging 合成 Webhook 重放冒烟。
6. 把灰度切片调到 5–12%。
7. 观察 48h错误预算。
8. 按文档化权重晋升或回滚。

超时、Webhook 重试与重复投递

双网关放大重复投递风险：若上游在 TCP 空闲窗口内 aggressive 重试，业务必须识别幂等键，并把去重标记落在正确的状态目录下。proxy_read_timeout 要与供应商 idle 限制对齐——重试表见 Webhook 投递与签名。

SLO 信号	阈值	动作
本机上游连接 p95	> 120 ms	暂停调权；查 launchd 限流
5xx 占比	> 0.5%（15 分钟窗口）	灰度权重归零
队列积压	> 200 待处理作业	加第二台 Mac 或降并发，不要叠第三套网关

SLO：何谓“健康的双网关”

把双网关当成迷你服务网格：每一跳单独度量。若生产绿、灰度红，先修灰度配置，而不是盲调 nginx。对内面板建议每套网关四条线：进程 RSS、CPU%、nginx 日志里的在途 HTTP 数、失败上游连接数。同权重下若灰度 RSS 比生产偏离 18%+，多半是插件内存泄漏或 Node semver 不一致——暂停 rollout，对比两套 OPENCLAW_STATE_DIR 下 npm ls --depth=0。跳过这步的团队常把周末烧在“模型质量回退”上，实际是同一 skill bundle 在灰度被加载了两次。每季度演练整 nginx 挂掉：故意 stop nginx，确认 launchd 仍保活两套回环网关，并确认告警能叫到对的人——目标是双网关提高可用性，而不是让 pager 翻倍。

常见问题：TLS、DNS 与密钥

问题	实操答案（2026-05-06）
两套网关要两套 TLS 证书吗？	通常不需要——在 nginx 终结一次 TLS；网关只走回环。
API key 能共用吗？	不建议——独立轮换以缩小爆炸半径；模式见 网关升级与回滚。

为何裸金属 Mac mini M4 仍能简化双网关混乱

双网关同时压测 CPU、磁盘 与 launchd 台账。MacXCode 节点上带 1–2 TB NVMe 的租用 Mac mini M4 让 nginx→OpenClaw 回环延迟可预期，统一内存也足以并行两套 Node 图而不抢 nightly xcodebuild 邻居车道的核心。可预期性才是权重灰度“可度量”的前提。向运维解释为何需要专用第二节点而非在忙主机上叠第三套网关时，用 区域定价；需要在新 TLS 信任锚上走 VNC 证据链时，用 帮助文档 与 VNC 说明。