Подписаться: 
Skip to content 
Откройте BotFather и проверьте, что токен актуален и вы не делали недавно /revoke (отзыв токена). Сверьте /setcommands и нужный scope (область: по умолчанию/для групп/для PM) с тем, что зашито в коде. Если команды не совпадают по названию/локали, автодополнение и триггеры не сработают. В большинстве инцидентов достаточно обновить список команд и подставить правильный токен.
Когда токен и команды подтверждены, проверьте воронку на небольшом трафике. Аккуратная Накрутка телеграм малыми партиями поможет замерить реакцию на команды, скорость ответа бота и конверсию в целевое действие. Подавайте равномерно 30-60 минут и сравните метрики до и после.
Решите, откуда бот получает события: webhook (вебхук) или long polling (опрос), но не одновременно. Вызовите getWebhookInfo и убедитесь, что ваш URL отвечает 200 OK за ≤ 10 секунд (без редиректов). Если есть ошибки, снимите вебхук и временно проверьте getUpdates — события должны приходить в консоль. Такой тест показывает, в сети/сертификате проблема или в логике кода.
В группах с включённым Privacy Mode бот видит только команды вида /cmd и упоминания @MyBot (это нормально). Проверьте, что боту выданы права писать/читать там, где он «молчит» (особенно каналы/супергруппы). Введите команду со слэшем и упоминанием: /cmd@MyBot — так исключите конфликт имён. Без прав и корректного контекста реакции не будет, даже если код верный.
Сравните токен в переменных окружения с токеном у BotFather — не разъехались ли среды dev/stage/prod. Обновите /setcommands и проверьте локаль описаний: русская/английская версия должны соответствовать клиенту пользователя. Убедитесь, что scope (область) верный: по умолчанию, для групп или для приватных чатов. Такой синк убирает «немоту» без единой правки сервера.
Проверьте, что активен только один канал получения апдейтов — двойной запуск даст 409 Conflict. Посмотрите getWebhookInfo: не пустой ли last_error_message и приходит ли к вам POST с апдейтом. Если вебхук «висит», снимите его (deleteWebhook?drop_pending_updates=true) и временно включите polling. Так вы отделите сетевые ошибки от логических.
Включите подробный лог: update_id, chat_id, handler, время начала/окончания и статус. Отлавливайте непойманные исключения: падение одного обработчика «съедает» реакцию на команду. Храните last_update_id и соблюдайте идемпотентность (без повторной обработки) — это убирает дубли и «пропуски». После фикса повторно запустите тестовую команду и проверьте цепочку в логах.
Когда Privacy Mode включён, бот не видит обычные сообщения и ждёт команду с явным обращением. Используйте форму /cmd@MyBot или ответ на его сообщение (reply), чтобы передать контекст. Если нужно читать обычные фразы, переключите /setprivacy на Disabled у BotFather. Это безопаснее, чем долго искать «баг» в коде там, где всё работает по правилам платформы.
В группах и каналах права отличаются, и без роли администратора постинг может быть запрещён. Проверьте галочки: отправка сообщений, ссылки/медиа, закрепление/удаление сообщений. После смены прав перезапустите бота, чтобы кэш чатов обновился. Отсутствие прав — частая и самая быстрая в исправлении причина тишины.
Супергруппы включают антифлуд и «медленный режим» — визуально бот «молчит» дольше. Проверьте фильтры, ограничения на частоту и права на ссылки/медиа. Попробуйте ту же команду в тестовой группе без ограничений, чтобы исключить внешние факторы. Если в песочнице всё ок — корректируйте политику группы.
Код 403 на sendMessage обычно означает, что пользователь заблокировал бота или никогда не писал ему первым. Попросите начать диалог вручную (первое сообщение) — это снимает запрет PM. Не ретратьте одно и то же сообщение — это выглядит как спам и тратит лимиты. Логируйте такие случаи, чтобы не пытаться писать в закрытые лички снова.
Если бот часто отвечает подряд, вы рискуете словить 429 Too Many Requests. Включите бэкофф (паузы между повторами) и очереди, уменьшите частоту. Пометьте «окна тишины» для массовых рассылок, чтобы не упираться в лимиты. Так вы сохраните доставку и доверие.
Иногда команда «закрыта» в callback или изменённом сообщении (edited_message), а обработчика нет. Проверьте, что хэндлеры подписаны на все используемые типы апдейтов: message, command, callback_query. Добавьте заглушки и лог на неожиданные типы — бот перестанет «падать молча». Это быстрый способ увидеть истинную форму события.
Убедитесь, что сертификат от публичного CA, цепочка полная (есть intermediate), CN соответствует домену, SNI включён. Просроченный или неполный сертификат Telegram не примет, вебхук «онлайн», но апдейтов нет. Перепроверьте даты и issuer и перезапустите сервер после обновления. Это 5 минут работы и море сэкономленного времени.
Ваш обработчик должен вернуть 200 OK быстро (лучше до 2 секунд, максимум 10) и без редиректов. Content-Type должен соответствовать ответу, иначе телеграм «ругается» wrong response. Долгие операции вынесите в фон или очередь, чтобы не блокировать ответ. Так вы избежите таймаутов и повторов.
Если видите 409, значит одновременно активны webhook и polling. Снимите вебхук: deleteWebhook?drop_pending_updates=true — и убедитесь, что polling единственный. После фикса верните setWebhook и проверьте getWebhookInfo — ошибки должны исчезнуть. Держите один канал апдейтов в каждый момент времени.
Храните last_update_id и сдвигайте offset на +1, чтобы не получать дубли. Ставьте timeout 25–30 секунд и проверяйте, что апдейты идут без «дыр». Если видите пропуски, проверьте очередь, обработчики и место фикса offset. Это база стабильной доставки.
Только один процесс должен читать getUpdates, иначе получите гонки и дубли. Отдельные воркеры пусть обрабатывают, но не принимают апдейты. Сделайте явную «единственную точку входа» и идемпотентность на обработке. Так вы исключите «хаос» на входе.
Проверьте таймауты HTTP‑клиента и прокси, добавьте бэкофф и ретраи для временных сбоев. На NAT/фаерволе убедитесь, что исходящие к api.telegram.org разрешены. Если сеть «рвётся», переходите на вебхук и мониторьте время ответа. Сеть — частая причина «тишины» вне кода.
400 Bad Request — ошибка в параметрах/JSON: проверьте типы и поля. 401 Unauthorized — токен неверный/отозван: получите новый у BotFather и обновите конфиги. 403 Forbidden — нет прав/пользователь заблокировал: запросите права или попросите пользователя написать первым. 409 Conflict — запущены webhook и polling: снимите webhook. 413 — слишком большой файл: сжимайте/делите. 429 — превышен лимит: включайте очереди и бэкофф.
Держите callback_data короткими, не кладите туда большие JSON — храните состояние на сервере. Проверьте лимиты размеров файлов для фото, видео, документов и аудио. Следите за длиной подписей и текстов, чтобы не ловить «тихие» 400. Эти мелочи регулярно «роняют» бота без явных ошибок в коде.
Ставьте Content-Type: application/json и валидируйте сериализацию. Экранируйте спецсимволы и учитывайте Unicode/эмодзи. Тестируйте крайние случаи (длинные подписи, RTL‑текст), чтобы не падать в проде. Это простая страховка от ночных инцидентов.
Ниже — короткие подсказки, которые закрывают самые частые кейсы. Держите их под рукой как карту навигации перед дебагом. Сначала исключите 409/401/403 и проблемы TLS — это «критично». Остальное идёт вторым шагом.
Симптом Причина Проверка/исправление Команда не подсвечивается Нет /setcommands или не тот scope BotFather /setcommands, локаль, совпадение с кодом Молчит в группе Privacy Mode/нет прав /setprivacy, права админа, /cmd@MyBot Webhook «висит» TLS/не 200 OK getWebhookInfo, логи сервера, починить сертификат/ответ Двойные апдейты offset не двигается/два воркера Хранить last_update_id, единый приёмник 409 Conflict Webhook + polling одновременно deleteWebhook?drop_pending_updates=true 429 Too Many Requests Превышен лимит Бэкофф/очереди, снизить частоту
Перед командами убедитесь, что подставили настоящий и ваш HTTPS‑домен. В ответах смотрим 200 OK и текст last_error_message в getWebhookInfo. Ошибки TLS/timeout укажут направление фикса. После правки повторяем проверку.
Накрутка соц сетей
Продвижение
Блогcurl https://api.telegram.org/bot<TOKEN>/getWebhookInfo
curl -F "url=https://example.com/hook" https://api.telegram.org/bot<TOKEN>/setWebhook
curl "https://api.telegram.org/bot<TOKEN>/deleteWebhook?drop_pending_updates=true"Для быстрой локальной проверки событий используйте getUpdates c timeout. Если видите апдейты здесь, а вебхук молчит — виноваты сеть/TLS/обработчик. Это хороший способ локализовать проблему за минуты. Не держите polling и webhook вместе.
curl "https://api.telegram.org/bot<TOKEN>/getUpdates?timeout=30"Проверьте токен и /setcommands, убедитесь в корректной локали и scope. Проверьте права в чатах и режим Privacy Mode в соответствии со сценарием. Убедитесь, что вебхук даёт 200 OK и цепочка TLS полная; включите мониторинг и алерты. Зафиксируйте порядок действий на переключение каналов (runbook) и проверьте его на тесте.
Запишите, какой канал сейчас активен, и отключите второй, чтобы не словить 409. Включите расширенный лог апдейтов и ошибок и отметьте время начала проблемы. Временно перейдите на polling, чтобы не терять события, и параллельно чините сеть/сертификат/код. После фикса вернитесь на вебхук и убедитесь, что last_error_message пустой.
Чаще всего включён Privacy Mode или боту не хватает прав писать/читать. Используйте форму /cmd@MyBot или отключите приватный режим, если нужно читать обычные сообщения. Дайте права администратора и повторите тест. Если в тестовой группе всё работает — проблема в настройках целевой группы.
409 — отключите один канал апдейтов; 429 — включите очереди и бэкофф; 400 — проверьте JSON и длины полей. Для 401 обновите токен, для 403 проверьте права/блок в PM. Снимите getWebhookInfo и логи — они подскажут направление. Двигайтесь по чек‑листу сверху вниз.
Если getWebhookInfo показывает TLS/timeout — лечите сертификаты и скорость ответа. Если polling получает апдейты, а вебхук — нет, виноваты сеть/TLS/обработчик. Проверьте SNI/CN, полный chain и время до 200 OK. Если и это в норме — смотрим логи хэндлеров.
Нет, для одного бота допускается только один способ приёма апдейтов. Совместный запуск приводит к 409 Conflict и дублированию событий. Держите «единственную точку входа» и фиксируйте порядок переключений в runbook. Так вы избежите «гонок» и странных багов.
Twitter / X 
LinkedIn 
