Webhook или long polling: как Telegram-бот получает сообщения
Любой бот должен как-то узнавать, что ему написали. Способов ровно два: спрашивать сервер самому (long polling) или попросить, чтобы сервер стучался к вам (webhook). Выбор влияет на хостинг, задержки и то, насколько больно будет отлаживать. Разложим по полочкам.
Два способа, никаких других
Telegram не держит постоянного соединения с вашим ботом. Поэтому апдейты доставляются одним из двух способов, и включить можно только один за раз: либо бот сам периодически спрашивает «что новенького?» (long polling), либо Telegram сам присылает события на ваш HTTPS-адрес (webhook).
Long polling: бот ходит за апдейтами сам
Бот вызывает getUpdates. Telegram держит соединение открытым до timeout секунд и отвечает, как только появляется событие — или пустым списком по таймауту. Затем бот спрашивает снова. Отсюда «long»: это не агрессивный опрос каждую секунду, а ожидание на стороне Telegram.
curl "https://api.telegram.org/bot$BOT_TOKEN/getUpdates?timeout=30&offset=$NEXT"
Ключевой нюанс — offset. Каждый апдейт имеет update_id. Передав offset = последний_update_id + 1, вы подтверждаете обработку: Telegram больше не пришлёт эти апдейты. Не подтвердили — получите их снова. Это и спасает (не теряются при падении), и подводит (дубликаты, если подтвердить раньше, чем обработали).
Плюсы: не нужен белый IP, домен и сертификат; запускается где угодно, хоть с ноутбука; легко отлаживать. Минусы: один процесс = один потребитель; масштабировать сложнее; чуть выше задержка и расход на холостые запросы.
Webhook: Telegram стучится к вам
Вы один раз говорите Telegram адрес, и он шлёт туда POST на каждое событие:
curl "https://api.telegram.org/bot$BOT_TOKEN/setWebhook" \
-d "url=https://example.com/tg/secret-path" \
-d "secret_token=$WEBHOOK_SECRET"
Требования жёсткие: только HTTPS, валидный сертификат, ответ за отведённое время. secret_token Telegram кладёт в заголовок X-Telegram-Bot-Api-Secret-Token — проверяйте его, иначе ваш эндпоинт сможет дёрнуть кто угодно. Если ответите ошибкой или слишком долго — Telegram повторит доставку.
Плюсы: минимальная задержка; ноль холостых запросов; естественно масштабируется за балансировщиком. Минусы: нужен публичный HTTPS-эндпоинт; локальная отладка больнее (нужны туннели вроде ngrok); чужие/повторные запросы надо фильтровать.
Что выбрать
| Критерий | Long polling | Webhook |
|---|---|---|
| Публичный домен и сертификат | не нужен | обязателен |
| Задержка | секунды | миллисекунды |
| Отладка локально | просто | нужен туннель |
| Масштабирование | руками | естественно |
| Когда брать | разработка, малый бот | прод, нагрузка |
Практичный совет: начинайте на polling — проще запустить и поймать первые баги. Переезжайте на webhook, когда упрётесь в задержку или захотите несколько инстансов. Переключение — это вызвать setWebhook (или deleteWebhook, чтобы вернуться к polling), код обработчиков почти не меняется.
Частая ошибка. Поставили webhook, но бот всё равно зовёт getUpdates в цикле — Telegram возвращает ошибку «can't use getUpdates while webhook is active». Включено что-то одно. И наоборот: забыли снять старый webhook — polling молчит.
А как с этим работает аналитика
MaxBotStat подключается на стороне вызовов Bot API, которые делает бот. При long polling через прокси проходит и getUpdates — видно обе стороны диалога без настроек. При webhook входящие идут напрямую к вам, мимо прокси, но исходящие (sendMessage и т.д.) всё равно учитываются — контакты и рассылки собираются. Рекомендованные схемы для полной картины на webhook — в документации.
Какой бы способ вы ни выбрали — аналитика подключается одной строкой. Попробуйте бесплатно.
Открыть кабинет →