2026年版 OpenClaw Gateway ペアリングとトークン衝突の実務:onboarding 停滞、1006/1008、環境変数が設定を上書きするときの段階チェックリスト

読了目安 約 15 分 · MACCOME

想定読者:Docker またはローカルで OpenClaw を入れたあと、初回ペアリング・onboarding・コンテナ内実行で openclaw CLI が WebSocket 1006/1008 を繰り返したり、token mismatch が出て設定ファイルを直しても直らない場合です。結論:環境変数の上書きCLI が実際に接続する ws URLペアリング状態機械を一枚の対照表に揃え、そのうえで openclaw doctor と Docker ネットワーク稿をつなぎます。構成:六つの誤読、症状マトリクス、指紋コマンド、六段 Runbook、三 KPI、ホスティングの収束です。

なぜ gateway.auth.token を変えても mismatch が残るのか:六つの典型誤読

2025–2026 のコミュニティ切り分けでは、OpenClaw Gateway のペアリングと認証が「ネットワーク不通」と混同されがちです。ログに切断コードとモデルエラーが同居すると、上流 LLM 障害と決めつけてしまいます。次の六つは当番で寄り道しやすいパターンなので、インストール後の doctor と Gateway ヘルスと並べて Wiki の表紙に貼ってください。

  1. OPENCLAW_GATEWAY_TOKEN が設定ファイルを黙って上書きする:コンテナや launchd ユニットから注入された環境変数の方が優先され、ディスク上の gateway.auth.token は変えたのにプロセスは古い値を読み、「再起動しても mismatch」のように見えます。
  2. コンテナ内 CLI が既定で 127.0.0.1 を向く:Compose で CLI の Gateway URL を openclaw-gateway サービス名に向けていないと、ハンドシェイク早期に失敗し、アプリ層のエラーなしに 1006/1008 だけが残り、Docker ネットワーク切り分けチェックリストと症状が重なります。
  3. ペアリングが終わる前に重いジョブを走らせる:明示確認や状態書き込みが必要な onboarding 手順を、スクリプト化パイプラインが飛ばすと、Gateway はListenしていてもセッション層が未準備になり、CLI からは「たまに繋がってすぐ切れる」ように見えます。
  4. 設定パスの二重化:ユーザーホームとプロジェクト直下にそれぞれ .openclaw 相当があり、CLI が読むパスとエディタで開いているファイルが一致しません。
  5. CI シークレットに古い token が残る:Gateway token ローテ後に GitHub Actions / GitLab CI の変数が未更新で、夜間ジョブが誤 token をログに流し、本来直すべき Runner ラベル問題を隠します。
  6. 1006 をすべて「一瞬のネットワーク」扱いする:「プロトコル上の正常終了」と「認証/サブプロトコル失敗」を分けず、ネットワーク稿と本稿の間を往復して収束しません。

公式インストールスクリプトと npm グローバル経路との関係:インストール稿は「バイナリと Node が PATH に乗る」ことを保証し、本稿は「CLI と Gateway が同一 token・同一 ws エンドポイントで話す」ことを保証します。同一の初日 Runbook に順番付きで載せます。

表 1:症状 → まず疑うスタック → 次の一手(先にペアリング、次にネットワーク、最後にモデル)

このマトリクスは初動の一次切り分け用です。行に当てはまったら、そのチェックを「再現可能なコマンド出力」まで落としてから次へ進み、token・Compose・リバプロを同時にいじらないでください。

表面症状優先して疑うスタックすぐやる確認次に読む稿
ログに token mismatch、ファイル修正が効かない環境変数上書き/複数設定プロセス環境の OPENCLAW_GATEWAY_* を出す;実際に読み込まれたパスと突き合わせる本文 §3 の指紋スクリプト;インストール後 doctor 稿
コンテナ内だけ失敗しホストは成功ループバック/サービス名/DNSコンテナ内で Gateway ポートを curl または nc;ws URL のホストを確認Docker ネットワーク切り分けチェックリスト
1008 と 401/403 相当、または明示的な認証失敗認証設定/リバプロによるヘッダ欠落loopback 直結で再現;リバプロ前後で応答ヘッダを比較Nginx/Caddy リバースプロキシと WebSocket 稿
1006 が多く認証エラーがはっきりしないアイドル切断、プローブによる切断、バージョン不一致CLI と Gateway の版を揃える;ゲートウェイ側がセッションを積極的に切っていないかログを見るGateway 無応答と doctor 稿
onboarding の UI/CLI が止まったまま状態機械未完/ポート競合Listen ポートの衝突を確認;再ペアリング前に一時状態を公式手順に従って掃除公式 Troubleshooting;本文 Runbook
再インストール後「一度だけ繋がるがすぐ切れる」古い token の注入層が残存systemd drop-in、シェルプロファイル、CI 変数を確認インストール稿の pin とプロキシ・フォールバック節

実行断片:「token を誰が上書きしているか」と「CLI が実際に向いている先」

出力はチケットに貼ってください。ルートパスは自環境に置き換えます。Docker ボリュームと権限と併せてレビューするときは、マウントが新しいボリュームを古い設定ディレクトリで覆い隠していないかも確認してください。

bash
# A) 現在のシェルから見える環境変数(大文字小文字とプレフィックスに注意)
env | sort | grep -i OPENCLAW || true

# B) 例:systemd で gateway を管理している場合、drop-in が token を注入していないか
# systemctl show openclaw-gateway --property=Environment 2>/dev/null || true

