2026-05-06 OpenClaw デュアルゲートウェイ：ポート、OPENCLAW_STATE_DIR、nginx 上流ロールアウト（レンタル Apple Silicon クラウド Mac、HK / JP / KR / SG / US）
同一台レンタル Mac mini M4上で2 系統の OpenClaw ゲートウェイを走らせたいチームは多いです。本番の横でカナリアを置く、顧客 Webhook から切り離したステージングのモデル許可リストを持つ、といった用途です。誤った構成——ポートの衝突、共有の ~/.openclaw、リクエスト途中で変わる nginx の重み——はモデル障害のように見える502 の嵐を招きますが、実態は配管だけです。この 2026-05-06 のガイドでは、衝突しないループバック待受ポート、分離した OPENCLAW_STATE_DIR ツリー、slow_start 付きの nginx upstream、そしてヘルスプローブを順にそろえ、香港・東京・ソウル・シンガポール・米国で SSH ヒーロー頼みにせずトラフィックをドレインできるようにします。重なるリポジトリを読むエージェント向けには nginx と Webhook 入口、ヘルスプローブ、launchd の環境変数の優先順位、ファイルツールの規律に接続してください。
デュアルゲートウェイの複雑さに見合う場面
予算が許せば2 台目の Macを優先してください——witness ノード追加は 料金ページ を参照。1 台に縛られる場合でも、次のときはデュアル構成が役立ちます。
- 規制対象トラフィックと実験トラフィックでモデル許可リストが異なる。
- ステージングと本番でWebhook 署名シークレットのローテーション周期が違う。
- CPU ピニングは無いが、カナリアと本番セッションの間に爆発半径の壁が欲しい。
トポロジー：並列 active/active と primary/standby
並列 active/active はクライアントをランダム化できる、または nginx の重みを完全にコントロールできる場合に向きます。Primary/standby は決定的なデバッグが必要なチーム向けで、共有 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 キーを回したときの汚染キャッシュが起きます。launchd が両方のジョブに同じ UID を使うならディレクトリは必ず分離し、sqlite やセッションルートを共有しないでください。
rsync と launchctl kickstart であり、再インストール話ではありません。
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 遅延は縮みません。
nginx を reload するとき worker_connections と keepalive プールはワーカー単位であることを忘れないでください。upstream を倍にして上限を上げないと、Webhook バーストの再送で頭打ちになります。stub_status を取れるなら取得し、無ければ access log で upstream 応答時間を解析してください。reload 直後に p95 が 35% 以上跳ねたら、OpenClaw の設定よりワーカー飢餓を疑います。TLS 負荷が高いなら staging と prod の cipher を揃え、カナリア側だけ遅い経路を誤って有効にしないでください。
OpenClaw の状態スナップショットの横に、明示的なロールバック用 nginx tarball を文書化してください。Node ツリーだけスナップショットして nginx を忘れた運用者は、map $http_x_forwarded_proto の 2 行 typo がパーサ fail closed で両ゲートウェイを同時に壊すのを何度も踏みます。
ヘルスプローブ：トラフィック移動前に両方を緑にする
レディネスプローブと同じ curl 行列を両方のローカルポートに対して実行し、reload 後は nginx 経由でも打ちます。HTTP ステータス、upstream 接続時間、TLS ハンドシェイク時間を分けてログし、nginx 退行と OpenClaw 退行を切り分けます。
8 段階ロールアウトチェックリスト
- スナップショット plist、nginx、両状態ディレクトリ。
- インストール 第 2 ゲートウェイ（バイナリまたは npm pin は本番と同一）。
- 各ツリーで
openclaw doctorを独立検証。 - nginx でカナリア重み 0（準備完了までブラックホール）。
- ステージングから合成 Webhook リプレイでスモーク。
- カナリアスライスへ重みを上げる（5–12%）。
- 48h エラーバジェットを観測。
- 文書化した重みステップで昇格またはロールバック。
タイムアウト、Webhook 再試行、二重配送
デュアル構成は、上流が積極的に再試行すると二重配送リスクを増幅します。ハンドラが冪等キーを尊重し、正しい状態ディレクトリ配下に重複排除マーカーを置くようにしてください。proxy_read_timeout はプロバイダの TCP アイドル制限に合わせます——再試行表は Webhook 配送と署名 を参照。
| SLO シグナル | 閾値 | アクション |
|---|---|---|
| localhost への upstream 接続 p95 | > 120 ms | 重み変更を止め、launchd のスロットリングを調査 |
| 5xx 比率 | 15 分で > 0.5% | カナリア重みをゼロにドレイン |
| キュー滞留 | 保留ジョブ > 200 | 2 台目の Mac を足すか並行度を下げる——3 つ目のゲートウェイは積まない |
SLO 表：「健全なデュアルゲートウェイ」の意味
デュアルゲートウェイをミニサービスメッシュとして扱い、ホップごとに測定します。本番が緑でカナリアだけ SLO 違反なら nginx をいじる前にカナリア設定を直します。
社内ダッシュボードにはゲートウェイごとに4 本の線：プロセス RSS、CPU%、nginx ログ由来の処理中 HTTP 数、失敗した upstream 接続数。同じトラフィック重みでカナリア RSS が本番から 18% 以上乖離したら、プラグインのメモリリークか Node semver の不一致が多いです——ロールアウトを止め、各 OPENCLAW_STATE_DIR で npm ls --depth=0 を比較してください。この比較を飛ばすチームは週末を「LLM 品質劣化」追跡に費やしますが、実態はカナリアで同じ skill bundle が二重ロードだった、というパターンです。
四半期ごとにnginx 全停止をリハーサルしてください。意図的に nginx を止め、launchd が両ゲートウェイをループバックで生かしていること、インシデントボットが適切な人へページすることを確認します。目的は可用性向上であり、Pager が倍になることではありません。
FAQ：TLS、DNS、シークレット
| 質問 | 実務的な答え（2026-05-06） |
|---|---|
| ゲートウェイごとに TLS 証明書が要る？ | 通常は不要——nginx で一度終端し、ゲートウェイはループバックのみ。 |
| 両方で同じ API キー？ | 避ける——爆発半径を抑えるため独立ローテ。手順は アップグレードとロールバック を参照。 |
なぜ Mac mini M4 ベアメタルがデュアルゲートウェイの混沌をまだ単純化するか
デュアル構成は CPU・ディスク・launchd の台帳を同時に圧迫します。MacXCode ノードで 1–2 TB NVMe のレンタル Mac mini M4 は、nginx→OpenClaw のループバック遅延を予測可能にし、夜間 xcodebuild の隣レーンからコアを奪わずに 2 つの Node グラフを動かす統合メモリに余裕を残します。その予測可能性が重みベースのロールアウトを測定可能にします。すでに忙しいホストに 3 つ目のゲートウェイを積む代わりに専用の 2 ノード目を運用が求めたら リージョン別料金 を、新しい TLS 信頼アンカーを VNC で承認するブレークグラスは ヘルプ と VNC を併記してください。
