Устранение неполадок WSL2 + Windows + удалённого Chrome CDP

В распространённой конфигурации с раздельными хостами OpenClaw Gateway работает внутри WSL2, Chrome — в Windows, а управление браузером должно пересекать границу WSL2/Windows. Одновременно могут проявиться несколько независимых проблем (см. проблему #39369): транспорт CDP, безопасность источника Control UI и токен/сопряжение могут независимо давать сбои, создавая при этом похожие ошибки. Последовательно проверьте перечисленные ниже уровни, а не пытайтесь угадать, какой из них неисправен.

Сначала выберите правильный режим браузера

Вариант 1: прямое удалённое подключение CDP из WSL2 к Windows

Используйте профиль удалённого браузера, направленный из WSL2 на конечную точку CDP Chrome в Windows. Выбирайте этот вариант, когда Gateway остаётся внутри WSL2, Chrome работает в Windows, а управление браузером должно пересекать границу WSL2/Windows.

Вариант 2: локальный для хоста Chrome MCP

Используйте драйвер existing-session (профиль user) только в том случае, если Gateway работает на том же хосте, что и Chrome, вам нужно локальное состояние браузера с выполненным входом, не требуется межхостовой транспорт браузера и не нужны responsebody, экспорт PDF, перехват загрузок или пакетные действия (профили Chrome MCP их не поддерживают).

Для сочетания Gateway в WSL2 и Chrome в Windows используйте прямое удалённое подключение CDP. Chrome MCP работает локально на хосте и не является мостом между WSL2 и Windows.

Рабочая архитектура

• WSL2 запускает Gateway на 127.0.0.1:18789
• Windows открывает Control UI в обычном браузере по адресу http://127.0.0.1:18789/
• Chrome в Windows предоставляет конечную точку CDP на порту 9222
• WSL2 может обращаться к этой конечной точке CDP в Windows
• OpenClaw направляет профиль браузера на адрес, доступный из WSL2

Критически важное правило для Control UI

Когда интерфейс открывается из Windows, используйте localhost Windows, если только у вас не настроен HTTPS намеренно:

http://127.0.0.1:18789/

Не используйте IP-адрес локальной сети по умолчанию. Обычный HTTP по адресу локальной сети или tailnet может вызвать поведение, связанное с небезопасным источником или аутентификацией устройства и не относящееся к самому CDP. См. Control UI.

Проверяйте по уровням

Двигайтесь сверху вниз, не пропуская уровни. После исправления одного уровня всё ещё может отображаться другая ошибка с более низкого уровня.

Уровень 1: убедитесь, что Chrome предоставляет CDP в Windows

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

Chrome 136 и более поздние версии игнорируют параметры командной строки удалённой отладки для каталога данных Chrome по умолчанию. Используйте отдельный каталог данных, отличный от используемого по умолчанию, как показано выше. См. описание изменения безопасности удалённой отладки в Chrome. Это не позволяет удалённо управлять обычным профилем Chrome с выполненным входом.

Сначала проверьте сам Chrome из Windows:

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

Если проверка завершается сбоем, выполните диагностику прослушивающих сокетов Windows, описанную ниже. На этом этапе проблема ещё не в OpenClaw.

Проверьте IPv4 и IPv6 перед изменением portproxy

Chromium сначала пытается привязать удалённую отладку к 127.0.0.1 и переходит к [::1], только если привязка IPv4 завершается сбоем. Постоянное правило v4tov4, прослушивающее 127.0.0.1:9222, может занять эту конечную точку до запуска Chrome. Тогда Chrome переходит к [::1]:9222, а старое правило перенаправляет трафик IPv4 обратно на собственный прослушивающий сокет и возвращает пустой ответ.

Проверьте фактические прослушивающие сокеты и правила прокси из Windows, а не пытайтесь определить их по версии Chrome:

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

Используйте tasklist /fi "PID eq <PID>" для каждого PID из netstat.

• Если chrome.exe отвечает на 127.0.0.1, удалите все правила portproxy, которые также прослушивают 127.0.0.1:9222. Перенаправляйте только адрес адаптера Windows, доступный из WSL2, на 127.0.0.1.

• Если chrome.exe отвечает только на [::1], направьте доступный из WSL2 прослушивающий сокет на ::1 с помощью v4tov6, вместо перенаправления на неиспользуемый IPv4-адрес:

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

Привяжите прослушивающий сокет к адресу адаптера, который требуется WSL2. Не публикуйте порт CDP на 0.0.0.0, адресе локальной сети или адресе tailnet: CDP предоставляет управление сеансом браузера.

Уровень 2: убедитесь, что WSL2 может обращаться к этой конечной точке Windows

Из WSL2 проверьте точный адрес, который планируете использовать в cdpUrl:

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

Ожидаемый результат:

• /json/version возвращает JSON с метаданными Browser / Protocol-Version
• /json/list возвращает JSON (пустой массив допустим, если ни одна страница не открыта)

Если проверка завершается сбоем, Windows ещё не предоставляет порт для WSL2, адрес неверен для стороны WSL2 либо отсутствует настройка брандмауэра, перенаправления портов или проксирования. Исправьте это, прежде чем изменять конфигурацию OpenClaw.

Уровень 3: настройте правильный профиль браузера

Направьте OpenClaw на адрес, доступный из WSL2:

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

Примечания:

• используйте адрес, доступный из WSL2, а не адрес, работающий только в Windows
• сохраняйте attachOnly: true для браузеров под внешним управлением
• cdpUrl может иметь значение http://, https://, ws:// или wss://
• используйте HTTP(S), если хотите, чтобы OpenClaw обнаруживал /json/version
• используйте WS(S), только если поставщик браузера предоставляет прямой URL-адрес сокета DevTools
• проверьте тот же URL с помощью curl, прежде чем ожидать успешной работы OpenClaw

Уровень 4: отдельно проверьте уровень Control UI

Откройте http://127.0.0.1:18789/ из Windows, затем убедитесь, что:

• источник страницы соответствует ожидаемому значению gateway.controlUi.allowedOrigins
• аутентификация с помощью токена или сопряжение настроены правильно
• вы не диагностируете проблему аутентификации Control UI как проблему браузера

Полезная страница: Control UI.

Уровень 5: проверьте сквозное управление браузером

Из WSL2:

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

Ожидаемый результат:

• вкладка открывается в Chrome в Windows
• browser tabs возвращает целевой объект
• последующие действия (snapshot, screenshot, navigate) работают из того же профиля

Распространённые ошибки, вводящие в заблуждение

Контрольный список для быстрой диагностики

1. Windows: какой из адресов 127.0.0.1 или [::1] отвечает на /json/version и принадлежит ли этот прослушивающий сокет процессу chrome.exe?
2. WSL2: работает ли curl http://WINDOWS_HOST_OR_IP:9222/json/version?
3. Конфигурация OpenClaw: использует ли browser.profiles.<name>.cdpUrl именно этот адрес, доступный из WSL2?
4. Control UI: открываете ли вы http://127.0.0.1:18789/ вместо IP-адреса локальной сети?
5. Не пытаетесь ли вы использовать existing-session между WSL2 и Windows вместо прямого удалённого подключения CDP?

Сначала локально проверьте конечную точку Chrome в Windows, затем проверьте ту же конечную точку из WSL2 и только после этого диагностируйте конфигурацию OpenClaw или аутентификацию Control UI.

См. также

• Браузер
• Вход в браузере
• Устранение неполадок браузера в Linux