2026 Mac VPS で Docker の OpenClaw：Gateway Token、CLI コンテナネットワークとペアリングデッドロック Runbook
ノート PC から同じ Compose を無人の Mac VPS に移すと、token mismatch、1008 pairing required、CLI が 127.0.0.1:18789 で失敗しがちです。openclaw-gateway と openclaw-cli を別コンテナに分けるチーム向けに、五つの根因、症状トリアージ表、監査可能な五手順 Runbook（トークン凍結、二重ソース整合、名前空間修正、ペアリング脱出、launchd 連携のヘルスチェック）、および本サイトの Compose 7×24 とゲートウェイ ladder 記事へのリンクをまとめます。
目次
1. 痛点：二重トークン、ループバック、ペアリング、bind、uid
公式フローは同一ネット名前空間でのオンボーディング前提。無人 Mac VPS では次の五類型に収束します。
- 環境変数の静かな上書き：
OPENCLAW_GATEWAY_TOKENがgateway.auth.tokenを上書きし UI と実体が不一致。 - CLI ループバック：既定
ws://127.0.0.1:18789はCLI コンテナ自身。ECONNREFUSED/1006が出やすい。 - ペアリングデッドロック：
gateway.bind=lanで相互承認待ち、手順なしだと1008。 - bind とブリッジ：
loopbackと横断が両立しにくい。lanへ切替後も CLI URL 未更新だと listen ログだけ残る。 - uid ズレ：多く uid 1000。root 生成パスは永続化とトークン混乱を招く。
無人 Mac VPS ではログがそのまま真実です。docker compose logs -f openclaw-gateway と CLI を同一タイムラインで読み、digest 固定時は変更票に digest とトークン先頭 8 文字を併記してください。ダッシュボードを外向きにする場合はゲートウェイ露出のハードニング記事も併読します。
2. トリアージ表：症状・根因・最初のコマンド
インシデント票に貼れる表です。ポリシー化時は露出面ハードニング記事と併読。
| Symptom | Likely cause | First action |
|---|---|---|
| token mismatch / unauthorized | env と json の不一致 | リポジトリとマウント双方を grep；setup 再実行前に hex を固定 |
| 127.0.0.1:18789 refused | CLI がゲートウェイと分離 | network_mode: service:openclaw-gateway か GATEWAY_URL をサービス名へ |
| 1008 pairing loop | 相互承認待ち | openclaw dashboard --no-open の後 devices list / devices approve、ログ断片をチケットに添付 |
| ヘルスが不安定 | プロセスのみのプローブ | 実リスナーで /healthz と /readyz を HTTP 確認 |
| 書き込みが戻る | マウントまたは権限 | VPS 実ディスクの bind を確認；データdirで chown -R 1000:1000 |
OPENCLAW_GATEWAY_TOKEN=$(openssl rand -hex 32) を export し、同一文字列を .env と gateway/CLI に書きオンボーディングでもそれだけ貼る。インシデント中に第二トークンを自動生成させない。
「両方 grep」はリポジトリ検索に加え、docker compose exec で各コンテナの openclaw.json と compose env を突き合わせるまで完了とみなしません。シークレットマネージャは実行時解決値を確認。1008 でダッシュボードと CLI の pending 表示が非対称なら GATEWAY_URL やクッキー分断を疑います。
3. 五手順 Runbook：オンコール検収まで
- 秘密の凍結：変更票にトークン先頭 8 文字と digest。
- 二重ソース：
compose up前にgateway.auth.tokenとOPENCLAW_GATEWAY_TOKENを各定義で突合。 - 名前空間：CLI は
network_mode: service:openclaw-gateway優先。ブリッジならGATEWAY_URL=ws://openclaw-gateway:18789と DNS 検証。 - ペアリング：ゲートウェイで
dashboard --no-open、CLI でdevices approve、手順をチケット化。 - プローブ：ホスト curl
/healthz・/readyzを plist に写す。上限は Compose 7×24 記事参照。
最小 Compose スケッチ（本番は上流テンプレとマージ）：
network_mode が使えない場合は内部 URL を明示し、捨てコンテナで healthz を wget/curl して DNS 綴りを確認。デバイス行削除はログ保全の後に限ります。
4. 引用用ファクト：ポート、uid、プローブ
- ポート：既定リスナー
18789。ヘルススクリプトはdocker psだけでなく実リスナーを叩く。 - UID：node ユーザーは多くの場合 uid
1000。ホスト bind を揃えないと永続化が静かに失敗する。 - プローブ：
/healthzを liveness、/readyzを WS 受け入れ準備に近い readiness として扱い、順序とタイムアウトを Runbook に明記。 - 時刻同期：ホストとコンテナの大きなズレは単体では WS を壊しにくいが証明書やログ相関を乱す。NTP を健全に保つ。
- アップグレード窓：イメージ更新時は五手順チェックリストを成功宣言の前に再実行。
docker psが通っても認証済み CLI セッションと同義ではない。
5. Compose 7×24 とネイティブゲートウェイ記事の読み順
まず Compose 7×24、続けて ゲートウェイ install/bind/auth Runbook。ノートの ad-hoc docker run は無人 VPS ではトークンとペアリング欠陥を隠します。長期エージェント向けに専用 Apple Silicon・固定出口・並列の見通しが欲しければ VPSMAC M4 Mac クラウド が運用一本化に向きます。自動化導線は 90 秒 API ガイドを参照。