OpenClaw 2026: настройка каналов
Slack, Discord и Telegram — права, OAuth и триаж «подключено, но тишина»

Шесть симптомов каналов: «подключено», но мёртво

Проблемы каналов часто ошибочно относят к «сломалась модель» или «опять compose». Прежде чем менять образы или network_mode, опишите поведение списком ниже и сравните с таблицей триажа Docker-сети, чтобы две параллельные правки не стёрли первопричину.

1. Нет входящих событий: админка показывает online, но новые сообщения в канале не дают строк в логах Gateway — обычно выключены подписки Slack на события, не хватает Gateway intents у Discord или режим приватности Telegram блокирует группы.
2. Только ЛС, без каналов: OAuth scopes или политика присоединения бота покрывают только DM; сообщения в каналах отбрасываются без шума — проверьте списки каналов и членство бота.
3. Парсит команды, но не отвечает: входящие логи есть; ответы режутся groupPolicy, правилами тредов или политикой «только по упоминанию» — часто маршрут в пустого агента или отказ в правах.
4. Прерывистое истечение OAuth/token: всё зелёное в консоли, через несколько часов красное — обычно refresh-токены не записались в хранилище секретов или контейнеры перезапустили без того же монтирования .env.
5. Перепутанные workspace или guild: один процесс держит несколько workspace Slack или серверов Discord; слитые конфиги ведут callbacks на неверный URL.
6. Ложное обвинение модели: каналы в порядке, но ответы 429/5xx от провайдера создают впечатление «бот умер» — сравните доли логов Gateway и провайдера и вернитесь к статье про failover.

Фиксируйте эти шесть классов вместе с недавними правками allowedOrigins и выкатами образов в одном тикете дежурства, чтобы за пять минут выбрать ветку расследования.

Таблица 1: трёхуровневый триаж — Gateway, каналы или модель?

Матрица задаёт, какой слой смотреть первым; она не исключает остальные. Каждая строка должна сопоставляться с конкретной командой или ключевым словом в логах. На бумаге разметьте три колонки: симптом для пользователя, первая аномалия в логах Gateway и HTTP-коды модели. Если средняя колонка пуста — пауза перед троганием провайдеров; если справа сначала 429, десять повторных OAuth не исправят биллинг.

Вместе со статьёй про Docker-сеть считайте провалившиеся внутри контейнера пробы каналов уровнем 0: убедитесь, что CLI в той же сети compose достигает Gateway, прежде чем использовать таблицу; иначе консоль webhook Slack выглядит здоровой, а на хосте — только таймауты.

Три KPI каналов для дашборда

Эти метрики превращают «бот завис» в числа для алертов; имена полей согласуйте с логированием Gateway. Предпочтительны часовые агрегаты, а не шум посекундно, чтобы ночные пейджеры оставались осмысленными.

1. Inbound event rate (IER): число подтверждённых каналом событий, делённое на отправки со стороны бизнеса за окно; устойчиво ниже 0.9 указывает на OAuth и подписки, а не на GPU.
2. Routing hit rate (RHR): доля входящего трафика, привязанного к нужному агенту; если IER в норме, а RHR падает — прогнили политики или карты каналов.
3. Reply completion rate (RCR): сквозной успех от входа до HTTP 200 от модели; если IER и RHR высоки, а RCR низок — в приоритете слой модели.

В документации сообщества в 2026 году по-прежнему акцент на openclaw channels status --probe; стройте результаты проб рядом с этими тремя долями, чтобы не опираться на невоспроизводимые «переподключи и надеись». Если HTTP-пробы из статьи про health-check Gateway уже настроены, убедитесь, что URL проб идут тем же reverse-proxy путём, что и реальные callbacks каналов: пробы только на loopback при публичных callbacks на другой цепочке сертификатов дают «все мониторы зелёные, все пользователи красные».

Добавьте привычку ручной сверки: раз в неделю выборочно десять пользовательских сообщений и проверка, что ID сообщения платформы, request ID Gateway и trace ID модели проходят сквозь логи; если звеньев не хватает — сначала чините структурированное логирование, потом масштабирование.

Шестишаговый runbook: от проб до обратимых изменений OAuth