# C) CLI の版と doctor(まず浅く—本番で盲信 --fix は避ける)
openclaw --version || true
openclaw doctor 2>/dev/null | sed -n '1,40p' || true

# D) CLI 側の gateway URL を表示(サブコマンド名はインストール版に合わせる)
# openclaw config get gateway.remoteUrl  # 例・プレースホルダ

# E) Docker:CLI を動かすコンテナ内で、ws 先が誤った 127.0.0.1:18789 になっていないか
# docker compose exec cli sh -lc 'env | grep -i OPENCLAW; getent hosts openclaw-gateway || true'
info

ヒント:コミュニティ issue では、環境変数の token とファイルの不一致による長時間の onboarding 停滞がよく見られます。Compose を議論する前に、まず A/B の出力を揃えてください。

六段 Runbook:「繋がらない」から「再現可能なペアリング結論」へ

  1. 版の指紋を凍結する:CLI、Gateway イメージの tag、npm グローバルの pin を記録し、インストール稿の pin 方針と揃え、切り分け中に自動アップグレードしないようにします。
  2. 層別に再現する:loopback 直結 → 同一ホストの別ネットワーク名前空間(コンテナ)→ リバプロの順で、各層に失敗が出たログ断片を残します。
  3. 上書き源を空にする:OPENCLAW_GATEWAY_TOKEN などの注入を一つずつ外し、プロセス再起動後に環境がきれいであることを確認してから、設定ファイルに単一の正とします。
  4. ws URL を補正する:コンテナではサービス名と正しいポートを明示します。Docker ネットワーク稿の「127.0.0.1 誤指定禁止」と突き合わせます。
  5. ペアリングをやり直し状態をスクショする:公式 onboarding の順序に従います。ビルドに doctor --deep があれば変更窓の中で使い、出力を保存します。
  6. 回帰用例を書く:最小再現を CI の smoke(health のみ、重いモデルは走らせない)に落とし、次の Compose マージで token 二重化が戻らないようにします。

ダッシュボードと変更票に載せたい「硬い」三指標

  1. Token 正の本数:環境変数・設定ファイル・シークレット管理からの注入経路を数えます(ハッシュ先頭だけで可)。複数は違反なので先に収束させます。
  2. ペアリング再試行率:onboarding の再試行回数と成功回数を記録します。短期で急増する場合は二重 token か誤った ws ホストが多く、「モデルが遅い」ではありません。
  3. 1006/1008 の内訳:週次で切断コードと隣接ログ語を集計します。1008 が認証キーワードと同時に増えるなら、CPU を増やす前にリバプロとヘッダを疑います。

エンジニアリング上の位置づけ(ベンチではなくコミュニティ/運用の経験則)です。公開 issue ではtoken 二重化コンテナ内ループバック誤指定が「初回デプロイ失敗」系で上位に残ります。変更テンプレに環境変数監査を入れると平均の切り分けラウンドは下がりやすいです。さらに重要なのは、これらの失敗はCPU の GHz と相関が弱いことです。メモリを増やしてもハンドシェイク失敗だけが直るとは限りません。

Gateway を 7×24 で動かし、個人ノートのスリープや省電力と争わないなら、「安定した専有実行面」と「ペアリング/アップグレード窓」を同じ SRE 文書に書きます。リモート Mac にエージェント用 Gateway を常駐させる企業運用とも整合します。

なぜ「ノートに Gateway を載せたまま」だと本番ペアリングのリズムが崩れやすいか

個人端末ではスリープ、VPN 切替、企業証明書更新の影響を受けやすく、ペアリング状態機械の監査と再生が難しくなります。token ローテが複数人の CI にまたがる場面では、固定ホスト名と安定したループバック境界も欠けがちで、ログが散らばります。

Gateway を、再起動やディスク・ログの挙動が読みやすく、チーム Runner と同一ネットワークに置ける専用リモート Macに載せると、複数の個人端末を渡り歩くより onboarding 問題が収束しやすいです。Apple Silicon を常時オンで、CI の秘密モデルと揃えて納品したいチームは、MACCOMEMac mini M4 / M4 Pro のマルチリージョンと柔らかいレンタル期間で、「ペアリング切り分け」と「安定実行面」を同じ請求と変更リズムに載せられます。まず公開の料金説明を読み、運用は リモート Mac 常駐運用チェックリストに揃えてください。

パイロット案:主 CI と同じリージョンのリモート 1 台だけ選び、Gateway と最小 smoke ジョブだけ載せ、隔週レビューで本稿の六段 Runbook を回してから、対話開発まで同一トポロジに寄せるか判断します。

よくある質問

先に doctor を回すべきですか、それとも token を変えるべきですか。

まず本文の表 1 で「ペアリング/token」に振り分けます。ネットワーク層まで確定しているなら、doctor のネットワーク項目を並行して構いません。公開の料金とリージョンは レンタル料金の案内をご覧ください。

1006 は必ず 1008 より軽いのでしょうか。

必ずしもそうではありません。隣接ログ行と再現性を見てください。切断コードはラベルであり結論ではないので、認証切り分けを飛ばさないでください。

本番コンテナに長期で token を export してもよいですか。

おすすめしません。オーケストレータから短期クレデンシャルを注入するか、シークレット用サイドカーを使い、「正」を一か所に収束させる方が安全です。さもないとローテのたびに二重化しやすくなります。