Почему бот не отвечает в Телеграм

Почему бот не отвечает в Телеграм – причины, диагностика и решение

Токен и BotFather – валиден ли токен, не отозван ли, настроены ли /setcommands и /setprivacy

Откройте BotFather и проверьте, что токен актуален и вы не делали недавно /revoke (отзыв токена). Сверьте /setcommands и нужный scope (область: по умолчанию/для групп/для лички) с тем, что зашито в коде. Убедитесь, что /setprivacy соответствует сценарию: Enabled для команд или Disabled, если нужно читать обычные сообщения. Несоответствие токена/команд/локалей часто даёт «тишину» без ошибок.

Когда токен, команды, scope и privacy приведены в порядок, проверьте конверсию на малыx волнах реального трафика: аккуратная накрутка подписчиков тг небольшими партиями поможет быстро замерить отклик на команды, p95 ответа и долю целевых действий. Подавайте равномерно 30–60 минут, сравните метрики до и после и зафиксируйте безопасный темп.

Канал апдейтов – webhook или long polling, не запущены ли оба одновременно

Определите один способ приёма событий: либо webhook (веб-хук), либо long polling (опрос). Два канала одновременно дают 409 Conflict и дубли. Для опроса остановите веб-хук через deleteWebhook?drop_pending_updates=true, для веб-хука остановите поллер. Это базовая проверка, которая экономит часы дебага.

Webhook статус – getWebhookInfo, есть ли last_error_message, отвечает ли хук 200 OK < 10 c

Выполните getWebhookInfo и посмотрите поля url, last_error_message, max_connections. Если есть TLS/timeout/wrong response, лечите сеть и обработчик. Ваш хук должен возвращать 200 OK быстро (лучше до 2 секунд, максимум 10 секунд) и без редиректов. После фикса снимите веб-хук с drop_pending_updates и зарегистрируйте заново.

Права и контекст чатов – бот не заблокирован, есть права писать, в группе команда как /cmd@YourBot

Проверьте, что бот не заблокирован пользователем и имеет право «писать» в нужной группе/канале. В группах с включённым Privacy Mode команды вызывают формой /cmd@YourBot, иначе бот их не увидит. Для каналов бот должен быть админом, иначе публикации не пройдут. Это простые причины «немоты», которые правятся за минуты.

Быстрый тест – напишите боту в личку и в тестовую группу, посмотрите логи апдейтов

Отправьте /start в личку и тестовую команду в чистую группу без ограничений. Включите расширенный лог апдейтов: update_id, chat_id, type, handler, duration_ms, reply_status. Если в логах пусто – проблема в доставке апдейтов, если есть – в логике/правах. Такой тест отделяет «сеть/настройки» от «кода» за пару минут.

Бот не реагирует на команды – ключевые категории проблем

Неверный токен или сбитые настройки BotFather

Отозванный токен, неверный scope команд или несоответствие локалей ломают автодополнение и триггеры. Всегда обновляйте токен в переменных окружения и перезапускайте воркеры после /revoke. Храните команды в репозитории и заливайте их автоматически на релизе. Это снижает риск «тихих» отказов.

Апдейты не доходят – ошибки вебхука или polling

Два канала одновременно, редиректы, неверный сертификат или медленный ответ блокируют доставку. Проверьте getWebhookInfo и скорость ответа обработчика, а при опросе – timeout/offset. Временно включите polling, чтобы исключить сеть/TLS и проверить логику хэндлеров. Этот приём быстро локализует проблему.

Недостаточные права и ограничения чатов

Без права «писать/медиа/закреплять» бот в группе будет «молчать», даже если код верный. В супергруппах могут мешать slow mode и антиспам-фильтры. В личке пользователь должен написать первым – иначе 403 Forbidden. Всегда начинайте с проверки прав и формы вызова команды.

Ошибки в коде и зависания воркера

Непойманные исключения и блокирующие вызовы приводят к «тихому» падению. Добавьте глобальный перехват ошибок и обратите внимание на очереди/латентность. Вынесите тяжёлые операции во внешние воркеры или очереди. Перезапуск по watchdog возвращает доступность до фикса.

Лимиты и формат сообщений Bot API

400/401/403/409/413/429 и 5xx встречаются чаще, чем кажется. Валидируйте JSON и длины полей, экранируйте Markdown/HTML, следите за размерами файлов. На 429 включайте бэкофф (повтор с паузами и джиттером) и снижайте частоту. Это избавляет от невидимых блокеров.

