Руководство по развёртыванию 2026-03-30 14 мин

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 стабильнее.

2026 OpenClaw Windows Linux WSL2 прокси и удалённый шлюз macOS

1. Боли, с которыми команды сталкиваются на практике

  1. Расщепление между оболочками. Node 20 в PowerShell и Node 18 в WSL2 дают разные OpenSSL по умолчанию, разные глобальные пути npm и инциденты «у меня работает», которые проходят ревью, потому что обе стороны выглядят «достаточно Linux».
  2. Корпоративные HTTPS-прокси и невидимый MITM. Трафик к registry.npmjs.org, Git и API моделей идёт через прокси; без выпускающего ЦС в том trust store, который использует рантайм, установки падают с TLS-ошибками, похожими на «лежит регистр».
  3. 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.

Удалённые Mac

Нужен постоянный хост шлюза macOS?

Сопоставьте этот runbook для Windows/Linux с физическим Mac mini, который патчится, онлайн и ближе к пользователям.

Apple Silicon bare metal Готовность к SSH Низкое потребление в простое
Аренда macOS в облаке Ограниченное время — низкая цена
Получить сейчас