Чому бот не відповідає в Телеграм

Чому бот не відповідає в Телеграм – причини, діагностика та рішення

Токен і BotFather – чи дійсний токен, чи не відкликано його, чи налаштовано /setcommands і /setprivacy

Відкрийте BotFather і перевірте, що токен актуальний і ви не робили нещодавно /revoke (відклик токена). Звірте /setcommands і потрібний scope (область: за замовчуванням/для груп/для особистих чатів) із тим, що прописано в коді. Переконайтеся, що /setprivacy відповідає сценарію: Enabled для команд або Disabled, якщо потрібно читати звичайні повідомлення. Невідповідність токена/команд/локалей часто дає «тишу» без помилок.

Коли токен, команди, scope і privacy наведені до ладу, перевірте реакцію на невеликому трафіку: акуратна накрутка підписників тг малими партіями допоможе швидко виміряти відгук на команди, 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, щоб не плодити порожні запити й не впиратися в ліміти. Такий режим економить ресурси та стабілізує потік подій. Це основа для dev-середовищ і відладки.

Дублікати й пропуски – ідемпотентність, збереження 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 і частоту викликів методів — можливо, вперлися в ліміт. Перевірте глибину черг і час обробки хендлерів — це ознака вузьких місць. Увімкніть бекофф із джиттером і обмежте паралелізм. Якщо затримки залишаються — масштабуйте воркери й оптимізуйте блокуючі ділянки.