2026 OpenClaw шлюз: разбор по цепочке status → logs → doctor (порт 18789 и каналы)

1. Зачем порядок

Одна строка runtime: running не доказывает, что 18789 слушает корректно, что pairing ещё действителен и что вебхуки или long-poll мессенджера реально доставляют события. Прыгать к смене модели до status или запускать doctor --fix, не прочитав JSONL по порядку, часто превращает баг прав канала в «ленивую модель», а дрейф удалённого URL — в лимиты провайдера. Минимальная дисциплина эксплуатации в 2026 году: сохранить status и ограниченный по времени срез логов до любого рестарта, чтобы отличить шум от дрейфа конфигурации.

Слои важны, потому что одно и то же сообщение о таймауте может прийти с разных плоскостей: RTT шлюза к upstream, колбэк IM, заблокированный корпоративным фаерволом, или зависший сокет провайдера. Помечайте инциденты в тикетах как контроль / данные / канал, чтобы постмортемы совпадали с метками времени, а не смешивали несвязанные сбои. Руководству можно дать одну строку root cause, но внутренние заметки должны фиксировать, какая плоскость упала первой.

2. Слои боли: контроль, данные, канал

1. Контрольная плоскость: при gateway.mode=remote локальный процесс может простаивать, пока вы думаете, что он обслуживает трафик; проверяйте bind, слушатели и пробы — не только runtime.
2. Плоскость данных: без фиксированного порядка обхода логов вы утонете в INFO-сердцебиениях; сначала WARN/ERROR, затем расширяйте по request id. Предпочитайте структурированный JSONL.
3. Плоскость канала: «в сети, но тихо» часто связано с правилами упоминаний, областью группы, истёкшим pairing или правами бота — сигналами, которые в doctor не всегда видны как ERROR.

Трёхслойная линза останавливает рефлекторную подстройку temperature, когда вебхук до процесса не дошёл. Команды регулярно сжигают часы на «сделать модель отзывчивее», пока в манифесте Slack или Discord не хватает одного OAuth scope — это доказательства плоскости канала, а не модели.

3. Таблица маршрутизации симптомов

В эскалациях используйте таблицу как ограждение: если curl на loopback не проходит, не ротируйте токены канала, пока слушатель не доказан. Если ЛС работает, а группы нет — оставайтесь в плоскости канала: сравните политики упоминаний, членство бота и workspace ID.

4. Пять и больше шагов: status → logs → doctor → точечные правки

Соблюдайте тот же порядок на Linux, macOS или Mac-облаке. В Docker выполняйте команды в одном namespace, чтобы не получить split-brain между хостом и контейнером. Если сравниваете хост и контейнер, запускайте openclaw doctor в обоих и сравнивайте diff только после проверки, что одни и те же конфиги смонтированы read-write там, где ожидается.

1. Базовая линия openclaw status: зафиксируйте runtime, режим шлюза, bind; при remote запишите upstream URL и health — не только «running».
2. Доказательства openclaw logs: возьмите 10 минут до/после апгрейдов; сначала WARN/ERROR, затем корреляция по request id; TLS/DNS раньше токенов.
3. openclaw doctor: сначала читайте без --fix; сделайте бэкап ~/.openclaw или смонтированных конфигов перед автоисправлением.
4. Порт 18789: найдите владеющий процесс; предпочитайте loopback плюс SSH-туннель или reverse proxy вместо сырого порта наружу.
5. Каналы: выполните probe/status команд вашей версии; перепривяжите pairing при истечении; проверьте scope бота и правила упоминаний для групп.
6. Регрессия: минимальный DM-пробник, затем инструменты, затем полный трафик.

Если инциденты повторяются еженедельно, архивируйте «эталонный» вывод status и обезличенный срез логов в runbook. Следующий дежурный сможет сравнить с базовой линией вместо гаданий, новое ли предупреждение — шум или регрессия после bump зависимости.

5. Жёсткие факты: порт, pairing, ключи логов

• 18789: типичный локальный порт шлюза по умолчанию — сверяйте с release notes; конфликты часто означают дублирующиеся экземпляры.
• TTL pairing: коды истекают; продлевайте сразу на стороне IM, чтобы не застрять в полупривязанном состоянии.
• Ключи корреляции: храните request id, channel id и коды ошибок провайдера для сверки с биллингом токенов.
• Апгрейд/откат: если после апгрейда doctor показывает пункты миграции, следуйте релизу перед даунгрейдом; сохраняйте выдержки логов для постмортемов.
• Аудит: задокументируйте пути JSONL и ротацию — часто минимум семь дней для разборов (подстройте под политику).
• Docker: если doctor расходится между хостом и контейнером, проверьте тома и uid до трогания секретов канала.
• Сдвиг часов: дрейф часов VM или контейнера ломает TLS и OAuth-подобные токены; синхронизируйте время на хосте и внутри контейнера до обвинения бинарников OpenClaw.
• Штормы ретраев: при нестабильном канале неограниченные повторы заливают логи и скрывают первую полезную строку; после восстановления рассмотрите контролируемый рестарт в окне изменений и сравните число строк до/после.
• Орг-конкурентность: несколько агентов с одного egress IP могут упереться в общий rate limit; коррелируйте 429 с другими сервисами до повышения конкурентности шлюза.

6. Mac-облако, туннели и пределы дешёвых хостов

Ноутбук и круглосуточное Mac-облако отличаются надзором, сохранением логов и поверхностью атаки. Доступ только из браузера без туннеля рвется при перезагрузках; публикация 18789 в интернет привлекает сканеры и риск ошибок конфигурации. SSH-туннели или zero-trust уменьшают blast radius, но требуют ротации ключей и логики переподключения. Windows или бюджетный Linux VPS годятся для экспериментов, но долговременная надёжность демонов, паритет toolchain и автоматизация рядом с Apple страдают. Когда нужны нативный macOS, launchd и та же лестница разборов без лишней абстракции, выделенный узел VPSMAC Mac-облака обычно предсказуемее, чем костыли на не-Mac железе. Для первой проводки продолжите пятиминутный гайд развёртывания OpenClaw на сайте — от «запустилось один раз» до «переживает дежурство».

Это сравнение намеренное: Docker на Linux может держать OpenClaw, но вы платите маппингом uid томов, двойной правдой конфигов и лишними движущими частями в инцидентах. Узел Mac-облака совпадает с тем, как операторы уже думают о путях, связке ключей и автоматизации без GUI — меньше переводов между документацией и продом.

Наконец, считайте дашборды провайдера и консоли IM частью одной цепочки доказательств: делайте скриншоты или экспортируйте графики rate limit при спорах о том, шлюз тормозил или upstream. Сопоставляйте эти экспорты с request id из JSONL, чтобы финансы, безопасность и инженеры делили одну шкалу времени, а не три противоречащие истории.

Держите статью рядом с чеклистом апгрейда: при каждом bump OpenClaw или образа шлюза прогоняйте лестницу в staging до production — даже если release notes выглядят скучно, тонкие дефолты вокруг bind и окон обновления auth всё ещё ломают воскресные выкаты.

Для сетевых команд полезно заранее согласовать, какой исходящий ASN и какой health-check URL использует шлюз: при разовых сбоях TLS это снимает половину ложных гипотез ещё до созвона с безопасностью.

Если ротация логов слишком агрессивна, сохраните хотя бы сутки WARN на диске или в агрегаторе — иначе пик ошибок исчезнет раньше, чем вы успеете сопоставить его с релизом или с деплоем в пятницу вечером.