WSL2 + Windows + リモート Chrome CDP のトラブルシューティング

​

まず適切なブラウザーモードを選ぶ

​

オプション 1: WSL2 から Windows への生のリモート CDP

​

オプション 2: ホストローカル Chrome MCP

​

動作するアーキテクチャ

• WSL2 が 127.0.0.1:18789 で Gateway を実行する
• Windows が通常のブラウザーで http://127.0.0.1:18789/ の Control UI を開く
• Windows Chrome がポート 9222 で CDP エンドポイントを公開する
• WSL2 がその Windows CDP エンドポイントに到達できる
• OpenClaw が WSL2 から到達可能なアドレスをブラウザープロファイルに指定する

​

Control UI の重要なルール

http://127.0.0.1:18789/

​

レイヤーごとに検証する

​

レイヤー 1: Chrome が Windows で CDP を提供していることを確認する

chrome.exe --remote-debugging-port=9222 --user-data-dir="$env:LOCALAPPDATA\OpenClaw\ChromeCDP"

curl.exe http://127.0.0.1:9222/json/version
curl.exe http://127.0.0.1:9222/json/list

​

portproxy を変更する前に IPv4 と IPv6 を診断する

netstat -ano | findstr :9222
netsh interface portproxy show all
curl.exe http://127.0.0.1:9222/json/version
curl.exe http://[::1]:9222/json/version

• chrome.exe が 127.0.0.1 で応答する場合は、同じく 127.0.0.1:9222 で待ち受ける portproxy ルールをすべて削除します。WSL2 から到達可能な Windows アダプター アドレスだけを 127.0.0.1 に転送します。
• chrome.exe が [::1] でのみ応答する場合は、未使用の IPv4 アドレスへ転送するのではなく、 v4tov6 を使って WSL2 から到達可能なリスナーを ::1 に向けます。
  netsh interface portproxy add v4tov6 listenaddress=WINDOWS_HOST_OR_IP listenport=9222 connectaddress=::1 connectport=9222
  

​

レイヤー 2: WSL2 がその Windows エンドポイントに到達できることを確認する

curl http://WINDOWS_HOST_OR_IP:9222/json/version
curl http://WINDOWS_HOST_OR_IP:9222/json/list

• /json/version が Browser / Protocol-Version メタデータを含む JSON を返す
• /json/list が JSON を返す（ページが開いていなければ空配列でも問題ありません）

​

レイヤー 3: 正しいブラウザープロファイルを設定する

{
  browser: {
    enabled: true,
    defaultProfile: "remote",
    profiles: {
      remote: {
        cdpUrl: "http://WINDOWS_HOST_OR_IP:9222",
        attachOnly: true,
        color: "#00AA00",
      },
    },
  },
}

• Windows 上でだけ動作するものではなく、WSL2 から到達可能なアドレスを使用する
• 外部管理ブラウザーでは attachOnly: true を維持する
• cdpUrl は http://、https://、ws://、または wss:// にできる
• OpenClaw に /json/version を検出させたい場合は HTTP(S) を使用する
• ブラウザープロバイダーが直接の DevTools ソケット URL を提供する場合にのみ WS(S) を使用する
• OpenClaw の成功を期待する前に、同じ URL を curl でテストする

​

レイヤー 4: Control UI レイヤーを別に確認する

• ページのオリジンが gateway.controlUi.allowedOrigins の期待と一致している
• トークン認証またはペアリングが正しく設定されている
• ブラウザーの問題のように見せかけて Control UI 認証問題をデバッグしていない

​

レイヤー 5: エンドツーエンドのブラウザー制御を確認する

openclaw browser --browser-profile remote open https://example.com
openclaw browser --browser-profile remote tabs

• タブが Windows Chrome で開く
• browser tabs がターゲットを返す
• 後続のアクション（snapshot、screenshot、navigate）が同じ プロファイルから動作する

​

よくある紛らわしいエラー

​

高速トリアージチェックリスト

1. Windows: 127.0.0.1 と [::1] のどちらが /json/version に応答し、 そのリスナーは chrome.exe に属しているか？
2. WSL2: curl http://WINDOWS_HOST_OR_IP:9222/json/version は動作するか？
3. OpenClaw 設定: browser.profiles.<name>.cdpUrl は、その正確な WSL2 から到達可能なアドレスを使用しているか？
4. Control UI: LAN IP ではなく http://127.0.0.1:18789/ を開いているか？
5. 生のリモート CDP ではなく、WSL2 と Windows をまたいで existing-session を使おうとしていないか？

​

関連

• ブラウザー
• ブラウザーログイン
• ブラウザー Linux トラブルシューティング