1. Ограничьте зону поражения: зафиксируйте теги образов, хэши env и последние три изменения compose — регрессии каналов часто приходят с rolling-релизами. Если в тот же день менялись allowedOrigins или TLS, опишите откат к предыдущему отпечатку сертификата, чтобы OAuth callbacks и CORS не ломались одновременно.
2. Базовая линия Gateway: убедитесь, что gateway status на хосте или в контейнере совпадает с гайдом doctor. При systemd или launchd проверьте политики перезапуска — частые рестарты бьют по rate limit WebSocket каналов на стороне платформ.
3. Авторизация по платформам: Slack — повтор OAuth и scopes; Discord — включить intents и заново пригласить бота; Telegram — настроить приватность в BotFather или обеспечить @ в группах. После авторизации дождитесь TTL кэша платформы (часто 5–15 минут); не спамьте десятью попытками re-auth.
4. Докажите минимальный диалог: один канал, один агент, без лишних политик для теста ping-pong, затем снова включайте groupPolicy. Префиксируйте тестовые сообщения для удобного grep, а не шум в публичных каналах.
5. Сравните с моделью: если ping-pong не проходит, за 30 секунд логов оцените долю 429 перед сменой провайдера. Если 429 кластеризуются на одном ключе, проверьте, не смешаны ли consumer-ключи с pay-as-you-go.
6. Зафиксируйте runbook в репозитории: ротация токенов и пути к секретам — в том же репо, что и заметки по Docker-сети, чтобы релиз не зависел от одного ноутбука. Коллабораторам — минимальные read-only scopes; мастер-ключи — в KMS или sealed secrets.

Быстрые проверки Slack, Discord и Telegram на одной странице

Выполняйте по консоли каждого вендора; не доверяйте устаревшим скриншотам. Если ведёте staging и production workspace, добавьте колонку hostname callback, чтобы staging-сертификаты не привязались к prod DNS.

• Slack: валидны и app-, и bot-токены; URL подписок на события указывают на публичный Gateway, который реально запущен; Socket Mode и HTTP не смешаны случайно. В Enterprise Grid убедитесь, что установка в каждом workspace ссылается на один OAuth client, иначе часть регионов не получит события.
• Discord: Message Content Intent и Server Members соответствуют задачам; бот виден в целевых каналах; переопределения каналов не запрещают отправку. Используйте встроенную диагностику прав Discord, а не только имена ролей.
• Telegram: webhook или long polling — выберите одно; сертификаты и callback URL не должны уезжать после rolling-релизов; в группах под приватностью могут требоваться явные упоминания. Самоподписанные сертификаты всё равно должны открывать порты и версии TLS, которые ожидает Telegram; ротацию сертификатов выносите в отдельное окно изменений.

Все три платформы чувствительны к стабильным исходящим IP. Домашний интернет или VPN с сменой exit-узлов выглядят как злоупотребление webhook. Это согласуется с гайдом по мультирегиональному облачному Mac о фиксированных регионах и аудируемом egress — перенесите control plane на хост с доказуемой достижимостью, прежде чем команда будет зависеть от бота.

Почему личный ноутбук не тянет командный масштаб OpenClaw по каналам

Сон, VPN и локальные прокси меняют egress IP и отпечатки TLS, из‑за чего OAuth callbacks и allowlist вендоров падают случайно. На общем ноутбуке нельзя централизовать ротацию токенов и поля аудита. Запускайте Gateway и воркеры каналов на стабильной дежурной плоскости исходящего трафика, чтобы согласоваться с командными политиками агентов.

Для топологий с круглосуточным сервисом, фиксированными callback-доменами и предсказуемым egress у MACCOME есть облачные хосты Mac mini M4 / M4 Pro в Сингапуре, Японии, Корее, Гонконге, US East и US West — удобно для Gateway и инструментов Apple. После триажа каналов сочетайте с гайдом SSH против VNC и центром помощи, продлевая аренду по публичным тарифам и региональным страницам.

Пилот: 24 часа IER и RCR на выделенном тестовом хосте с одним каналом перед открытием production workspace — не включайте сразу большое сообщество «в красную зону».