Боли: удалённый шлюз — это эксплуатационный контракт
Боль 1: раздвоение. Если openclaw gateway status показывает разные Config (cli) и Config (service), вы правите один JSON, а systemd или launchd всё ещё смотрит на другую копию через HOME или EnvironmentFile.
Боль 2: устаревший URL. Ротация VM или новые контейнеры без обновления gateway.remote.url дают гейзенбаги: UI попадает на CDN edge, а проба — в отключённый частный IP.
Боль 3: путаница с pairing. Проблемы pairing тоже рвут UI; сначала лестница status.
Боль 4: RPC и тишина канала. Красная проба — транспорт; зелёная проба и молчание Telegram — канальный runbook.
Слои: CLI, RPC, каналы
L0 версии. Согласуйте openclaw --version на ноутбуке и хосте шлюза.
L1 gateway status. Зафиксируйте runtime, URL цели пробы, ожидаемый TLS SNI и сравните с gateway.remote.url.
L2 doctor. Снимите блокеры до обвинения сети.
L3 каналы. После зелёного L1 запускайте channels status --probe.
Поля тикета с цифрами
В каждом тикете: сводки двойных путей, remote URL, маскированные префиксы токена, имена unit, время последней зелёной RPC, notAfter TLS, RTT админ→шлюз, почасовые снимки на апгрейде.
Ёмкость: одновременные UI-сессии нагружают WebSocket; p95 проб отдельно от задержки модели.
Матрица решений
| Симптом | Вероятная причина | Первый шаг | Откат |
|---|---|---|---|
| Config(cli)≠Config(service) | устаревшие метаданные сервиса | gateway install --force и холод | бэкап JSON и credentials |
| Runtime ок, проба нет | токен, bind, прокси | выровнять токены; upstream; curl/ws | логировать порядок reload |
| URL сменили, клиент старый | DNS/кэш UI | сброс DNS; перезапуск UI | не фиксировать IP навсегда |
| Каналы тихие, RPC зелёный | не слой remote | каналы и квоты | не менять токен и webhook параллельно |
Семь шагов
- Заморозить: полный gateway status с редактированием.
- Проверить семантику remote: gateway.mode и gateway.remote.url по доке.
- Согласовать токены CLI/UI/сервиса.
- Квартет reverse-proxy: TLS, WebSocket, allowedOrigins, keepalive.
openclaw gateway install --force+gateway restartс именами unit.- doctor без блокеров; выжимка в тикет.
- База: p95 проб и одна успешная операция UI.
Пример блока для тикета
openclaw --version
openclaw gateway status
openclaw config get gateway.remote.url
openclaw doctorУглубление: реальные причины вместо копипаста
systemd --user, linger и одинаковый HOME
Служба в режиме systemd --user исчезает после закрытия SSH, если не включён loginctl enable-linger. Статус шлюза может казаться здоровым, пока сессия жива, а затем «ломаться» без изменений JSON. Проверьте loginctl show-user, сравните $XDG_RUNTIME_DIR в интерактивной оболочке и в unit, убедитесь, что тот же Unix-пользователь владеет редактируемым openclaw.json. Частая ошибка — unit под root, а операторы правят файлы обычного пользователя: отсюда расхождение Config (cli) и Config (service).
launchd: явные переменные, а не .zshrc
На macOS launchd не подхватывает вашу .zshrc. Пути к Node и бинарникам openclaw в терминале и в агенте расходятся. Задайте EnvironmentVariables в plist, направьте stdout/stderr в файлы, избегайте относительных путей к конфигу. После точечного обновления macOS прогоняйте короткий smoke: перезапуск unit, свежий gateway status, сверка путей до правок DNS или прокси.
Обратный прокси: SNI, WebSocket и таймауты
Имя в TLS должно совпадать с gateway.remote.url и целью RPC-пробы. Иначе TLS рвётся без явной ошибки в UI. Проверьте маппинг upgrade WebSocket, задайте разумный proxy_read_timeout для длинных сессий, убедитесь, что healthcheck бьёт в тот же порт, что слушает процесс. Логируйте фактический upstream-адрес, чтобы инцидент можно было воспроизвести без догадок.
Токены, bind вне loopback и единый источник
Современные ограничения часто запрещают слушать LAN без согласованного секрета. Частичная ротация — UI обновлён, сервис читает старый EnvironmentFile — даёт загадочные 401. Остановите сервис, обновите секрет в одном месте, выполните gateway install --force, холодный рестарт, затем обновляйте клиентов. Так нет окна, где браузер шлёт новый токен на старый бинарник.
Наблюдаемость: разделяйте handshake, первую RPC и LLM
Собирайте отдельно метрики TLS-handshake, апгрейда WebSocket, первой успешной RPC и задержки модели. Если растёт только последняя — шлюз здоров. Если падает апгрейд — не крутите токены вслепую. Для 152-ФЗ/GDPR фиксируйте, какие строки логов могут содержать секреты и сколько их хранить — это реальная польза вместо повторов абзацев.
DNS, TTL и blue-green
Смена хоста в gateway.remote.url требует учёта TTL, кэша браузера и параллельно живых старых узлов. Короткий TTL ускоряет откат, но нагружает резолверы. Запланируйте окно, где доступны оба конца, зафиксируйте время официального переключения и панели, которые должны позеленеть. Постмортем полезнее, когда там таймстемпы, а не десять одинаковых фраз.
Pairing и remote-дрейф
Проблемы pairing дают похожий симптом в UI, но другой сценарий CLI. Сначала пройдите официальную лестницу status → gateway → logs, иначе потеряете историю одобрений устройств. Remote-дрейф — это транспорт и файлы конфигурации; фиксируйте, какой слой упал первым, чтобы не спорить между сетью и продуктом.
Хаос и откат
На staging удалите EnvironmentFile и убедитесь, что алерт сработал. Откат — обратные шаги по чек-листу, а не стек полуфиксов. Каждый шаг с временем лучше ста страниц с одинаковыми предложениями.
Аренда удалённого Mac
Если нет сил постоянно следить за drift unit-файлов, TLS и прокси, управляемый всегда включённый Mac часто дешевле ночных дежурств. Политики токенов остаются у вас, «железный» цикл и базовые сонды — у провайдера. Сравните минуты простоя RPC с часовой ставкой дежурства.
RACI и первые пятнадцать минут
Сначала фиксируйте только факты: полный вывод gateway status с замазанными префиксами токенов, время последней зелёной RPC-пробы, строки прокси с реальным upstream и два конфликтующих пути конфигурации. Если один человек одновременно правит DNS, unit-файлы и сертификаты и ещё ведёт заметки, след потом не восстановить. Разделите роли наблюдателя, исполнителя и того, кто утверждает reload; перекрёстная проверка перед продакшеном спасает от взаимоисключающих хотфиксов.
Кэши DNS и асимметрия резолверов
Ноутбук оператора может держать старую частную IP, пока на шлюзе уже виден новый A-запись. Проверяйте тем резолвером, которым реально пользуется браузер или скрипт пробы, а не только dig с бастиона. Запишите TTL и негативное кэширование — они объясняют отложенное «самоисцеление» после корректного выката. Для внутреннего имени в gateway.remote.url проверьте split DNS между VLAN.
Цепочки TLS, stapling и разные trust store
После смены промежуточного сертификата Nginx может отдавать полную цепь, а процесс шлюза — только лист, или наоборот. Сравнивайте openssl s_client с исходного диапазона адресов, откуда бьёт автоматическая сонда, а не только с рабочего ноутбука. Ошибки OCSP stapling часто всплывают под нагрузкой; один ручной рукопожатия мало что доказывает.
Шторм переподключений
После короткого обрыва множество клиентов одновременно открывает WebSocket заново. Без умеренного backoff на клиенте и без разумных лимитов приёма на прокси процесс шлюза может упереться в CPU при здоровом транспорте. Прогоните синтетический сценарий в препроде до выбора окна обслуживания.
Кардинальность метрик
Метки с ID канала или пользователя на каждом ряду раздувают стоимость и почти не помогают при сбоях транспорта. По умолчанию держите грубые измерения: окружение, роль хоста, мажорная версия. Тонкий drill-down включайте только на время инцидента, потом отключайте, чтобы дашборды оставались читаемыми.
Постмортем с измеримыми действиями
Каждому пункту — владелец, срок и ссылка на тикет или PR. Вместо общих фраз про «важность мониторинга» укажите, какая именно дыра закрывается: какая проба или какой дифф конфигурации появится автоматически после инцидента.
Журналы и корреляция без шума
Сведите в одну временную шкалу события systemd или launchd, reload прокси, смену DNS и результат RPC-пробы. Если шкала разъезжается из-за разных часовых поясов или миллисекундных сдвигов, заранее договоритесь об UTC и о точности логов. Иначе постмортем превращается в спор о порядке событий, а не в устранение причины дрейфа между CLI и сервисом.
Долгосрочная гигиена конфигурации
Раз в квартал прогоняйте сценарий: свежая VM или чистый пользовательский аккаунт, установка по документации, затем сравнение gateway status с эталонным чек-листом. Расхождения фиксируйте в инфраструктурном коде, а не в личных заметках. Так вы ловите дрейф до того, как он попадёт в ночной эскалационный звонок.
Окно обновления и ворота готовности
Сначала стабилизируйте конфигурацию прокси, затем перезапускайте демон шлюза, и только после этого подталкивайте клиентов обновить UI. Переставьте порядок — получите полуоткрытые WebSocket на узле со старыми upstream-картами. Закрывайте инцидент только после трёх подряд зелёных проб с двух независимых исходных сетей.
Stateful firewall и длинные сессии
Часть периметровых устройств молча рвёт малоактивные TCP-сессии на контрольной плоскости, хотя с точки зрения приложения канал «живой». Сведите в таблицу все idle-timeout на пути и согласуйте их с heartbeat приложения и таймаутами прокси; иначе вы чините TLS, а рвёт средний слой.
SLA арендодателя и ваша телеметрия
Аренда Mac обычно покрывает отказ железа, но не дрейф unit-файлов и не шторм переподключений. Зафиксируйте заранее, какие метрики остаются на вашей стороне. Ночные runbook должны выполняться без доступа в панель провайдера, иначе каждый инцидент упирается в часы работы поддержки.
Согласование версий клиента и сервера
Разные minor-версии openclaw на ноутбуке и на хосте шлюза иногда по-разному сериализуют поля конфигурации или меняют значения по умолчанию для удалённого режима. После обновления одной стороны сразу сверяйте openclaw --version и diff нормализованного JSON; не полагайтесь на «визуально одинаковый» файл на диске.
Границы ответственности между сетью и приложением
Когда RPC зелёный, а пользователи жалуются на «зависания», разделите гипотезы: задержка в модели, очередь сообщений канала, или же MTU/фрагментация на пути до удалённого ЦОД. Короткий тест с уменьшенным MSS или с другим выходным IP часто быстрее длинного обсуждения без измерений.
Ротация секретов без двойной правды
Токены должны создаваться в одном авторитетном месте и затем доставляться на ноутбук админа, unit сервиса и UI по согласованному каналу. Три параллельных «быстрых» правки приводят к тому, что побеждает последняя запись на диск, а логи ещё показывают старые префиксы. Сразу после смены секрета выполните gateway status и RPC-пробу и сохраните хэш соответствующего JSON — так споры о состоянии опираются на факты, а не на память.
Документация URL и соглашение об именах
Зафиксируйте в репозитории инфраструктуры, является ли gateway.remote.url каноническим FQDN или допустим ли CNAME с коротким TTL для blue-green. Смешение «официально мы зовём хост A, а в старых скриптах всё ещё B» порождает частичные обновления DNS и ощущение мистического флейка. Один абзац в README с примером dig и ожидаемым ответом экономит часы расследований.
Если в организации несколько команд с разными VPN, явно укажите, из какой сети должна стучаться внешняя сонда: иначе «зелёно у нас» и «красно у клиента» будут оба правдой из-за расхождения маршрутов, а не из-за OpenClaw. Запишите ожидаемый next-hop и номер egress-интерфейса в том же README, чтобы новый дежурный не начинал с нуля.
Связанные материалы
Pairing: runbook pairing. Установка: install шлюза. TLS/WebSocket: reverse proxy. Тишина канала: каналы. Аудит 4.14: аудит.
Remote чинит транспорт и auth; зелёная проба не заменяет разбор каналов или квот.
FAQ и аренда удалённого Mac
Достаточно ли SSH-туннеля?
Краткосрочно да; долгосрочно зафиксируйте канонические URL и токены.
VPS или удалённый Mac?
VPS для Linux-автоматизации; Mac для Apple-native сборок и выдачи файлов рядом с агентами.
Зачем аренда SFTPMAC?
Если runbooks есть, но дрейф железа и входа сжигает дежурство, аренда даёт постоянную доступность и базовые метрики, сохраняя вашу политику токенов.