​

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

• OpenClaw Gateway działa wewnątrz WSL2
• Chrome działa w Windows
• sterowanie przeglądarką musi przekraczać granicę WSL2/Windows

​

Najpierw wybierz właściwy tryb przeglądarki

​

Opcja 1: Surowy zdalny CDP z WSL2 do Windows

• Gateway pozostaje wewnątrz WSL2
• Chrome działa w Windows
• potrzebujesz sterowania przeglądarką przez granicę WSL2/Windows

​

Opcja 2: Host-local Chrome MCP

• OpenClaw i Chrome działają na tej samej maszynie
• chcesz używać lokalnego, zalogowanego stanu przeglądarki
• nie potrzebujesz transportu przeglądarki między hostami
• nie potrzebujesz zaawansowanych tras tylko dla managed/raw-CDP, takich jak responsebody, eksport PDF, przechwytywanie pobrań lub działania wsadowe

​

Działająca architektura

• WSL2 uruchamia Gateway na 127.0.0.1:18789
• Windows otwiera Control UI w zwykłej przeglądarce pod adresem http://127.0.0.1:18789/
• Windows Chrome udostępnia punkt końcowy CDP na porcie 9222
• WSL2 może połączyć się z tym punktem końcowym CDP w Windows
• OpenClaw wskazuje profil przeglądarki na adres osiągalny z WSL2

​

Dlaczego ta konfiguracja jest myląca

• WSL2 nie może połączyć się z punktem końcowym CDP w Windows
• Control UI jest otwierany z niezabezpieczonego origin
• gateway.controlUi.allowedOrigins nie pasuje do origin strony
• brakuje tokenu lub parowania
• profil przeglądarki wskazuje niewłaściwy adres

​

Kluczowa zasada dla Control UI

​

Weryfikuj warstwami

​

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

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

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

​

Warstwa 2: Sprawdź, czy WSL2 może połączyć się z tym punktem końcowym Windows

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

• /json/version zwraca JSON z metadanymi Browser / Protocol-Version
• /json/list zwraca JSON (pusta tablica jest w porządku, jeśli nie ma otwartych stron)

• Windows nie udostępnia jeszcze portu dla WSL2
• adres jest niewłaściwy po stronie WSL2
• nadal brakuje konfiguracji firewalla / przekierowania portów / lokalnego proxy

​

Warstwa 3: Skonfiguruj prawidłowy profil przeglądarki

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

• użyj adresu osiągalnego z WSL2, a nie takiego, który działa tylko w Windows
• zachowaj attachOnly: true dla przeglądarek zarządzanych zewnętrznie
• cdpUrl może używać 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 podaje bezpośredni URL gniazda DevTools
• przetestuj ten sam URL za pomocą curl, zanim oczekujesz, że OpenClaw zadziała

​

Warstwa 4: Osobno sprawdź warstwę Control UI

• czy origin strony pasuje do tego, czego oczekuje gateway.controlUi.allowedOrigins
• czy auth tokenem lub parowanie są poprawnie skonfigurowane
• czy nie debugujesz problemu auth Control UI tak, jakby był problemem przeglądarki

• Control UI

​

Warstwa 5: Sprawdź pełne sterowanie przeglądarką end-to-end

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

• karta otwiera się w Windows Chrome
• openclaw browser tabs zwraca cel
• późniejsze działania (snapshot, screenshot, navigate) działają z tego samego profilu

​

Typowe mylące błędy

• control-ui-insecure-auth
  • problem z origin interfejsu / secure-context, a nie z transportem CDP
• token_missing
  • problem z konfiguracją auth
• pairing required
  • problem z zatwierdzeniem urządzenia
• Remote CDP for profile "remote" is not reachable
  • WSL2 nie może połączyć się ze skonfigurowanym cdpUrl
• Browser attachOnly is enabled and CDP websocket for profile "remote" is not reachable
  • punkt końcowy HTTP odpowiedział, ale nadal nie udało się otworzyć WebSocketu DevTools
• nieaktualne nadpisania viewport / dark-mode / locale / offline po zdalnej sesji
  • uruchom openclaw browser stop --browser-profile remote
  • to zamyka aktywną sesję sterowania i zwalnia stan emulacji Playwright/CDP bez restartowania gateway ani zewnętrznej przeglądarki
• gateway timeout after 1500ms
  • często nadal problem z osiągalnością CDP albo wolnym/niedostępnym zdalnym punktem końcowym
• No Chrome tabs found for profile="user"
  • wybrano lokalny profil Chrome MCP tam, gdzie nie ma dostępnych kart host-local

​

Szybka lista kontroli

1. Windows: czy działa curl http://127.0.0.1:9222/json/version?
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 osiągalnego z WSL2?
4. Control UI: czy otwierasz http://127.0.0.1:18789/, a nie adres LAN?
5. Czy próbujesz używać existing-session przez WSL2 i Windows zamiast surowego zdalnego CDP?

​

Praktyczny wniosek

• najpierw zweryfikuj lokalnie punkt końcowy Windows Chrome
• potem zweryfikuj ten sam punkt końcowy z WSL2
• dopiero wtedy debuguj konfigurację OpenClaw lub auth Control UI