Почему бот не работает в Телеграм – токен и настройки BotFather

Отозванный токен – как перевыпустить и обновить переменные окружения

Если делали /revoke, старый ключ перестаёт работать мгновенно. Получите новый /token у BotFather и обновите секреты в env/CI/CD. Перезапустите сервисы и убедитесь, что нет старых контейнеров со «старыми» переменными. Рассинхрон токенов – топ-причина «тишины».

Когда токен синхронизирован и вебхук стабилен, проверьте доставку постов на реальном трафике: аккуратная накрутка просмотров телеграм малыми волнами даст первичные сигналы по скорости появления показов, CTR и дочитываниям. Подавайте равномерно 30–60 минут, сравните метрики до и после и зафиксируйте безопасный темп для последующих публикаций.

Privacy Mode и работа в группах – когда нужен /setprivacy disabled

Включённый Privacy Mode скрывает обычные сообщения, бот видит только команды со слэшем. Если сценарий требует читать фразы – переключите /setprivacy на Disabled. Помните, что отключение приватности требует фильтров по чатам/ролям. Так вы избежите «шума» и жалоб.

Команды и меню – корректный /setcommands для лички и групп, локали, описания

Поддерживайте два набора команд: для лички и для групп (scope у BotFather). Проверьте локали описаний – клиент подхватывает язык пользователя. Названия команд должны совпадать с кодом и подсказками. Это возвращает автодополнение и снижает ошибки запуска.

Webhook не работает – TLS, DNS, редиректы, 200 OK

setWebhook – один бот – один URL, валидный HTTPS без self-signed

Регистрируйте веб-хук на публичном HTTPS-домене с доступом из интернета. Не держите параллельно polling, иначе будет 409. При миграциях снимайте хвост drop_pending_updates=true, чтобы не ловить лавину старых событий. Это сокращает время восстановления.

Сертификат и цепочка – SNI, CN, срок действия, промежуточные CA

Сертификат должен соответствовать домену (CN/SAN), цепочка должна быть полной (intermediate присутствуют), SNI настроен. Просроченные или самоподписанные сертификаты приводят к «тихому» молчанию. Проверка одной командой:

echo | openssl s_client -servername your.domain -connect your.domain:443 -showcerts 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Сверьте issuer/subject/dates и что CN/SAN совпадает с доменом.

Диагностика – getWebhookInfo, логи сервера, проверка cURL

Посмотрите getWebhookInfo: пустой ли last_error_message, нет ли timeout/TLS/wrong response. Проверьте серверные логи и попробуйте curl -i https://your.domain/bot-hook – нужен быстрый 200 OK без редиректа. После фикса снимите веб-хук и поставьте заново, очистив отложенные апдейты. Повторная проверка должна показать пустой last_error_message.

Long polling не получает апдейты – offset и конкуренция воркеров

Конфигурация getUpdates – timeout, limit, корректный offset

Задайте timeout=25–30 и храните last_update_id, двигая offset на +1. Следите за limit, чтобы не плодить пустые запросы и не упираться в лимиты. Такой режим экономит ресурсы и стабилизирует поток событий. Это база для дев-сред и отладки.

Дубли и пропуски – идемпотентность, хранение last_update_id

Идемпотентность (повтор безопасен) и таблица/Redis для уже обработанных update_id закрывают дубли. Фиксируйте побочные действия (платёж/выдача) только после отметки «обработано». Это убирает «призраков» при ретраях и перебоях сети. Простая техника, а пользы много.

Переход webhook ↔ polling – deleteWebhook с drop_pending_updates

Всегда снимайте веб-хук с drop_pending_updates=true перед запуском polling и наоборот. Держите одну точку приёма апдейтов – иначе получите 409 и дубли. Зафиксируйте порядок переключений в runbook, чтобы команда не путалась. Это исключает «гонки» на входе.

Бот не отвечает в группе – проверяем Privacy Mode и права

Команды в группах – форма /команда@YourBot и необходимость упоминания

Включённый Privacy Mode требует явного обращения /команда@YourBot или reply на сообщение бота. Иначе команду «не видно» и реакция не придёт. Объясните это пользователям в описании или закрепе. Это простая настройка, которая снимает половину вопросов.

Права администратора – читать, удалять, закреплять, отправлять медиа

