Rozwiązywanie problemów z WSL2, Windows i zdalnym Chrome CDP

W typowej konfiguracji z rozdzielonymi hostami OpenClaw Gateway działa wewnątrz WSL2, Chrome działa w systemie Windows, a sterowanie przeglądarką musi przekraczać granicę WSL2/Windows. Jednocześnie może wystąpić kilka niezależnych problemów (zobacz zgłoszenie #39369): transport CDP, bezpieczeństwo źródła Control UI oraz token/parowanie mogą ulec awarii niezależnie, generując podobnie wyglądające błędy. Przechodź kolejno przez poniższe warstwy, zamiast zgadywać, która z nich nie działa.

Najpierw wybierz odpowiedni tryb przeglądarki

Opcja 1: bezpośredni zdalny CDP z WSL2 do Windows

Użyj profilu zdalnej przeglądarki wskazującego z WSL2 na punkt końcowy CDP Chrome w systemie Windows. Wybierz tę opcję, gdy Gateway pozostaje wewnątrz WSL2, Chrome działa w systemie Windows, a sterowanie przeglądarką musi przekraczać granicę WSL2/Windows.

Opcja 2: lokalny dla hosta Chrome MCP

Używaj sterownika existing-session (profil user) tylko wtedy, gdy Gateway działa na tym samym hoście co Chrome, chcesz korzystać z lokalnego stanu zalogowanej przeglądarki, nie potrzebujesz transportu przeglądarki między hostami ani funkcji responsebody, eksportu do PDF, przechwytywania pobierania lub operacji wsadowych (profile Chrome MCP ich nie obsługują).

W przypadku Gateway w WSL2 i Chrome w Windows użyj bezpośredniego zdalnego CDP. Chrome MCP działa lokalnie na hoście i nie stanowi mostu między WSL2 a Windows.

Działająca architektura

• WSL2 uruchamia Gateway pod adresem 127.0.0.1:18789
• Windows otwiera Control UI w zwykłej przeglądarce pod adresem http://127.0.0.1:18789/
• Chrome w Windows udostępnia punkt końcowy CDP na porcie 9222
• WSL2 może uzyskać dostęp do tego punktu końcowego CDP w Windows
• OpenClaw kieruje profil przeglądarki na adres dostępny z WSL2

Kluczowa reguła dotycząca Control UI

Gdy interfejs jest otwierany z Windows, używaj hosta lokalnego Windows, chyba że masz celowo skonfigurowane HTTPS:

http://127.0.0.1:18789/

Nie używaj domyślnie adresu IP sieci LAN. Zwykły protokół HTTP pod adresem LAN lub tailnet może wywołać zachowanie związane z niezabezpieczonym źródłem lub uwierzytelnianiem urządzenia, niezależne od samego CDP. Zobacz Control UI.

Weryfikuj warstwami

Przechodź od góry do dołu; nie pomijaj kolejnych kroków. Naprawienie jednej warstwy może nadal pozostawić widoczny inny błąd pochodzący z dalszej warstwy.

Warstwa 1: sprawdź, czy Chrome udostępnia CDP w Windows

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

Chrome 136 i nowsze ignorują przełączniki wiersza poleceń zdalnego debugowania dla domyślnego katalogu danych Chrome. Użyj oddzielnego, niestandardowego katalogu danych, jak pokazano powyżej. Zobacz zmianę zabezpieczeń zdalnego debugowania w Chrome. Nie umożliwia to zdalnego sterowania zwykłym, zalogowanym profilem Chrome.

Najpierw sprawdź działanie samego Chrome z Windows:

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

Jeśli to się nie powiedzie, zdiagnozuj poniższe procesy nasłuchujące w Windows. Na tym etapie problem nie dotyczy jeszcze OpenClaw.

Zdiagnozuj IPv4 i IPv6 przed zmianą portproxy

Chromium próbuje najpierw powiązać zdalne debugowanie z 127.0.0.1, a do [::1] przechodzi tylko wtedy, gdy powiązanie IPv4 się nie powiedzie. Trwała reguła v4tov4 nasłuchująca na 127.0.0.1:9222 może zająć ten punkt końcowy przed uruchomieniem Chrome. Chrome przechodzi wtedy na [::1]:9222, podczas gdy stara reguła przekazuje ruch IPv4 z powrotem do własnego procesu nasłuchującego i zwraca pustą odpowiedź.

Sprawdź rzeczywiste procesy nasłuchujące i reguły serwera proxy w Windows, zamiast wnioskować o nich na podstawie wersji Chrome:

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

Dla każdego identyfikatora PID z netstat użyj polecenia tasklist /fi "PID eq <PID>".

• Jeśli chrome.exe odpowiada pod adresem 127.0.0.1, usuń każdą regułę portproxy, która również nasłuchuje na 127.0.0.1:9222. Przekazuj wyłącznie adres karty sieciowej Windows dostępny z WSL2 do 127.0.0.1.

• Jeśli chrome.exe odpowiada tylko pod adresem [::1], skieruj proces nasłuchujący dostępny z WSL2 na ::1 za pomocą v4tov6, zamiast przekazywać ruch na nieużywany adres IPv4:

  netsh interface portproxy add v4tov6 listenaddress=WINDOWS_HOST_OR_IP listenport=9222 connectaddress=::1 connectport=9222

Powiąż proces nasłuchujący z adresem karty sieciowej wymaganym przez WSL2. Nie udostępniaj portu CDP pod adresem 0.0.0.0, adresem LAN ani adresem tailnet: CDP zapewnia kontrolę nad sesją przeglądarki.

Warstwa 2: sprawdź, czy WSL2 ma dostęp do tego punktu końcowego Windows

Z WSL2 przetestuj dokładnie ten adres, którego zamierzasz użyć w cdpUrl:

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

Prawidłowy wynik:

• /json/version zwraca dane JSON z metadanymi Browser / Protocol-Version
• /json/list zwraca dane JSON (pusta tablica jest prawidłowa, jeśli nie ma otwartych stron)

Jeśli test się nie powiedzie, Windows nie udostępnia jeszcze portu dla WSL2, adres jest nieprawidłowy po stronie WSL2 albo brakuje zapory, przekierowania portów lub serwera proxy. Napraw to przed zmianą konfiguracji OpenClaw.

Warstwa 3: skonfiguruj prawidłowy profil przeglądarki

Skieruj OpenClaw na adres dostępny z WSL2:

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

Uwagi:

• używaj adresu dostępnego z WSL2, a nie adresu działającego wyłącznie w Windows
• pozostaw attachOnly: true dla przeglądarek zarządzanych zewnętrznie
• cdpUrl może używać schematu http://, https://, ws:// lub wss://
• używaj HTTP(S), gdy chcesz, aby OpenClaw wykrywał /json/version
• używaj WS(S) tylko wtedy, gdy dostawca przeglądarki udostępnia bezpośredni adres URL gniazda DevTools
• przetestuj ten sam adres URL za pomocą curl, zanim zaczniesz oczekiwać poprawnego działania OpenClaw

Warstwa 4: sprawdź oddzielnie warstwę Control UI

Otwórz http://127.0.0.1:18789/ z Windows, a następnie sprawdź:

• czy źródło strony odpowiada wartości oczekiwanej przez gateway.controlUi.allowedOrigins
• czy uwierzytelnianie tokenem lub parowanie jest prawidłowo skonfigurowane
• czy nie diagnozujesz problemu z uwierzytelnianiem Control UI tak, jakby był to problem z przeglądarką

Pomocna strona: Control UI.

Warstwa 5: sprawdź kompleksowe sterowanie przeglądarką

Z WSL2:

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

Prawidłowy wynik:

• karta otwiera się w Chrome w Windows
• browser tabs zwraca obiekt docelowy
• kolejne operacje (snapshot, screenshot, navigate) działają z tego samego profilu

Częste mylące błędy

Lista kontrolna szybkiej diagnostyki

1. Windows: który z adresów 127.0.0.1 lub [::1] odpowiada na /json/version i czy ten proces nasłuchujący należy do chrome.exe?
2. WSL2: czy działa curl http://WINDOWS_HOST_OR_IP:9222/json/version?
3. Konfiguracja OpenClaw: czy browser.profiles.<name>.cdpUrl używa dokładnie tego adresu dostępnego z WSL2?
4. Control UI: czy otwierasz http://127.0.0.1:18789/ zamiast adresu IP sieci LAN?
5. Czy próbujesz używać existing-session między WSL2 a Windows zamiast bezpośredniego zdalnego CDP?

Najpierw sprawdź lokalnie punkt końcowy Chrome w Windows, następnie sprawdź ten sam punkt końcowy z WSL2, a dopiero potem diagnozuj konfigurację OpenClaw lub uwierzytelnianie Control UI.

Powiązane materiały

• Przeglądarka
• Logowanie w przeglądarce
• Rozwiązywanie problemów z przeglądarką w systemie Linux