WSL2とWindows間でOpenClawを連携：Chrome CDP接続トラブル解決ガイド

WSL2 と Windows を組み合わせた開発環境は非常に強力ですが、ネットワークの境界を越えてブラウザを制御しようとすると、途端に複雑さが増してしまいます。「設定したはずなのに動かない」という時、どこに原因があるのか特定するのは至難の業ですよね。

このガイドでは、OpenClaw Gateway を WSL2 で動かし、ブラウザ（Chrome）を Windows 側で動かすという、いわゆる「スプリットホスト」構成でのトラブルシューティングを解説します。複数の問題が重なって発生し、どのレイヤーが壊れているのか分からなくなった時の道標として活用してください。

まずは適切なブラウザモードを選択しましょう

セットアップには、主に 2 つの有効なパターンがあります。

オプション 1: Raw remote CDP

WSL2 から Windows 側の Chrome CDP エンドポイントを直接参照するリモートブラウザプロファイルを使用します。

このパターンが適しているケース：

• ブラウザの制御機能のみが必要な場合
• Chrome のリモートデバッグ機能を WSL2 に公開することに抵抗がない場合
• Chrome extension relay が不要な場合

オプション 2: Chrome extension relay

組み込みの chrome プロファイルと OpenClaw Chrome extension を組み合わせて使用します。

このパターンが適しているケース：

• ツールバーのボタンを使って、既存の Windows Chrome タブにアタッチしたい場合
• 生の --remote-debugging-port ではなく、拡張機能ベースの制御を行いたい場合
• WSL2 と Windows の境界を越えてリレー自体にアクセスする必要がある場合

異なる名前空間を越えて拡張機能リレーを使用する場合、browser.relayBindHost が重要な設定になります。詳細は Browser および Chrome extension を参照してください。

動作アーキテクチャ

標準的な構成イメージは以下の通りです：

• WSL2：Gateway が 127.0.0.1:18789 で動作
• Windows：通常のブラウザで http://127.0.0.1:18789/ を開き、Control UI を表示
• Windows Chrome：ポート 9222 で CDP エンドポイントを公開
• WSL2：Windows 側の CDP エンドポイントに到達可能な状態
• OpenClaw：WSL2 から到達可能なアドレスをブラウザプロファイルに指定

なぜこのセットアップは混乱を招くのか

この構成では、以下のような複数の失敗が重なることがあります。

• WSL2 から Windows の CDP エンドポイントに到達できない
• Control UI がセキュアなオリジン（Secure Origin）から開かれていない
• gateway.controlUi.allowedOrigins がページのオリジンと一致していない
• トークンまたはペアリングが設定されていない
• ブラウザプロファイルが間違ったアドレスを指している
• 名前空間を越えたアクセスが必要なのに、拡張機能リレーがループバック限定（loopback-only）になっている

これらの問題が重なると、一つのレイヤーを修正しても別のエラーが表示され続けるため、解決が難しくなります。

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

Windows から UI を開く際は、意図的な HTTPS 設定がない限り、Windows の localhost を使用してください。

推奨： http://127.0.0.1:18789/

Control UI に LAN IP をデフォルトで使用しないでください。LAN や Tailnet のアドレスでプレーンな HTTP を使用すると、CDP 自体とは無関係な「セキュアでないオリジン」や「デバイス認証」の問題が発生する可能性があります。詳細は Control UI を確認してください。

レイヤーごとに検証する

上から順に確認してください。途中のステップをスキップしてはいけません。

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

リモートデバッグを有効にして Windows で Chrome を起動します。

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

まずは Windows 自体から Chrome の状態を確認します。

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

これが Windows 上で失敗する場合、OpenClaw 以前の問題です。

レイヤー 2: WSL2 から Windows のエンドポイントに到達できるか確認する

WSL2 から、cdpUrl に設定予定の正確なアドレスをテストします。

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 を返す（タブが開いていない場合は空の配列 [] で OK）

失敗する場合：

• Windows が WSL2 に対してポートを公開していない
• WSL2 側から見たアドレスが間違っている
• ファイアウォール、ポートフォワーディング、またはローカルプロキシの設定が不足している

OpenClaw の設定をいじる前に、必ずこれを解決してください。

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

Raw remote CDP の場合、WSL2 から到達可能なアドレスを OpenClaw に指定します。

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

注意点：

• Windows 上だけで動くアドレスではなく、WSL2 から到達可能なアドレスを使用してください
• 外部で管理されているブラウザの場合は attachOnly: true を維持してください
• OpenClaw で試す前に、同じ URL を curl でテストしてください

レイヤー 4: Chrome extension relay を使用する場合

ブラウザが動いているマシンと Gateway が名前空間の境界で分かれている場合、リレーにループバック以外（non-loopback）のバインドドレスが必要になることがあります。

例：

{
  browser: {
    enabled: true,
    defaultProfile: "chrome",
    relayBindHost: "0.0.0.0",
  },
}

必要な場合のみ使用してください：

• デフォルトの挙動（ループバック限定）の方が安全です
• 0.0.0.0 は露出面を広げます
• Gateway の認証、ノードのペアリング、および周囲のネットワークのプライバシーを維持してください

拡張機能リレーが不要な場合は、前述の Raw remote CDP プロファイルを優先してください。

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

Windows から UI を開きます。

http://127.0.0.1:18789/

その後、以下を確認します：

• ページのオリジンが gateway.controlUi.allowedOrigins の期待値と一致しているか
• トークン認証またはペアリングが正しく設定されているか
• Control UI の認証問題を、ブラウザの問題と勘違いしていないか

参考ページ：

• Control UI

レイヤー 6: エンドツーエンドのブラウザ制御を検証する

WSL2 から実行します。

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

拡張機能リレーの場合：

openclaw browser tabs --browser-profile chrome

期待される結果：

• 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 に到達できていません。
• gateway timeout after 1500ms
  • 多くの場合、CDP の到達性、またはリモートエンドポイントの応答が遅い・到達不能なことが原因です。
• Chrome extension relay is running, but no tab is connected
  • 拡張機能リレーのプロファイルが選択されていますが、アタッチされたタブがまだ存在しません。

クイック診断チェックリスト

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. 拡張機能リレーのみ：browser.relayBindHost が本当に必要ですか？必要な場合、明示的に設定されていますか？

実践的なまとめ

このセットアップは十分に実現可能です。難しいのは、ブラウザの通信、Control UI のオリジンセキュリティ、トークン/ペアリング、そして拡張機能リレーのトポロジーといった複数の要素が、ユーザー側からは似たようなエラーに見えつつも、それぞれ独立して失敗する可能性がある点です。

迷ったときは以下の手順を思い出してください。

• 最初に Windows 側で Chrome エンドポイントをローカル検証する
• 次に WSL2 から同じエンドポイントを検証する
• それらが通ってから、OpenClaw の設定や Control UI の認証をデバッグする
• ネットワーク境界を越える際は、常にバインドドレスとオリジンの不一致を疑う

セットアップで困ったときは、こちらのツールも活用してみてください。 AI Setup Assistant

次のステップ

• Control UI の詳細設定
• ブラウザプロファイルの構成
• Chrome 拡張機能のセットアップ