​

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

• OpenClaw Gateway は WSL2 内で動作する
• Chrome は Windows 上で動作する
• ブラウザー制御は WSL2/Windows の境界をまたぐ必要がある

​

まず正しいブラウザーモードを選ぶ

​

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

• Gateway は WSL2 内に置いたままにする
• Chrome は Windows 上で動作する
• ブラウザー制御で WSL2/Windows の境界をまたぐ必要がある

​

オプション 2: host-local Chrome MCP

• OpenClaw と Chrome が同じマシン上にある
• ローカルのログイン済みブラウザー状態を使いたい
• ホスト間のブラウザー転送は不要
• responsebody、PDF エクスポート、ダウンロードのインターセプト、バッチアクションのような、高度な managed/raw-CDP 専用ルートは不要

​

動作アーキテクチャ

• 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 から到達可能なアドレスを指すブラウザープロファイルを使う

​

この構成が分かりにくい理由

• WSL2 から Windows の CDP エンドポイントに到達できない
• Control UI が安全でないオリジンから開かれている
• gateway.controlUi.allowedOrigins がページのオリジンと一致しない
• token または pairing が不足している
• ブラウザープロファイルが誤ったアドレスを指している

​

Control UI に関する重要なルール

​

層ごとに検証する

​

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

chrome.exe --remote-debugging-port=9222

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

​

レイヤー 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 を返す（ページが開かれていなければ空配列でも可）

• Windows がまだそのポートを WSL2 に公開していない
• WSL2 側にとってアドレスが間違っている
• firewall / port forwarding / local proxying がまだ足りない

​

レイヤー 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) を使ってください
• browser provider が直接の DevTools ソケット URL を提供する場合にのみ WS(S) を使ってください
• OpenClaw の成功を期待する前に、同じ URL を curl でテストしてください

​

レイヤー 4: Control UI 層を別個に検証する

• ページオリジンが gateway.controlUi.allowedOrigins の期待と一致している
• token 認証または pairing が正しく設定されている
• 実際は Control UI の認証問題なのに、ブラウザー問題としてデバッグしていない

• Control UI

​

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

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

• タブが Windows Chrome で開く
• openclaw browser tabs が対象を返す
• その後の操作（snapshot、screenshot、navigate）が同じプロファイルから動作する

​

よくある誤解を招くエラー

• control-ui-insecure-auth
  • UI オリジン / セキュアコンテキストの問題であり、CDP 転送の問題ではない
• token_missing
  • 認証設定の問題
• pairing required
  • デバイス承認の問題
• Remote CDP for profile "remote" is not reachable
  • WSL2 から設定された cdpUrl に到達できない
• Browser attachOnly is enabled and CDP websocket for profile "remote" is not reachable
  • HTTP エンドポイントは応答したが、DevTools WebSocket はまだ開けなかった
• リモートセッション後に viewport / dark-mode / locale / offline の上書き状態が残る
  • openclaw browser stop --browser-profile remote を実行する
  • これにより、Gateway や外部ブラウザーを再起動せずに、アクティブな制御セッションを閉じて Playwright/CDP のエミュレーション状態を解放します
• gateway timeout after 1500ms
  • 多くの場合、依然として CDP の到達性の問題か、遅い/到達不能なリモートエンドポイント
• No Chrome tabs found for profile="user"
  • host-local のタブが利用できないのに、ローカル Chrome MCP プロファイルが選ばれている

​

迅速なトリアージチェックリスト

1. Windows: curl http://127.0.0.1:9222/json/version は動きますか？
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 を使おうとしていませんか？

​

実践的な要点

• まず Windows の Chrome エンドポイントをローカルで確認する
• 次に同じエンドポイントを WSL2 から確認する
• その後で初めて OpenClaw の設定や Control UI 認証をデバッグする