Болевые точки: в облаке Linux стабильно, под WSL2 — нервно
1. Два localhost. Привязка к 127.0.0.1 безопасна, но телефон в Wi‑Fi не достучится до слушателя внутри WSL, пока Windows снова не опубликует порт или край не переедет на реальный NIC. Симптом: curl в Ubuntu работает, Postman в Windows — нет, потому что все ждут «одну» TCP-стек.
2. systemd не PID 1. Юниты с VPS не стартуют без init. Остаётся tmux и ручные shell — ломается операционная история из матрицы постоянного daemon.
3. Сон и VPN. Долгоживущие транспорты чата падают тихо; процесс шлюза жив, воркеры каналов зависли. Поэтому в эксплуатации шлюза просят коррелировать doctor с канальными логами, а не зелёную HTTP-пробу.
4. TLS. Терминация на Windows, plaintext в WSL и снова HTTP может съесть заголовки WebSocket. Сверяйтесь с прокси и TLS; WSL — ещё один хоп в runbook.
5. Дрейф путей. Node в Windows, nvm в WSL, несколько openclaw. После обновления ExecStart смотрит на старый префикс — см. установка и откат.
6. «Поставим Docker Desktop». Ещё один NAT; уместно для Compose-культуры, не автоматически проще systemd в WSL для одного процесса. Решайте по метрикам.
Режимы энергосбережения Windows могут задерживать heartbeat; зафиксируйте, разрешён ли шлюз на батарее. Разные локали и часовые пояса сдвигают метки логов — UTC в приложении упрощает сверку с webhooks провайдера. Смешанные macOS/WSL команды требуют runbook на оба пути или одного «золотого» сценария.
Иногда полезно завести отдельную тестовую учётную запись бота с урезанным трафиком: вы проверяете сетевой контур без риска для продакшен-диалогов. Переключение между учётками должно быть явным в конфиге, иначе «тестовый» токен окажется в unit с меткой prod.
Наконец, документируйте ожидаемую задержку между событием провайдера и ответом шлюза в вашей сети; без базовой линии невозможно отличить деградацию модели от чисто сетевого хвоста на стороне клиента или WSL.
Пространства имён WSL2: куда падают пакеты
WSL2 — лёгкая utility VM: свои интерфейсы и маршруты. 127.0.0.1 в Ubuntu — loopback VM, не Windows. Служба только на Windows не появится в Linux «магически» без форвардинга или документированного механизма доступа к хосту.
Зеркальный сетевой режим облегчает жизнь, но не снимает необходимость описать интерфейс webhook, профиль фаервола и URL в панели провайдера. Диаграммы считайте двумя блоками, пока не доказано иное.
Исходящий NAT из WSL обычно работает: модели и исходящий Telegram ок, входящие webhooks ломаются — типичный признак незакрытой входной цепочки, а не «рандома» OpenClaw.
Для LAN одного 0.0.0.0 в WSL мало: нужны portproxy и правила Windows. Безопаснее loopback плюс контролируемый reverse proxy или слушатель на маленькой VM / удалённом Mac на хостинге SFTPMAC.
Корпоративный split DNS на Windows может расходиться с systemd-resolved в WSL — сохраняйте ответы резолверов с обеих сторон при повторяющихся инцидентах.
Дрейф времени в VM редок, но ломает OAuth; сравнивайте синхронизацию с Windows, если падает только подписанная валидация webhook на WSL.
IPv6-only или домашний CGNAT усложняют проброс: явно укажите IPv4/IPv6/туннель для callbacks. Антивирус/EDR может душить localhost или исходящий трафик WSL без следов в Linux — добавьте проверку в чеклист рядом с фаерволом и portproxy.
В README пометьте, доступен ли endpoint «только из WSL», «только LAN» или «публично с mTLS», чтобы не повторять одни вопросы на каждой смене дежурства.
Корпоративные политики «запретить входящие из интернета» часто конфликтуют с webhook-телеграмом: нужен явный официальный путь — либо reverse proxy в DMZ, либо туннель, либо перенос шлюза на площадку с согласованным ingress. Иначе каждый разработчик изобретает свой обход, не попадающий в аудит.
Нагрузочное тестирование с ноутбука на батарее отличается от сети питания: троттлинг CPU и задержки радиомодуля меняют тайминги повторных попыток каналов. Если вы принимаете SLO по задержке ответа бота, фиксируйте, на каком железе и питании эти SLO измерялись.
systemd в WSL: из unit-файлов сделать надзор
Современный WSL позволяет systemd как init: /etc/wsl.conf, systemd=true, затем wsl --shutdown и перезапуск дистрибутива. Без перезагрузки юниты парсятся, но не цепляются к PID 1.
Далее дисциплина сервера: daemon-reload, явные User= и WorkingDirectory=, Restart=on-failure с бэкоффом, LimitNOFILE под параллельные tool-calls. Сочетайте с «лестницей здоровья» из документации residency — active (running) не гарантирует живые каналы.
Системные и пользовательские юниты читают разные EnvironmentFile; секреты на /mnt/c требуют внимания к правам и CRLF.
Если политика запрещает systemd в WSL, нужен supervisor с политикой рестартов, не интерактивная оболочка. Аналогия с launchd в статье о постоянстве: интеграция с ОС обязательна для 24/7 шлюзов.
Логи в journalctl с персистентным journal, если разбор переподключений через дни. Ротация, чтобы VHDX на ноутбуках не заполнились.
Обновления поэтапно: сохранить последний чистый вывод openclaw doctor, обновить пакеты, перезагрузить юниты, снова пройти лестницу. Связать с откатом, чтобы CLI и daemon не разъехались.
После feature-update Windows проверяйте portproxy — иначе правила исчезнут незаметно. Бэкап включайте unit-файлы и wsl.conf. Наблюдаемость должна отделять CPU модели, tool-вызовы и бесконечные reconnect-циклы каналов.
При миграции сотрудника на новый ПК недостаточно скопировать репозиторий: без тех же unit, переменных окружения и сетевой схемы шлюз «внезапно» перестаёт принимать webhooks, хотя код идентичен. Чеклист онбординга должен включать сетевой слой WSL, а не только git clone.
Версии ядра WSL и дистрибутива влияют на поведение systemd и сокетов; закрепляйте в документации минимально поддерживаемые версии, чтобы случайное обновление не стало сюрпризом в пятницу вечером.
Матрица решений: bind, проброс Windows, reverse proxy
| Паттерн | Плюс | Риск | Когда уместно |
|---|---|---|---|
| Только loopback в WSL | Минимальная экспозиция | Нет прямого LAN/телефона | Локальные CLI-агенты |
| Все интерфейсы WSL + portproxy | Ясный путь с LAN | Перекос в открытость, устаревшие правила | Домашний homelab с allowlist |
| TLS на Windows proxy → WSL | Центр сертификатов | Ошибки WebSocket/заголовков | Псевдо-прод на одном ПК |
| SSH-туннель из облака | Нет публичного listener дома | Сложность, флап туннеля | Личные эксперименты |
| Шлюз на хостинговом удалённом Mac | Питание и сеть проще | Вендор, политика сети | Фокус на аптайме |
| Docker Desktop | Воспроизводимые образы | Ещё NAT, тонкости volume | Стандарт Compose везде |
На среду — один основной паттерн в онбординге. Гибрид ломается, когда половина тестирует loopback, а половина ждёт LAN без чтения таблицы portproxy.
Учения: оборвать VPN, усыпить машину, зафиксировать алерты и время восстановления — вместо декоративных диаграмм.
При выборе строки таблицы фиксируйте владельца: кто обновляет сертификаты на Windows-прокси, кто перезапускает unit в WSL, кто меняет URL в консоли Telegram. Размытое «команда платформы» приводит к тому, что в праздник никто не трогает просроченный сертификат, потому что все думали, что это не их зона.
Если вы используете несколько ботов или рабочих пространств Slack, разведите их по разным порту или hostname на краю, иначе отладка смешивает логи и метрики; WSL-часть остаётся простой, а сложность держите на измеримом reverse proxy.
Лестница команд: от загрузки WSL до доказательств doctor
# 1) systemd (пример — смотрите доку дистрибутива)
# sudo tee /etc/wsl.conf <<'EOF'
# [boot]
# systemd=true
# EOF
# Windows: wsl --shutdown
# 2) init и unit
# ps -p 1 -o comm=
# systemctl status openclaw-gateway.service
# 3) слушатели в WSL (порт подставьте)
# ss -lntp | head
# 4) portproxy Windows (PowerShell администратора)
# netsh interface portproxy add v4tov4 listenport=8443 listenaddress=0.0.0.0 connectport=8443 connectaddress=<WSL-IP>
# 5) диагностика OpenClaw (флаги по релизу)
# openclaw status
# openclaw gateway status
# openclaw doctor
# openclaw logs --follow
В тикет прикладывайте все выводы разом; скриншот тишины в Telegram не заменяет journal про ошибки обновления токена.
Порядок чтения и сопутствующая защита
Начните с развёртывания Windows, macOS и Linux, затем выровняйте длительный режим через launchd/systemd residency. При сбоях каналов переходите к эксплуатации и каналам до переписывания конфигов. Webhooks с TLS-терминаторами — прокси и WebSocket. Для обновлений держите открытым установку и откат.
Слоистый openclaw doctor: после systemd, portproxy, сертификатов, VPN запускайте снова. doctor чист, Telegram падает — углубляйтесь в транспортные логи, не крутите модель вслепую.
Петли Slack часто связаны с таймаутами сокета или корпоративным прокси на Windows; продублируйте переменные в WSL.
Стейджинг копирует bind-паттерн прода; только loopback в тесте и публичный hostname в бою прячет allowedOrigins до релиза.
На десктопе планируйте CPU: параллельные tool-вызовы голодят heartbeat каналов. Ревью безопасности просит одностраничную схему: Windows, WSL, listener, сертификаты, callback URL.
В change review фиксируйте, кто меняет portproxy/фаервол. Playbook дежурства: как быстро узнать IP WSL, вывести portproxy, проверить видимость listener в VM и на хосте. Несколько дистрибутивов — документируйте, какая несёт «почти прод» и как в скриптах задаётся wsl -d. Сравнивайте TCO часов отладки WSL с арендой управляемого удалённого Mac.
Для комплаенса полезно хранить вывод openclaw doctor и снимок netsh interface portproxy show all в тикете на каждое изменение ingress: ревьюеры видят до и после, а не только дифф в Git.
Если организация требует разделения сред, не смешивайте на одном WSL и прод-, и препрод-секреты в одном home — отдельные пользователи Linux или отдельные дистрибутивы снижают риск перекрёстного чтения файлов окружения.
Наконец, помните, что пользовательский опыт оператора важен: runbook на пятидесяти страницах не читают в 03:00. Одна страница «что сделать за пять минут» плюс ссылка на углублённый раздел снижает MTTR сильнее, чем ещё один дашборд без процедуры.
FAQ, ограничения и мост к удалённому Mac на SFTPMAC
Зеркальная сеть решает всё для localhost webhooks?
Нет; нужны bind, фаервол и callback URL, плюс проверка внешним клиентом, повторяющим путь Telegram/Slack.
doctor зелёный, после сна тишина?
Сопоставьте метки systemd со сном, проверьте сокеты в логах каналов, перезапустите шлюз; при необходимости зависимости на network-online.
Прод-шлюз на ноутбуке разработчика?
Обычно нет: сон, обновления, VPN. Для аптайма — стационарная инфра или управляемый удалённый Mac.
Уже кодим в WSL — зачем Mac?
Разделение ролей: IDE/сборки в WSL, шлюз OpenClaw на удалённом Mac на хостинге SFTPMAC со стабильным питанием и привычными SSH/SFTP поставками; меньше portproxy и риска сна на Windows. Артефакты можно гонять по той же операционной истории без знаний portproxy у каждого. Такой сдвиг часто сокращает количество «не воспроизводится у меня» инцидентов, потому что край сети перестаёт зависеть от конкретного ноутбука.
Итог: WSL2 задаёт границу пространства имён и опциональный systemd. Относитесь к localhost, пробросу и TLS как к проектным решениям; запускайте openclaw doctor после каждого изменения границы и коррелируйте каналы со структурными логами. Успех меряйте временем до убедительного доказательства, не только uptime, средней загрузкой CPU и количеством перезапусков без объяснения причины.
Ограничения: Не перечислить все сборки Windows, VPN и Docker Desktop. Если налог на интеграцию выше выгоды, перенесите шлюз на хостинговую macOS-инфраструктуру, оставив Linux-разработку на десктопе. Отдельно учитывайте конфликты Hyper-V, другие гипервизоры и корпоративный TLS-inspection, ломающий WebSocket. Также помните о различиях между каналами Dev и Retail Windows, о политиках MDM, которые могут блокировать локальные административные шаблоны, и о том, что некоторые античит-пакеты игр агрессивно фильтруют нестандартный трафик — на личных машинах это бывает неожиданным фактором.
Оцените SFTPMAC, если нужны стабильные шлюзы OpenClaw на удалённых Mac с меньшим пробросом портов WSL и риском сна. Это особенно полезно командам, которые уже инвестировали в Apple-цепочки сборки и хотят единый хост для агентов и артефактов.