Проверьте права «Отправлять сообщения/медиа», «Закреплять/Удалять», если сценарий это требует. В каналах без админки бот не публикует по правилам платформы. После выдачи прав перезапустите бот, чтобы кэш ролей обновился. Это самая частая быстрая победа.

Ограничения супергрупп – slow mode, фильтры, запрет ботов

Супергруппы нередко включают slow mode и антиспам, ограничивающие частоту и ссылки. Проверьте, не попадает ли бот под фильтры или запреты на приглашения. Тестируйте те же команды в песочнице без ограничений – так вы отделите политику группы от кода. При необходимости согласуйте исключения с владельцами чата.

Бот не отвечает в личке – PM и ограничения пользователя

Пользователь не инициировал диалог – правило «первого сообщения»

В PM боту нельзя писать первым – пользователь должен начать диалог. Дайте пользователю понятную инструкцию «нажмите Start/напишите /start», это снимает 403. Не шлите повторно в заблокированный чат – это тратит лимиты и ухудшает траст. Это правило по дизайну, его не обойти кодом.

Блокировка 403 – как корректно обработать и не спамить

Если получили 403 Forbidden, прекратите попытки отправки в этот чат. Предложите альтернативный канал связи в FAQ/описании. Логируйте такие случаи, чтобы не повторять попытки. Это экономит лимиты и нервы.

Ограничения частоты – 429, флуд-контроль, очереди и бэкофф

429 Too Many Requests означает, что вы упёрлись в лимит частоты. Включите очереди и экспоненциальный бэкофф с джиттером, сократите частоту ответов. Группируйте похожие реплики и шлите один итог вместо десяти. Так вы не перегреете лимиты и сохраните доставку.

Лимиты и ошибки Bot API – где тонко

400 – неверные параметры, кодировки, markdown – как валидировать payload

Проверяйте Content-Type: application/json, длины полей и экранирование Markdown/HTML. Валидируйте эмодзи и RTL-текст, чтобы не ловить «тихие» 400. Тестируйте длинные подписи и кнопки заранее. Это избавляет от ночных «падений» без стека ошибок.

401/403 – неверный токен, нет прав, пользователь заблокировал

401 = токен неверный/отозван – обновите ключ в окружении и перезапустите сервисы. 403 = нет прав/пользователь заблокировал – проверьте права/попросите пользователя написать первым. Не ретратьте одно и то же сообщение – это выглядит как спам. Логируйте код/место возникновения для быстрого поиска.

409/413/429/5xx – конфликт каналов, большие файлы, rate limit, сбои апстрима

409 = одновременно включены polling и веб-хук – снимите один канал. 413 = файл слишком большой – сжимайте/режьте и отправляйте как документ. 429 = превышен лимит – очереди, бэкофф, снижение частоты и батчинг. 5xx = сбой апстрима (внешний шлюз/сервер) – ретраи и мониторинг времени ответа.

Логика и код бота – частые баги

Непойманные исключения и «тихий» краш воркера

Добавьте глобальный перехват ошибок и алерты на падения процессов. Проверьте перезапуск воркеров по watchdog и ресурсы контейнеров. Логируйте стек и входящие данные для ускорения поиска причины. Это возвращает бота «в эфир» до больших правок.

Неполные хэндлеры – забытые callback_query, edited_message, channel_post

Убедитесь, что вы подписаны на типы событий, которые реально приходят: message/command, callback_query, edited_message, channel_post. Добавьте заглушки и лог на неожиданные типы, чтобы не «падать» молча. Это убирает «слепые зоны» и делает реакцию предсказуемой. Список типов проверьте по документации Bot API.

Блокирующие операции – отсутствие асинхронщины, таймауты внешних вызовов

Перенесите внешние вызовы и тяжёлые вычисления в очереди/воркеры. Поставьте таймауты и ретраи с джиттером, чтобы не блокировать веб-хук. Ограничьте параллелизм, чтобы не ловить 429 и дедлоки. Это поднимет стабильность и снизит задержки.

Интеграции и внешние сервисы – узкие места

Ключи и квоты внешних API – 4xx/5xx, истёкшие токены

Проверьте валидность ключей и квоты у партнёров, следите за SLA. Ловите 4xx/5xx и отвечайте «мягкой» деградацией функционала, а не молчанием. Держите статус-страницы провайдеров под рукой. Так вы не «роняете» бота из-за чужих сбоев.

Ретраи и circuit breaker – защита от флаппинга

