1. Граница: неинициализированный канал, а не «тихая» модель
Руководство про тихую нерегистрацию: нет явной ошибки Telegram, но шлюз не подключает ожидаемого провайдера. Если уже видны HTTP-строки модели, 429 или зелёная проба с мёртвым чатом, начните с канал: зелёная проба, нет ответов — там объект канала есть, события теряются ниже по стеку.
При раннем сбое инициализации сообщения пользователей не попадают в очередь вызова модели, правка промпта не поможет. В тикет приложите openclaw health (или аналог) сразу после перезапуска, первые ~200 строк логов с telegram / provider / webhook / plugin и факт запуска config validate под той же UID, что у службы. Без этого набора инженеры гоняются за TLS-призраками.
2. Слойные проверки: проба, логи, validate — в таком порядке
Шаг A — channels status --probe: подтверждает, что control plane достигает Bot API с тем токеном, который процесс считает своим. Если проба падает, сначала сеть, прокси и читаемость секретов, а не массовая переписка YAML.
Шаг B — логи шлюза: после перезапуска ищите язык регистрации. Полное отсутствие строк при активных других подсистемах часто значит: конфиг не дошёл до фабрики каналов или плагин упал раньше.
Шаг C — config validate: ошибки схемы и битые пути SecretRef. Некоторые сборки проглатывают отсутствие файла секрета как «канала нет в списке» вместо громкого стека; validate дешевле tcpdump.
openclaw channels status --probe
openclaw config validate
journalctl --user -u openclaw-gateway -n 200 # пример systemd
# launchd: StandardOutPath / log stream для метки службы3. Минимизация plugins.load как рычаг A/B
Плагины, падающие при старте, при уровне логов по умолчанию могут помешать регистрации нижележащих адаптеров. Снимите снимок openclaw.json (или пути пакета), обнулите plugins.load или оставьте минимальный проверенный набор, перезапустите шлюз и проверьте, вернулся ли Telegram в health. Если да — возвращайте плагины по одному, пока не найдёте виновную комбинацию. Зафиксируйте «выигрышный» порядок для парка, чтобы следующий апгрейд не перетасовал его вслепую.
Это не тишина после регистрации: здесь маршрутизатор так и не создал объект провайдера Telegram, поэтому сообщения не доходят до инструментов и модели.
4. botToken: открытый текст, переменные окружения, SecretRef под супервизором
Три частых паттерна: токен в конфиге (быстро, небезопасно), экспортированные переменные вроде TELEGRAM_BOT_TOKEN, файловый SecretRef на рантайме. Под systemd --user доминируют: EnvironmentFile= не применён до ExecStart, забыли daemon-reload после правки юнита, другой пользователь, чем интерактивная оболочка — отсюда ручной openclaw gateway ок, а надзорный перезапуск видит пустой токен и тихо пропускает Telegram.
Используйте systemctl --user show <unit> -p Environment (или аналог launchd launchctl print), чтобы доказать наличие токена до обвинений в сбоях выше по цепочке. Выровняйте HOME с деревом учётных данных из материалов установки и doctor, чтобы относительные пути SecretRef после перезагрузки разрешались одинаково.
5. Ротация токена и устаревшие webhook
Когда BotFather меняет токен, старый может держать webhook URL на мёртвый endpoint. Рекомендуемая цепочка: остановить шлюз → вызвать Telegram deleteWebhook с новым токеном (или ваш CLI-обёртку) → убедиться, что getWebhookInfo чист или соответствует текущему ingress → запустить шлюз и повторить сопряжение по релизным заметкам. Пропуск deleteWebhook даёт локально «всё настроено», пока Telegram шлёт на URL без ответа — зачастую с малым шумом на клиенте.
При переключении long polling и webhook следуйте release notes; смешение режимов без полной остановки даёт гонки, похожие на тихую инициализацию.
6. Дополнительные материалы
Базовая установка и doctor: OpenClaw: установка и устранение неполадок 2026. Сопряжение и версии после апгрейдов: отключённый шлюз и runbook сопряжения. После регистрации Telegram вернитесь к зелёная проба / нет ответа для троттлинга модели и ошибок двойных переключателей, и к установка и переустановка демона, launchd, systemd, linger для гигиены юнитов.
7. FAQ
Почему логи выглядят «пустыми»
Пока провайдер не зарегистрирован, меньше структурированных хуков. Временно повысьте детализацию или сделайте однократный отладочный перезапуск, чтобы окно сбоя попало в ретенцию.
Slack работает, в health нет только Telegram
Сфокусируйтесь на секретах Telegram, файлах SecretRef и состоянии webhook. Глобальная ошибка шлюза обычно ломает все мессенджеры.
Это то же, что утечки MCP stdio после перезапуска
Нет. Утечки транспорта могут голодать завершения после трафика; статья про адаптеры, которые не подключаются. Если в логах есть доставки Telegram, а инструменты висят, перейдите к runbook MCP и перезапуска шлюза во внутреннем индексе.