--- read_when: - Запуск OpenClaw Gateway в WSL2, когда Chrome работает в Windows - Обнаружение перекрывающихся ошибок браузера и интерфейса управления в WSL2 и Windows - Выбор между локальным для хоста Chrome MCP и прямым удалённым CDP в конфигурациях с раздельными хостами summary: Устранение неполадок WSL2 Gateway и удалённого CDP Windows Chrome по уровням title: Устранение неполадок WSL2 + Windows + удалённого Chrome CDP x-i18n: generated_at: "2026-07-13T18:41:33Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 24 provider: openai source_hash: be6d9af2b3efb23be22a5ed6e6645348ddc53e6f997280410fa3e00bb44d8b6d source_path: tools/browser-wsl2-windows-remote-cdp-troubleshooting.md workflow: 16 --- В распространённой конфигурации с раздельными хостами OpenClaw Gateway работает внутри WSL2, Chrome — в Windows, а управление браузером должно пересекать границу WSL2/Windows. Одновременно могут проявиться несколько независимых проблем (см. [проблему #39369](https://github.com/openclaw/openclaw/issues/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 намеренно: ```text http://127.0.0.1:18789/ ``` Не используйте IP-адрес локальной сети по умолчанию. Обычный HTTP по адресу локальной сети или tailnet может вызвать поведение, связанное с небезопасным источником или аутентификацией устройства и не относящееся к самому CDP. См. [Control UI](/ru/web/control-ui). ## Проверяйте по уровням Двигайтесь сверху вниз, не пропуская уровни. После исправления одного уровня всё ещё может отображаться другая ошибка с более низкого уровня. ### Уровень 1: убедитесь, что Chrome предоставляет CDP в Windows ```powershell chrome.exe --remote-debugging-port=9222 --user-data-dir="$env:LOCALAPPDATA\OpenClaw\ChromeCDP" ``` Chrome 136 и более поздние версии игнорируют параметры командной строки удалённой отладки для каталога данных Chrome по умолчанию. Используйте отдельный каталог данных, отличный от используемого по умолчанию, как показано выше. См. описание [изменения безопасности удалённой отладки](https://developer.chrome.com/blog/remote-debugging-port) в Chrome. Это не позволяет удалённо управлять обычным профилем Chrome с выполненным входом. Сначала проверьте сам Chrome из Windows: ```powershell 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: ```powershell 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 из `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-адрес: ```powershell 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`: ```bash 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: ```json5 { 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](/ru/web/control-ui). ### Уровень 5: проверьте сквозное управление браузером Из WSL2: ```bash 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, когда локальные вкладки хоста недоступны | ## Контрольный список для быстрой диагностики 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..cdpUrl` именно этот адрес, доступный из WSL2? 4. Control UI: открываете ли вы `http://127.0.0.1:18789/` вместо IP-адреса локальной сети? 5. Не пытаетесь ли вы использовать `existing-session` между WSL2 и Windows вместо прямого удалённого подключения CDP? Сначала локально проверьте конечную точку Chrome в Windows, затем проверьте ту же конечную точку из WSL2 и только после этого диагностируйте конфигурацию OpenClaw или аутентификацию Control UI. ## См. также - [Браузер](/ru/tools/browser) - [Вход в браузере](/ru/tools/browser-login) - [Устранение неполадок браузера в Linux](/ru/tools/browser-linux-troubleshooting)