Включите экспоненциальный бэкофф и circuit breaker (автовыключатель запросов) на нестабильных направлениях. Сообщайте пользователю понятный текст при деградации, а не «пустоту». Это экономит лимиты и нервы. Не бойтесь временно отключать вторичные функции.

Санитизация входящих данных – валидация схем и антиинъекции

Валидируйте входящие JSON/формы по схеме и экранируйте спецсимволы. Не доверяйте длинам и типам «по документации» – проверяйте. Санитизируйте Markdown/HTML в кнопках и подписях. Это снижает риск XSS и «тихих» 400.

Таблица – Симптом → Причина → Что проверить

Карта быстрых проверок и действий для команды инцидента

Примеры команд и проверок для разработчика

Webhook – setWebhook, getWebhookInfo, deleteWebhook

curl -s https://api.telegram.org/bot<TOKEN>/getWebhookInfo
curl -s -F "url=https://your.domain/bot-hook" https://api.telegram.org/bot<TOKEN>/setWebhook
curl -s "https://api.telegram.org/bot<TOKEN>/deleteWebhook?drop_pending_updates=true"

Polling – getUpdates с offset, быстрый ручной тест

curl -s "https://api.telegram.org/bot<TOKEN>/getUpdates?timeout=30"

Healthcheck эндпоинтов и метрик – latency, error rate, queue depth

Health: GET /bot-hook/health должен возвращать 200 OK, версию билда и uptime. Мониторьте p95/p99 latency веб-хука, долю 5xx и событие «getWebhookInfo.last_error_message != пусто» с алертом. Следите за глубиной очередей и временем обработки, чтобы вовремя масштабировать воркеры. Такие сигналы сокращают MTTR и снимают риски.

Чеклисты – перед релизом и при инциденте

Перед релизом – токен, команды, privacy, права, лимиты, мониторинг

Токен обновлён и един в dev/stage/prod, /setcommands и /setprivacy соответствуют сценарию. Веб-хук даёт быстрый 200 OK, TLS цепочка полная, SNI/CN верные. Выбран один канал апдейтов (webhook или polling), второй гарантированно выключен. Мониторинг и алерты настроены, логи включены.

При инциденте – зафиксировать канал апдейтов, включить логи, откат/перезапуск, временный polling

Зафиксируйте, что сейчас активно (webhook или polling), и выключите второй канал. Включите расширенный лог, перезапустите воркеры/контейнер и проверьте токен. При сетевых/TLS проблемах временно перейдите на polling и чините веб-хук. После фикса верните веб-хук и убедитесь, что last_error_message пустой, а p95 в норме.

FAQ – PAA и заголовки в формулировках пользователей

Почему бот не работает в телеграм после деплоя – что проверить первым

Проверьте токен в окружении, выберите один канал апдейтов и проверьте getWebhookInfo. Убедитесь, что веб-хук даёт 200 OK без редиректов и что сертификат валиден. Посмотрите логи хэндлеров и включите polling на время проверки. Это отделит «сеть» от «кода» за 5 минут.

Бот не отвечает в группе – как отключить Privacy Mode и выдать права

В BotFather выполните /setprivacy и переключите режим на Disabled, если нужно читать обычные сообщения. Выдайте боту права «писать/медиа/закреплять» в нужной группе. Просите вызывать команды формой /cmd@YourBot, если приватность оставили включённой. После изменений перезапустите процесс, чтобы обновить кэш ролей.

Ошибка 409 при setWebhook – что это и как исправить

Это конфликт каналов: одновременно включены webhook и polling. Снимите веб-хук с drop_pending_updates=true или остановите поллер, оставив один канал. Проверьте .env переменную режима и процессы на всех инстансах. После стабилизации верните необходимый режим и проверьте getWebhookInfo.

Как понять, что проблема в сертификате, а не в коде

Если last_error_message указывает на TLS/timeout/wrong response, ищите проблему в сети/сертификате/веб-сервере. Проверьте цепочку и SNI командой openssl s_client, затем повторите тест getWebhookInfo. Если polling получает апдейты, а веб-хук нет – код, скорее всего, ни при чём. После фикса ошибки в getWebhookInfo исчезают за несколько минут.

Бот отвечает с задержкой – это rate limit или очереди

Смотрите на 429 и частоту вызовов методов – возможно, упёрлись в лимит. Проверьте глубину очередей и время обработки хэндлеров – это признак узких мест. Включите бэкофф с джиттером и ограничьте параллелизм. Если задержки остаются, масштабируйте воркеры и оптимизируйте блокирующие участки.