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：Windows 上で Chrome が 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 トラブルシューティング