2026: OpenClaw на Windows и Linux — PowerShell и WSL2, корпоративный HTTPS-прокси, политика Node и runbook до удалённого шлюза macOS (FAQ)
Инженерные команды, которые ходят с Windows или Linux на физический шлюз OpenClaw в macOS, чаще всего спотыкаются о три шва: разные рантаймы Node, корпоративный MITM TLS и «localhost», который в PowerShell и WSL2 — не одно и то же. Здесь — матрица выбора среды, семь проверяемых шагов, фрагменты для прокси, ориентиры для дизайн-дока и FAQ для внутренней вики. Для стабильного шлюза на железе см. руководство по развёртыванию 24/7 ИИ-агентов OpenClaw на узлах ZoneMac; про стабильность физического Mac в CI — OpenClaw и CI: почему физический Mac mini стабильнее.
1. Боли, с которыми команды сталкиваются на практике
- Расщепление между оболочками. Node 20 в PowerShell и Node 18 в WSL2 дают разные OpenSSL по умолчанию, разные глобальные пути npm и инциденты «у меня работает», которые проходят ревью, потому что обе стороны выглядят «достаточно Linux».
- Корпоративные HTTPS-прокси и невидимый MITM. Трафик к registry.npmjs.org, Git и API моделей идёт через прокси; без выпускающего ЦС в том trust store, который использует рантайм, установки падают с TLS-ошибками, похожими на «лежит регистр».
- Localhost не переносится. SSH
-L, поднятый в Windows, не обязан быть виден на127.0.0.1внутри WSL2, и наоборот — CLI OpenClaw может быть «зелёным», а плагин IDE смотрит в мёртвый сокет.
2. Матрица: PowerShell vs WSL2 vs Linux
Выберите одну основную среду на инженера для клиентских сценариев OpenClaw, опишите её в онбординге и добейтесь паритета Node через .nvmrc или engines в package.json. Таблица ниже — для аудита ноутбуков и споров в чате.
| Критерий | Нативный Windows (PowerShell) | WSL2 (Ubuntu) | Linux desktop |
|---|---|---|---|
| Корпоративное доверие TLS | Хранилище сертификатов Windows; ближе к SOE ИТ | Нужен явный импорт ЦС в bundle WSL | update-ca-certificates или корпоративный агент |
| Эргономика HTTPS-прокси | Системный прокси + переменные HTTPS_PROXY |
В ~/.bashrc; следите за расхождением apt и npm |
Переменные сессии; при systemd — отдельные override |
| SSH local forward к шлюзу Mac | Клиент OpenSSH в Windows; bind 127.0.0.1 на Windows |
Туннель в WSL, если CLI там; не смешивайте 127.0.0.1 | Как на сервере Linux; проще всего ментально |
| Дисциплина версии Node | fnm/nvm-windows; антивирус может сканировать node.exe |
fnm/nvm в дистрибутиве; жёстко pin engines | Как колонка WSL2 |
| Лучше всего когда… | ИТ требует нативных Windows-агентов | Автоматизация на bash и контейнеры — каждый день | Корпоративная Linux-рабочая станция |
3. Семь шагов внедрения (воспроизводимо)
Шаг 1 — Зафиксировать целевую линейку Node
Ветки OpenClaw 2026.x обычно ориентируются на Node 22 LTS. Закоммитьте 22.x в .nvmrc и диапазон engines.node в репозитории, где живёт CLI.
Шаг 2 — Поставить Node только в выбранной оболочке
Windows PowerShell (пример fnm):
winget install Schniz.fnm fnm install 22 fnm use 22 node -v
WSL2/Ubuntu:
curl -fsSL https://fnm.vercel.app/install | bash source ~/.bashrc fnm install 22 && fnm use 22 node -v
Шаг 3 — Переменные прокси и список обхода
Единообразно используйте ВЕРХНИЙ регистр. Пример (замените хост и порт):
export HTTPS_PROXY=http://proxy.corp.example:8080 export HTTP_PROXY=http://proxy.corp.example:8080 export NO_PROXY=localhost,127.0.0.1,::1,.corp.example,169.254.0.0/16
В Windows можно зафиксировать для пользователя через setx или свойства системы; после этого перезапустите терминал.
Шаг 4 — Доверить цепочку ЦС предприятия
Экспортируйте цепочку в PEM. Для Node в Linux/WSL2 задайте NODE_EXTRA_CA_FILES=/path/to/corp-ca-bundle.pem в том же профиле оболочки, что и для OpenClaw. В нативном Windows Node импортируйте в доверенные корни/промежуточные и перезапустите сессии; проверьте npm ping или короткий node -e "https.get('https://registry.npmjs.org')".
Шаг 5 — Установить CLI OpenClaw и снять версии
При зеркале Artifactory следуйте внутреннему имени пакета. В каждый тикет поддержки вкладывайте openclaw --version, Node и билд ОС — это снимает половину «таинственных обрывов».
Шаг 6 — Достучаться до шлюза macOS одной дисциплиной туннеля
Создавайте SSH -L в той же среде, что и CLI. Шаблон: ssh -N -L 18787:127.0.0.1:18787 user@mac-host (порты замените на bind шлюза). При Tailscale Serve сначала добейтесь зелёного curl на Mac localhost, затем отдавайте URL клиентам.
Шаг 7 — Проверить curl из той же оболочки
Выполните curl -v http://127.0.0.1:18787/health (или документированный health) и сравните с curl на Mac к 127.0.0.1. Расхождение почти всегда — неверный bind, порт или туннель в «другой» подсистеме.
4. Цифры и рычаги политики
Согласование Node: команды, где между Windows и WSL2 плавает больше одного minor, получают примерно в 2–3 раза больше обращений на первой неделе по auth шлюза и WebSocket upgrade — закрепите один minor на сквад.
Keepalive длинных туннелей: сочетайте ServerAliveInterval 30 и ServerAliveCountMax 4 в ~/.ssh/config, чтобы пережить гостевой Wi‑Fi и агрессивные middlebox.
Гигиена NO_PROXY: всегда включайте 127.0.0.1, localhost, ::1; иначе прокси даёт 5–15 с подвисаний на loopback.
5. FAQ и разбор по симптомам
Ставить в PowerShell или WSL2?
См. раздел 2. Плохой ответ — «и то и другое без pin». Если безопасность требует Windows trust store, по умолчанию PowerShell; если автоматизация bash-first — полностью WSL2 и туннели там же.
TLS-ошибки только в npm/pnpm
Браузер доверяет MITM через ОС; Node не подхватывает это автоматически. Чините импорт ЦС для рантайма. strict-ssl=false оставьте для узких захватов.
PowerShell curl до шлюза есть, WSL2 — нет
Туннель поднят в Windows, а CLI в WSL2 (или наоборот). Пересоздайте forward в подсистеме, которой владеет процесс OpenClaw, либо используйте адрес хоста, документированный для вашей сборки WSL.
HTTP 502 или пустой UI через туннель
Сначала докажите шлюз на Mac через localhost curl. Если там плохо — перезапуск сервиса и логи launchd. Если на Mac ок — проверьте порядок -L, коллизию локального порта и не перепутали ли HTTP с HTTPS на hop к loopback.
6. Почему физический шлюз логичнее держать на Apple Silicon
Клиентский runbook — только половина истории: шлюз OpenClaw на macOS выигрывает от пропускной способности объединённой памяти Apple Silicon при параллельных агентах, от дружелюбного к 7×24 launchd и от Unix-цепочки, совпадающей с большинством CI. Узел класса Mac mini в простое держится порядка ~4 Вт и остаётся готовым к SSH-пробросу и health-check — проще обосновать, чем шумную башню в кладовке.
macOS даёт связку Gatekeeper, SIP и FileVault с меньшим типичным риском drive-by по сравнению с универсальными SOE на Windows — это важно, когда рядом со шлюзом лежат долгоживущие токены. Держите Windows/Linux контролируемыми клиентами, а «истину» шлюза — на тихом эффективном Apple Silicon.
Если вы выравниваете шлюзы для распределённой команды, Mac mini M4 в 2026 году — сильная база: предсказуемая задержка и низкие операционные расходы на электричество. Посмотрите варианты ZoneMac, когда будете готовы сопоставить этот runbook с промышленными хостами macOS.
Нужен постоянный хост шлюза macOS?
Сопоставьте этот runbook для Windows/Linux с физическим Mac mini, который патчится, онлайн и ближе к пользователям.