Диагностика Telegram в n8n: webhooks, токены и лимиты ¶

Обновлено: 2026-05-29

Короткий ответ ¶

Если Telegram bot в n8n не отвечает, сначала проверьте токен BotFather, режим получения событий и доступность HTTPS URL. У Telegram не должно быть конфликта между старым webhook, новым Telegram Trigger и polling; один бот не может одновременно корректно обслуживаться несколькими активными обработчиками. Затем проверьте, что workflow активирован, используется production URL, команда /start попадает в execution, а ответ отправляется в правильный chat_id.

Как Telegram связан с n8n ¶

В n8n Telegram-бот обычно работает по одной из двух схем.

Первая схема — Telegram Trigger. Она удобна, когда вы хотите получать сообщения, команды, callback query и другие события прямо в workflow. n8n сам настраивает обработчик, а вам остаётся маршрутизировать входящие update.

Вторая схема — обычный Webhook node плюс Telegram Bot API. Такой вариант выбирают, если нужен полный контроль над endpoint, валидацией, подписью, промежуточной очередью или если бот уже встроен в существующую backend-архитектуру.

Проблемы начинаются, когда одновременно остаются следы нескольких схем: старый webhook от предыдущего сервера, тестовый tunnel, активный workflow в другом n8n, polling-скрипт на VPS и новый Telegram Trigger. Бот “молчит” не потому, что Telegram сломался, а потому что update уходят не туда.

Быстрая диагностика по симптомам ¶

Симптом	Вероятная причина	Что проверить первым
Бот не отвечает на `/start`	workflow не активирован, update не приходит, неверный token	executions и BotFather token
В n8n нет execution	Telegram отправляет update на другой webhook	`getWebhookInfo`
Execution есть, но ответа нет	неверный `chat_id` или не та ветка IF/Switch	выход Telegram node
Ошибка webhook conflict	старый webhook или другой обработчик уже подключён	сброс webhook
Команды не распознаются	текст команды приходит с username бота или пробелами	нормализация command
Ошибка 429	слишком много сообщений за короткое время	rate limit и retry
Работало в test, не работает в production	workflow не активирован или используется test URL	production URL и active workflow

Шаг 1. Проверьте токен и бота ¶

Начните с самого простого: токен должен быть от нужного бота. Если у вас несколько тестовых ботов, легко вставить token от старого BotFather-диалога.

Безопасная проверка через Telegram Bot API:

curl "https://api.telegram.org/bot<TELEGRAM_BOT_TOKEN>/getMe"

В ответе должно быть имя именно того бота, с которым вы переписываетесь. Не публикуйте эту команду с реальным token в тикетах, логах и скриншотах.

Если token был скомпрометирован, перевыпустите его в BotFather и обновите credential в n8n. После замены token проверьте старые workflow: они могут продолжать использовать старый credential.

Шаг 2. Проверьте webhook Telegram ¶

Если update не доходят до n8n, проверьте, куда Telegram сейчас отправляет события:

curl "https://api.telegram.org/bot<TELEGRAM_BOT_TOKEN>/getWebhookInfo"

Обратите внимание на поля url, pending_update_count и last_error_message. Если в url старый домен, tunnel, IP или endpoint другого проекта, Telegram отправляет события не в текущий workflow.

Чтобы сбросить старый webhook:

curl "https://api.telegram.org/bot<TELEGRAM_BOT_TOKEN>/deleteWebhook"

После этого активируйте нужный workflow в n8n заново. Если используете Telegram Trigger, не держите параллельно другой polling-скрипт или другой активный n8n-инстанс с тем же bot token.

Шаг 3. Test URL против production URL ¶

В n8n важно различать тестовый и production-режим. Пока вы нажимаете Execute workflow или слушаете test trigger, всё может работать. Но после закрытия редактора бот перестаёт отвечать, если workflow не активирован.

Проверьте:

workflow включён переключателем Active;
используется production URL, а не test URL;
домен доступен по HTTPS из интернета;
reverse proxy не возвращает 404 или 502;
WEBHOOK_URL у self-hosted n8n указывает на внешний домен.

