Windows で Docker Desktop と WSL2 を使って OpenClaw を動かす際、インストーラの停止、トークン URL が到達不能、コンテナは running だがホスト CLI がプローブできない、アップグレード後に CLI とコンテナ版が食い違うといった症状が出た場合に貼れるチェックリストです。Windows／macOS／Linux インストール総覧、Compose ペアリング（1006／1008）、GHCR イメージと Control UI、Gateway doctor トリアージ、さらに SSH ローカル転送でリモート Gateway と ネイティブ macOS パスと役割分担します。公式の Gateway トラブルシュートは OpenClaw Gateway Troubleshooting を参照してください。
docker compose up が併存し、二重 Gateway や文書化されたループバックポートの競合が起きる（openclaw gateway status で確認）。openclaw --version とコンテナ内 CLI が食い違い、doctor の警告がモデル障害と読み違えられる。本稿は概念ツアーではなく、Windows と Docker に特化した実行可能なトリアージです。macOS、Linux systemd、Tailscale の Runbook と同じ検証ラダーを共有しますが、ホスト側の責務は異なります。
no-reply／モデルエラー Runbook を既に読んでいる場合は、本稿をモデルやチャネルに触る前の前提チェックとしてください。
現場では、WSL2 のディストリビューション更新と Docker Desktop のチャネル（Stable／Preview）が非同期に進み、同じ docker compose.yml でも名前解決の挙動だけが変わることがあります。その場合、OpenClaw 本体を再インストールする前に、wsl --shutdown 後の再起動や、社内 VPN が WSL の仮想スイッチに干渉していないかを切り分けると時間を節約できます。
また、トークンと gateway.auth の単一ソースを Runbook に明文化しないまま複数メンバーが触ると、「自分の端末では動く」状態が固定化します。変更管理の観点では、docker ps と openclaw gateway status のマスク済み出力をチケットに添付し、Compose ペアリング記事の表と突き合わせる運用が有効です。
オフライン／準オフライン環境では、GHCR や Docker Hub への経路がプロキシとミラーで二重化され、digest の検証が抜けると「ランダムに pull が失敗する」ように見えます。このときは GHCR Runbook のデータプレーン節と合わせ、社内レジストリのメタデータキャッシュ TTL まで含めて記録してください。
| 症状クラスタ | 初動チェック（5分以内） | 次の一手 |
|---|---|---|
| ウィザードが固まる／URL が出ない | Docker Desktop の状態、WSL 有効化、空きディスクが約 20 GB 超か（例示しきい値。基線は各社で調整） | 文書化された compose で Gateway を起動し docker logs を読む。スクリプトと手動の二重起動を避ける |
| コンテナは running だがホスト CLI が接続できない | ポート競合、コンテナネットワーク内にしか見えない誤バインド | openclaw gateway status／openclaw status を実行し、Compose ペアリング記事で TOKEN と名前空間を照合 |
| アップグレード直後の退行 | ホスト CLI とイメージタグの整合、競合設定を残す古いボリューム | バージョンを揃え openclaw doctor を実行。バックアップチェックポイントを残したうえで文書通りに Gateway を再構築 |
コミュニティ知見（ベンダー保証ではありません）：停止したウィザードを中断して docker compose up -d に切り替える例があります。未文書化のフラグや pending JSON を触れた場合は現行の公式ドキュメントへ戻し、本番では未公開スイッチに依存しないでください。
wsl --version、OpenClaw CLI の --version、イメージ digest をチケットに貼る。openclaw status → openclaw gateway status → openclaw doctor → openclaw channels status --probe（チャネルは導入経路のドキュメントに従う）。ステップ 3 と 4 の間に詰まる場合は、プロンプト調整の前に、マスク済みのコンテナ環境変数の一部と docker port の対応を印刷します。多くの「無返信」はトランスポート未準備が原因で、温度設定ではありません。
SSH 転送でリモート Gateway を使う場合、ノート PC 側は転送ポートへの TCP と単一の TOKEN ソースがあれば足ります。認証なしで Gateway ポートをインターネットに公開しないでください。
運用チーム向けには、各ステップに「期待される出力の例」と「不一致ならどのステップへ戻るか」を Markdown で共有しておくと、当番が交代しても同じ順序で切り分けできます。特に doctor の警告文はバージョンで文言が変わるため、スクリーンショットではなくテキストログを残す習慣を推奨します。
wsl --status docker version openclaw --version openclaw gateway status openclaw doctor
doctor をクリアするか明示的な免除を登録し、Gateway 依存のパイプライン変更をマージしない。スリープ方針、Patch Tuesday、Docker Desktop の更新が可用性を不規則なスライスに切ります。「動いたマシン」共有の Gateway は、同型イメージ・固定リスナー・監査ログを難しくし、結果として安くはなりません。
その近道と比べ、予測可能な Apple Silicon ホスト、安定したリージョン出口、文書化された SSH または tailnet トポロジーで 7×24 の Gateway を載せ、Windows Docker は開発サンドボックスに留めたい場合、MACCOME のクラウド Mac mini は多くの場合より安全な本番面です。六国の専用ノード、柔軟なリース、排他的ディスクとプロセス空間であり、他の OpenClaw とリモート Mac の Runbook と矛盾しません。
人事異動や端末交換が起きたとき、ノート依存の Gateway は秘密鍵とローカル状態の引き継ぎコストが跳ね上がります。専用リモート Mac に載せ替えると、起動手順と監視をインフラ側に寄せやすくなり、オンボーディングの再現性が上がります。
引き渡し資料にはイメージタグ、compose 断片の版、プロキシ方針、コマンド出力サンプルが必要です。別の Windows 端末で再現できない手順は未完成です。
ネイティブ macOS Runbook と対照すると、ラダーは同じだがホストの責務が違うため、起動セマンティクスを混ぜないでください。
最後の五分：Docker の単一の正は準備できたか、Gateway は単一トラックか、doctor はクリーンか。三つとも yes のときだけモデルとチャネルのトリアージ文書を開きます。