Устранение неполадок 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/version
curl.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 :9222
netsh interface portproxy show all
curl.exe http://127.0.0.1:9222/json/version
curl.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/version
curl 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.com
openclaw browser --browser-profile remote tabs

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

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

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

Сообщение	Значение
`control-ui-insecure-auth`	проблема источника интерфейса или безопасного контекста, а не транспорта CDP
`token_missing`	проблема конфигурации аутентификации
`pairing required`	проблема подтверждения устройства
`Remote CDP for profile "remote" is not reachable`	WSL2 не может обратиться к настроенному `cdpUrl`
пустой ответ CDP / `other side closed` через portproxy	несоответствие прослушивающего сокета Windows или зацикливание на себя; проверьте оба семейства loopback и `netsh interface portproxy show all`
`Browser attachOnly is enabled and CDP websocket for profile "remote" is not reachable`	конечная точка HTTP ответила, но открыть WebSocket DevTools не удалось
устаревшие параметры области просмотра / тёмного режима / локали / автономного режима после удалённого сеанса	выполните `openclaw browser --browser-profile remote stop`, чтобы закрыть сеанс и освободить кэшированное подключение Playwright/CDP без перезапуска Gateway или внешнего браузера
истечение времени ожидания около `remoteCdpTimeoutMs` (по умолчанию 1500ms)	обычно это по-прежнему проблема доступности CDP либо медленная или недоступная удалённая конечная точка
`Playwright page enumeration timed out after 3000ms`	подключение к удалённому CDP установлено, но чтение его постоянной вкладки зависло; крайний срок — большее из значений `remoteCdpTimeoutMs` и `remoteCdpHandshakeTimeoutMs`
`No Chrome tabs found for profile="user"`	выбран локальный для хоста профиль Chrome MCP, когда локальные вкладки хоста недоступны

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

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

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

Overview

Plugins

Plugin guides

Building plugins

Skills

Automation

Tools

Agent coordination

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

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

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

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

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

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

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

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

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

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

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

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

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

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

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

​См. также

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также