> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Probleemoplossing voor WSL2 + Windows + externe Chrome-CDP

In de gangbare split-hostconfiguratie draait OpenClaw Gateway binnen WSL2, draait Chrome op Windows, en moet browserbesturing de grens tussen WSL2 en Windows oversteken. Het gelaagde foutpatroon uit [issue #39369](https://github.com/openclaw/openclaw/issues/39369) betekent dat meerdere onafhankelijke problemen tegelijk kunnen optreden, waardoor eerst de verkeerde laag kapot lijkt.

## Kies eerst de juiste browsermodus

Je hebt twee geldige patronen:

### Optie 1: Ruwe externe CDP van WSL2 naar Windows

Gebruik een extern browserprofiel dat vanuit WSL2 naar een Windows Chrome-CDP-eindpunt wijst.

Kies dit wanneer:

* de Gateway binnen WSL2 blijft
* Chrome op Windows draait
* je browserbesturing de grens tussen WSL2 en Windows moet laten oversteken

### Optie 2: Host-lokale Chrome MCP

Gebruik `existing-session` / `user` alleen wanneer de Gateway zelf op dezelfde host als Chrome draait.

Kies dit wanneer:

* OpenClaw en Chrome op dezelfde machine staan
* je de lokale ingelogde browserstatus wilt
* je geen cross-host browsertransport nodig hebt
* je geen geavanceerde beheerde/alleen-raw-CDP-routes nodig hebt, zoals `responsebody`, PDF-
  export, downloadinterceptie of batchacties

Voor WSL2 Gateway + Windows Chrome heeft ruwe externe CDP de voorkeur. Chrome MCP is host-lokaal, geen brug van WSL2 naar Windows.

## Werkende architectuur

Referentievorm:

* WSL2 draait de Gateway op `127.0.0.1:18789`
* Windows opent de Control UI in een normale browser op `http://127.0.0.1:18789/`
* Windows Chrome stelt een CDP-eindpunt beschikbaar op poort `9222`
* WSL2 kan dat Windows CDP-eindpunt bereiken
* OpenClaw wijst een browserprofiel naar het adres dat bereikbaar is vanuit WSL2

## Waarom deze configuratie verwarrend is

Meerdere fouten kunnen elkaar overlappen:

* WSL2 kan het Windows CDP-eindpunt niet bereiken
* de Control UI wordt geopend vanaf een niet-beveiligde oorsprong
* `gateway.controlUi.allowedOrigins` komt niet overeen met de paginaoorsprong
* token of koppeling ontbreekt
* het browserprofiel wijst naar het verkeerde adres

Daardoor kan na het oplossen van één laag nog steeds een andere fout zichtbaar blijven.

## Kritieke regel voor de Control UI

Wanneer de UI vanuit Windows wordt geopend, gebruik dan Windows localhost tenzij je bewust een HTTPS-configuratie hebt.

Gebruik:

`http://127.0.0.1:18789/`

Gebruik niet standaard een LAN-IP voor de Control UI. Gewone HTTP op een LAN- of tailnet-adres kan onveilig-oorsprong-/apparaat-authenticatiegedrag activeren dat niets met CDP zelf te maken heeft. Zie [Control UI](/nl/web/control-ui).

## Valideer in lagen

Werk van boven naar beneden. Sla niets over.

### Laag 1: Controleer of Chrome CDP aanbiedt op Windows

Start Chrome op Windows met remote debugging ingeschakeld:

```powershell theme={"theme":{"light":"min-light","dark":"min-dark"}}
chrome.exe --remote-debugging-port=9222
```

Controleer vanuit Windows eerst Chrome zelf:

```powershell theme={"theme":{"light":"min-light","dark":"min-dark"}}
curl http://127.0.0.1:9222/json/version
curl http://127.0.0.1:9222/json/list
```

Als dit op Windows mislukt, is OpenClaw nog niet het probleem.

### Laag 2: Controleer of WSL2 dat Windows-eindpunt kan bereiken

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

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
curl http://WINDOWS_HOST_OR_IP:9222/json/version
curl http://WINDOWS_HOST_OR_IP:9222/json/list
```

Goed resultaat:

* `/json/version` retourneert JSON met Browser / Protocol-Version-metadata
* `/json/list` retourneert JSON (een lege array is prima als er geen pagina's open zijn)

Als dit mislukt:

* Windows stelt de poort nog niet beschikbaar aan WSL2
* het adres is verkeerd voor de WSL2-kant
* firewall / port forwarding / lokale proxying ontbreekt nog steeds

Los dat op voordat je de OpenClaw-configuratie aanraakt.

### Laag 3: Configureer het juiste browserprofiel

Voor ruwe externe CDP laat je OpenClaw wijzen naar het adres dat bereikbaar is vanuit WSL2:

```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}}
{
  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 wat alleen op Windows werkt
* houd `attachOnly: true` aan voor extern beheerde browsers
* `cdpUrl` kan `http://`, `https://`, `ws://` of `wss://` zijn
* gebruik HTTP(S) wanneer je wilt dat OpenClaw `/json/version` ontdekt
* gebruik WS(S) alleen wanneer de browserprovider je een directe DevTools-socket-URL geeft
* test dezelfde URL met `curl` voordat je verwacht dat OpenClaw slaagt

### Laag 4: Controleer de Control UI-laag afzonderlijk

Open de UI vanuit Windows:

`http://127.0.0.1:18789/`

Controleer daarna:

* de paginaoorsprong komt overeen met wat `gateway.controlUi.allowedOrigins` verwacht
* tokenauthenticatie of koppeling is correct geconfigureerd
* je debugt geen authenticatieprobleem van de Control UI alsof het een browserprobleem is

Nuttige pagina:

* [Control UI](/nl/web/control-ui)

### Laag 5: Controleer end-to-end browserbesturing

Vanuit WSL2:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw browser open https://example.com --browser-profile remote
openclaw browser tabs --browser-profile remote
```

Goed resultaat:

* het tabblad opent in Windows Chrome
* `openclaw browser tabs` retourneert het doel
* latere acties (`snapshot`, `screenshot`, `navigate`) werken vanuit hetzelfde profiel

## Vaak misleidende fouten

Behandel elk bericht als een laagspecifieke aanwijzing:

* `control-ui-insecure-auth`
  * UI-oorsprong / secure-context-probleem, geen CDP-transportprobleem
* `token_missing`
  * authenticatieconfiguratieprobleem
* `pairing required`
  * apparaatgoedkeuringsprobleem
* `Remote CDP for profile "remote" is not reachable`
  * WSL2 kan de geconfigureerde `cdpUrl` niet bereiken
* `Browser attachOnly is enabled and CDP websocket for profile "remote" is not reachable`
  * het HTTP-eindpunt antwoordde, maar de DevTools WebSocket kon nog steeds niet worden geopend
* verouderde viewport- / dark-mode- / locale- / offline-overschrijvingen na een externe sessie
  * voer `openclaw browser stop --browser-profile remote` uit
  * dit sluit de actieve besturingssessie en geeft Playwright/CDP-emulatiestatus vrij zonder de gateway of de externe browser opnieuw te starten
* `gateway timeout after 1500ms`
  * vaak nog steeds CDP-bereikbaarheid of een traag/onbereikbaar extern eindpunt
* `No Chrome tabs found for profile="user"`
  * lokaal Chrome MCP-profiel geselecteerd terwijl er geen host-lokale tabbladen beschikbaar zijn

## Snelle triagechecklist

1. Windows: werkt `curl http://127.0.0.1:9222/json/version`?
2. WSL2: werkt `curl http://WINDOWS_HOST_OR_IP:9222/json/version`?
3. OpenClaw-configuratie: gebruikt `browser.profiles.<name>.cdpUrl` dat exacte vanuit WSL2 bereikbare adres?
4. Control UI: open je `http://127.0.0.1:18789/` in plaats van een LAN-IP?
5. Probeer je `existing-session` over WSL2 en Windows te gebruiken in plaats van ruwe externe CDP?

## Praktische conclusie

De configuratie is meestal haalbaar. Het lastige is dat browsertransport, oorsprongsbeveiliging van de Control UI en token/koppeling elk onafhankelijk kunnen mislukken terwijl ze vanaf de gebruikerskant op elkaar lijken.

Bij twijfel:

* controleer eerst lokaal het Windows Chrome-eindpunt
* controleer daarna hetzelfde eindpunt vanuit WSL2
* debug pas daarna OpenClaw-configuratie of Control UI-authenticatie

## Gerelateerd

* [Browser](/nl/tools/browser)
* [Browserlogin](/nl/tools/browser-login)
* [Probleemoplossing voor Browser op Linux](/nl/tools/browser-linux-troubleshooting)