Probleemoplossing voor WSL2 + Windows + externe Chrome CDP

In de gebruikelijke configuratie met gescheiden hosts draait OpenClaw Gateway binnen WSL2, draait Chrome op Windows en moet browserbesturing de grens tussen WSL2 en Windows passeren. Er kunnen tegelijkertijd meerdere onafhankelijke problemen optreden (zie issue #39369): CDP- transport, oorsprongsbeveiliging van de Control UI en token/koppeling kunnen elk afzonderlijk mislukken en toch vergelijkbare fouten opleveren. Doorloop de onderstaande lagen op volgorde in plaats van te raden welke defect is.

Kies eerst de juiste browsermodus

Optie 1: rechtstreekse externe CDP van WSL2 naar Windows

Gebruik een extern browserprofiel dat vanuit WSL2 verwijst naar een CDP- eindpunt van Chrome op Windows. Kies dit wanneer de Gateway binnen WSL2 blijft draaien, Chrome op Windows draait en browserbesturing de grens tussen WSL2 en Windows moet passeren.

Optie 2: hostlokale Chrome MCP

Gebruik het stuurprogramma existing-session (profiel user) alleen wanneer de Gateway op dezelfde host als Chrome draait, u de lokale aangemelde browserstatus wilt gebruiken, u geen browsertransport tussen hosts nodig hebt en u geen responsebody, PDF-export, downloadonderschepping of batchacties nodig hebt (Chrome MCP-profielen ondersteunen deze niet).

Gebruik voor WSL2 Gateway + Windows Chrome rechtstreekse externe CDP. Chrome MCP is hostlokaal en geen brug van WSL2 naar Windows.

Werkende architectuur

• WSL2 voert de Gateway uit op 127.0.0.1:18789
• Windows opent de Control UI in een normale browser op http://127.0.0.1:18789/
• Chrome op Windows stelt een CDP-eindpunt beschikbaar op poort 9222
• WSL2 kan dat CDP-eindpunt op Windows bereiken
• OpenClaw laat een browserprofiel verwijzen naar het vanuit WSL2 bereikbare adres

Cruciale regel voor de Control UI

Wanneer de UI vanuit Windows wordt geopend, gebruikt u Windows-localhost, tenzij u bewust HTTPS hebt geconfigureerd:

http://127.0.0.1:18789/

Gebruik niet standaard een LAN-IP-adres. Onversleutelde HTTP op een LAN- of tailnetadres kan gedrag activeren voor een onveilige oorsprong of apparaatauthenticatie dat niets met CDP zelf te maken heeft. Zie Control UI.

Valideer in lagen

Werk van boven naar beneden en sla niets over. Nadat u één laag hebt hersteld, kan er nog steeds een andere fout zichtbaar zijn uit een onderliggende laag.

Laag 1: controleer of Chrome CDP beschikbaar stelt op Windows

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

Chrome 136 en hoger negeren opdrachtregelopties voor externe foutopsporing wanneer de standaardgegevensmap van Chrome wordt gebruikt. Gebruik een afzonderlijke, niet-standaard gegevensmap, zoals hierboven weergegeven. Zie de beveiligingswijziging voor externe foutopsporing van Chrome. Hiermee wordt het normale aangemelde Chrome-profiel niet op afstand bestuurbaar.

Controleer vanuit Windows eerst Chrome zelf:

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

Als dit mislukt, onderzoekt u de Windows-listeners hieronder. OpenClaw is dan nog niet het probleem.

Onderzoek IPv4 en IPv6 voordat u portproxy wijzigt

Chromium probeert externe foutopsporing eerst aan 127.0.0.1 te binden en valt alleen terug op [::1] als de IPv4-binding mislukt. Een permanente v4tov4-regel die luistert op 127.0.0.1:9222 kan dat eindpunt bezetten voordat Chrome start. Chrome valt dan terug op [::1]:9222, terwijl de oude regel IPv4-verkeer terugstuurt naar zijn eigen listener en een leeg antwoord retourneert.

Controleer vanuit Windows de daadwerkelijke listeners en proxyregels in plaats van deze af te leiden uit de Chrome-versie:

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

Gebruik tasklist /fi "PID eq <PID>" voor elke PID uit netstat.

• Als chrome.exe antwoordt op 127.0.0.1, verwijdert u elke portproxyregel die ook luistert op 127.0.0.1:9222. Stuur alleen het vanuit WSL2 bereikbare Windows-adapteradres door naar 127.0.0.1.

• Als chrome.exe alleen antwoordt op [::1], laat u de vanuit WSL2 bereikbare listener met v4tov6 naar ::1 verwijzen in plaats van door te sturen naar een ongebruikt IPv4-adres:

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

Bind de listener aan het adapteradres dat WSL2 nodig heeft. Stel de CDP- poort niet beschikbaar op 0.0.0.0, een LAN-adres of een tailnetadres: CDP geeft controle over de browsersessie.

Laag 2: controleer of WSL2 dat Windows-eindpunt kan bereiken

Test vanuit WSL2 het exacte adres dat u in cdpUrl wilt gebruiken:

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

Goed resultaat:

• /json/version retourneert JSON met Browser / Protocol-Version-metagegevens
• /json/list retourneert JSON (een lege matrix is prima als er geen pagina's geopend zijn)

Als dit mislukt, stelt Windows de poort nog niet beschikbaar aan WSL2, is het adres onjuist voor de WSL2-zijde of ontbreekt een firewall-, poortdoorstuur- of proxyconfiguratie. Herstel dit voordat u de OpenClaw-configuratie wijzigt.

Laag 3: configureer het juiste browserprofiel

Laat OpenClaw verwijzen naar het vanuit WSL2 bereikbare adres:

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

Opmerkingen:

• gebruik het vanuit WSL2 bereikbare adres, niet een adres dat alleen op Windows werkt
• behoud attachOnly: true voor extern beheerde browsers
• cdpUrl kan http://, https://, ws:// of wss:// zijn
• gebruik HTTP(S) wanneer u wilt dat OpenClaw /json/version detecteert
• gebruik WS(S) alleen wanneer de browserprovider u een rechtstreekse DevTools- socket-URL geeft
• test dezelfde URL met curl voordat u verwacht dat OpenClaw slaagt

Laag 4: controleer de Control UI-laag afzonderlijk

Open http://127.0.0.1:18789/ vanuit Windows en controleer vervolgens:

• of de paginaoorsprong overeenkomt met wat gateway.controlUi.allowedOrigins verwacht
• of tokenauthenticatie of koppeling correct is geconfigureerd
• of u niet een authenticatieprobleem van de Control UI onderzoekt alsof het een browserprobleem is

Nuttige pagina: Control UI.

Laag 5: controleer de browserbesturing van begin tot eind

Vanuit WSL2:

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

Goed resultaat:

• het tabblad wordt geopend in Chrome op Windows
• browser tabs retourneert het doel
• latere acties (snapshot, screenshot, navigate) werken vanuit hetzelfde profiel

Veelvoorkomende misleidende fouten

Snelle controlelijst voor probleemdiagnose

1. Windows: welke van 127.0.0.1 of [::1] antwoordt op /json/version, en behoort die listener toe aan chrome.exe?
2. WSL2: werkt curl http://WINDOWS_HOST_OR_IP:9222/json/version?
3. OpenClaw-configuratie: gebruikt browser.profiles.<name>.cdpUrl exact dat vanuit WSL2 bereikbare adres?
4. Control UI: opent u http://127.0.0.1:18789/ in plaats van een LAN-IP-adres?
5. Probeert u existing-session tussen WSL2 en Windows te gebruiken in plaats van rechtstreekse externe CDP?

Controleer eerst lokaal het Chrome-eindpunt op Windows, controleer daarna hetzelfde eindpunt vanuit WSL2 en onderzoek pas vervolgens de OpenClaw-configuratie of Control UI-authenticatie.

Gerelateerd

• Browser
• Browseraanmelding
• Probleemoplossing voor Browser op Linux