Для Telegram production-сценария не подходит URL вида localhost, локальный IP или временный tunnel, который выключится через час.

Шаг 4. Execution есть, но бот не отвечает ¶

Если входящее сообщение видно в execution, значит Telegram → n8n работает. Дальше ищите проблему в логике ответа.

Проверьте, какой chat_id вы передаёте в Telegram node. Обычно его берут из входящего update, а не прописывают вручную:

{{$json.message.chat.id}}

Но структура payload может отличаться для обычного сообщения, callback button, edited message или channel post. Для callback query chat_id часто лежит глубже, например через callback_query.message.chat.id. Поэтому для кнопок и команд лучше делать отдельные ветки обработки.

Также проверьте parse mode. Если отправляете MarkdownV2, некоторые символы нужно экранировать. Иногда бот “не отвечает”, хотя Telegram node падает из-за неэкранированного _, *, [ или ).

Шаг 5. Команды `/start`, `/help`, `/status` ¶

Командный роутер лучше не строить на одном точном сравнении без нормализации. Telegram может прислать:

/start;
/start payload;
/start@your_bot_name;
текст с пробелом в конце;
команду в группе, где нужен username бота.

Сначала нормализуйте текст: trim, lower-case, отделение команды от аргументов. Затем отправляйте в Switch или IF.

Пример логики:

Команда	Что отвечает бот
`/start`	краткое приветствие и список возможностей
`/help`	команды и формат сообщений
`/status`	проверка, что workflow жив и видит пользователя
неизвестная команда	fallback с подсказкой

Fallback обязателен. Без него пользователь пишет сообщение, execution проходит, но внешне кажется, что бот молчит.

Шаг 6. Ошибка 429 и задержки ¶

Telegram может ограничивать частоту отправки сообщений. Если workflow рассылает много ответов подряд, добавьте паузы, пакетную обработку, retry с backoff и отдельную ветку для ошибок.

Особенно аккуратно обрабатывайте сценарии:

массовая рассылка;
бот отвечает на каждое сообщение в активной группе;
AI-бот отправляет несколько длинных сообщений;
workflow повторяет запрос после timeout;
один и тот же update обрабатывается дважды.

Для production-бота нужна защита от дублей: сохраняйте update_id, message_id или собственный idempotency key, чтобы не отвечать повторно на одно и то же событие.

Что логировать для Telegram-бота ¶

Для каждой ошибки сохраняйте:

время;
bot username без token;
workflow name;
execution ID;
update_id;
тип события: message, command, callback_query;
chat_id;
текст команды без персональных данных;
ответ Telegram API;
причину и исправление.

Не сохраняйте полный token, приватные сообщения пользователей и лишние payload, если они не нужны для диагностики.

Чего не делать ¶

Не используйте один token в нескольких активных инстансах n8n. Не оставляйте старый webhook после переезда домена. Не отвечайте пользователю без проверки chat_id. Не отправляйте длинные AI-ответы одним сообщением без обработки ошибок форматирования. Не делайте бесконечный retry при 429: это только усилит ограничение.

FAQ ¶

Почему Telegram Trigger ждёт событие, но ничего не происходит?
Возможно, update уходят на старый webhook, workflow не активирован, используется test mode или token принадлежит другому боту.

Как проверить, куда Telegram отправляет сообщения?
Выполните getWebhookInfo для bot token. В поле url будет текущий webhook, если он установлен.

Можно ли использовать webhook и polling одновременно?
Для одного bot token лучше выбрать один способ обработки. Параллельные обработчики часто приводят к конфликтам и потерянным update.

Почему execution есть, но пользователь не получает ответ?
Проверьте chat_id, ветку IF/Switch, parse mode и ошибку Telegram node. Для callback buttons путь к chat id отличается от обычного сообщения.

Что делать с ошибкой 429?
Снизить частоту отправки, добавить паузы, retry с backoff и защиту от повторной обработки одного update.