Подписаться: 
Skip to content 
Бот перестал работать в телеграм? Я покажу, что критично проверить сразу (токен, вебхук, TLS) и что важно. Когда токен, вебхук и TLS уже исправны, проверьте воронку на реальных пользователях малыми волнами трафика: Накрутка подписчиков телеграм даст быстрый контрольный приток для замера welcome-сообщений, отклика бота и удержания. Фиксируйте p95 ответа, error rate и конверсию в целевое действие до и после запуска.
Нужны первоисточники, чтобы доверять каждому шагу? Сверяйтесь с документацией Telegram Bot API: setWebhook/getUpdates/лимиты – https://core.telegram.org/bots/api. Требования к HTTPS и сертификатам (публичный CA, полный chain, SNI/CN) – https://core.telegram.org/bots/webhooks#https-certificate. Про Privacy Mode у BotFather – https://core.telegram.org/bots/features#privacy-mode.
Сначала закрываем Критично: токен/дубликаты, 409 (двойной канал апдейтов), TLS chain/CN/SNI, быстрый 200 OK. Затем Важно: IPv6/AAAA и DNS, лимиты 429 (частые запросы), права/Privacy Mode. Опционально: окна тишины в cron, circuit breaker (автовыключатель запросов) и тонкие настройки очередей. Такая маркировка экономит время и снижает MTTR.
Токен не меняли вчера и он не отозван (/revoke у BotFather)? Бот добавлен админом там, где должен писать (группа/канал) и ему выданы нужные права? Включён ли Privacy Mode и не мешает ли он чтению обычных сообщений в группах (при включении бот видит только команды)? В моей практике 3 из 10 инцидентов закрываются уже на этом шаге.
Как бот получает события сейчас – webhook или long polling (опрос)? Если webhook, вызовите getWebhookInfo и убедитесь, что ваш URL стабильно возвращает 200 OK за 1–2 секунды. Для отладки временно снимите webhook и включите polling (не одновременно, иначе будет 409 Conflict). Такой переключатель сразу показывает: у нас сеть/сертификат или логика кода.
Открывается ли ваш домен по HTTPS без предупреждений? Проверьте цепочку сертификата и SNI (имя сервера в TLS), а также CN (имя домена в сертификате) – ошибки тут «глушат» вебхук. Посмотрите DNS и маршруты: нет ли рассинхрона IPv4/IPv6 и не режет ли фаервол исходящие/входящие. Часто это самый быстрый фикс без правок кода.
Сравните токен в переменных окружения с токеном у BotFather – не разъехались ли dev/stage/prod. Если делали /revoke или получили новый /token, старый ключ сразу мёртв – обновите секреты в CI/CD и перезапустите воркеры. Проверьте дубликаты окружений, где мог остаться старый ключ. В моей практике именно рассинхрон токенов валил бота на часы.
Если после синхронизации токенов бот всё равно молчит, отдельно разберитесь, почему телеграм бот не реагирует на команды: проверьте логи, корректность вебхука или long polling, актуальность прав бота и то, действительно ли апдейты доходят до нужного обработчика.
Активен ли только один канал доставки событий? 409 Conflict в API почти всегда значит, что запущены оба. Для локальной проверки снимите webhook (deleteWebhook с drop_pending_updates) и включите getUpdates. Так вы исключите сеть и посмотрите на обработчик апдейтов в лоб.
Вызовите getWebhookInfo и прочтите last_error_message: timeout, TLS error, wrong response? Timeout – обработчик отвечает слишком долго; TLS error – проблема с сертификатом/цепочкой; wrong response – не 200 OK или не тот формат ответа. Логируйте входящий payload (тело запроса) и время ответа – это экономит часы.
Используйте публичный CA и отдавайте полный chain (intermediate сертификаты). Убедитесь, что SNI (имя сервера) и CN (домен в сертификате) совпадают с URL вебхука. Возвращайте 200 OK быстро: лучше до 2 секунд, максимум до 10 секунд. В реальных инцидентах неполная цепочка была самой частой причиной «тишины».
Проверьте логи на 429 Too Many Requests и включите бэкофф (повторные попытки по экспоненте). Сверьте размеры файлов и длины полей (особенно callback_data) с лимитами Bot API. Валидируйте JSON и типы апдейтов, чтобы неожиданные события не «роняли» обработчик. Идемпотентность (без повторной обработки) спасает от дублей при ретраях.
Боту хватает прав на отправку сообщений, ссылок и медиа там, где он «молчит»? В группах с включённым Privacy Mode бот видит только команды и инлайн – это не баг. В каналах писать получится только с правами администратора. Мы заранее перечисляем требования к правам, чтобы их не потеряли при миграции.
Включите подробный лог: входящий апдейт, ID чата, время обработки, статус ответа. Поймайте непойманные исключения и проверьте очереди сообщений – нет ли «залипаний». Вынесите внешние вызовы в фон, поставьте таймауты (время ожидания ответа) и circuit breaker (автовыключатель запросов). Это стабилизирует 200 OK и уменьшит подвисания.
Проверьте, не режет ли прокси/фаервол входящие и исходящие запросы. Убедитесь, что health‑checks (URL проверки здоровья сервиса) не убивают воркер под нагрузкой. Нет ли проблем с DNS/TTL при переезде домена и не мешает ли AAAA‑запись для IPv6. Мониторинг задержек и аптайма даст ранний сигнал деградации.
Храните токен в секрет‑менеджере и распространяйте через один источник правды. После /revoke обновляйте все среды, иначе часть воркеров останется с «мертвым» ключом. Проверьте, не запущены ли старые контейнеры с прежними переменными окружения. Это классика, которая ломает прод на ровном месте.
Проверьте /setcommands и локализованные описания – первая строка видна сразу в клиенте. Соблюдайте формат: слэш, команда, короткое описание без «воды» и лишних символов. Для нескольких языков держите отдельные наборы, чтобы клиент подхватывал локаль пользователя. Мы заливаем команды из JSON на релизе, чтобы не править руками.
Даже при идеально оформленных командах стоит отдельно проверить, почему бот не отвечает в Телеграм: корректно ли настроены обработчики для этих команд, обновлён ли код после изменения списка, не конфликтуют ли локализованные варианты и действительно ли апдейты доходят до нужного метода в бэкенде.
Решите заранее: бот читает всё или только команды? Если нужно читать обычные сообщения, выключите Privacy Mode (и добавьте фильтры по чатам). Для публикации в канале дайте права администратора и отметьте нужные галочки. Так не придётся «ждать чуда» от приватного бота.
Регистрируйте вебхук на доступном извне HTTPS‑домене. Придерживайтесь правила «один бот – один вебхук», без дублей и старых хвостов. Перед переключением делайте drop_pending_updates, чтобы не тянуть старые апдейты. Мы всегда проверяем health‑endpoint до включения реального трафика.
Следите за сроком действия и целостностью цепочки, совпадением CN/домена и корректным SNI. На мультисайтовых серверах проверьте виртуальные хосты и роутинг. Неправильный SNI/CN выглядит как «молчание» без явной ошибки в логах. Это чинится за минуты, если знать куда смотреть.
Возвращайте 200 OK сразу, тяжёлое уносите в фоновые очереди. Ставьте ретраи (повторные попытки) и идемпотентность (без повторной обработки) на чувствительных участках. Логируйте время ответа и ID апдейта, чтобы ловить шипы. В моей практике перенос внешних вызовов в фон мгновенно снял «таймауты».
Держите timeout 25–30 секунд и сдвигайте offset, чтобы не ловить дубли. Храните last_update_id и применяйте идемпотентность (без повторной обработки). Не блокируйте получение апдейтов тяжёлыми задачами. Polling – быстрый способ изолировать проблему от сети/TLS.
Делегируйте долгие операции воркерам и очередям, а не держите их в обработчике. Контролируйте число параллельных воркеров и лимиты Bot API, чтобы не ловить 429. Добавьте метрики очередей и активных обработчиков в мониторинг. Это делает поведение бота предсказуемым под нагрузкой.
Снимайте вебхук с drop_pending_updates перед запуском polling – и наоборот. Фиксируйте шаги в журнале релиза, чтобы не получить 409 Conflict. Держите один канал апдейтов в каждый момент времени. Так вы избежите двойной доставки и странных багов.
Сверьте лимиты по размеру файлов и частоте запросов в документации Bot API. Включите бэкофф и очереди на массовых отправках, чтобы не ловить 429 Too Many Requests. Соблюдайте лимиты на чат и на бота, иначе сообщения будут «отскакивать». Мы ставим алерты на приближение к порогам, чтобы реагировать заранее.
Не кладите большие JSON в callback_data – храните состояние на сервере. Валидируйте длины полей, шифруйте или кодируйте маркеры компактно. Экранируйте пользовательский ввод, чтобы не «ломать» Markdown/HTML. Простые маркеры + серверное состояние = надёжность и скорость.
Отправляйте корректный Content‑Type и валидный JSON на входе/выходе. Учитывайте Unicode, эмодзи, RTL‑текст и длинные подписи. Автотесты на сериализацию спасают часы в проде. Мы держим заглушки на редкие события, чтобы бот не падал молча.
Проверьте галочки прав на отправку сообщений, ссылок, медиа и управление сообщениями. В канале без админки бот писать не будет – так устроено. Для закрепов и ссылок нужны отдельные разрешения – уточните это заранее. Мы всегда описываем требуемые права в README проекта.
Супергруппы включают антифлуд и slow‑mode – визуально бот «молчит». Проверьте фильтры и режим «только админы», а также Privacy Mode. Если нужен доступ к обычным сообщениям – выключайте Privacy Mode или работайте командами. Тест в песочнице экономит много нервов.
Во многом именно эти настройки и создают ощущение, что «всё сломалось», поэтому при диагностике важно отдельно разбираться, почему не работают боты в Телеграм именно в конкретном чате: шаг за шагом проверяйте режим супергруппы, антифлуд, slow mode, права бота и Privacy Mode, прежде чем искать проблему в коде или у провайдера.
403 Forbidden в личке = пользователь заблокировал бота. Не шлите повторно и не сжигайте лимиты – уважайте выбор пользователя. Дайте инструкцию по разблокировке в FAQ и интерфейсе. Это уменьшает жалобы и повышает доверие к боту.
Откройте исходящие на api.telegram.org:443 и входящие на порт вебхука. За NAT/прокси проверьте заголовки X‑Forwarded и реальный IP клиента. При необходимости добавьте IP Telegram в белые списки хостинга. Мы регулярно делаем трассы и проверяем MTU при нестабильной сети.
Проверьте A/AAAA записи и TTL, особенно после переезда домена. Несовместимость IPv6 вызывает таймауты на части клиентов – отключите AAAA или настройте поддержку. Подождите распространения DNS перед переключением вебхука. Эти мелочи часто объясняют «мистические» отказы.
Сверьте таймауты функций и лимиты по памяти/CPU – при недогрузке всё «висит». Холодный старт ломает 200 OK – держите «тёплый» пул или пинг по расписанию. Следите за p95 задержкой и временем до ответа: это ранние индикаторы проблем. В нашем опыте это ловит деградацию раньше, чем пользователи её заметят.
Включите глобальный перехват ошибок и алерты на падения процессов. Следите за длиной очередей и признавайте сообщения (ack), чтобы не плодить дубли. Проверяйте утечки памяти, чтобы воркеры не умирали тихо. Watchdog‑перезапуск часто возвращает доступность без редеплоя.
Сверьте список типов апдейтов и добавьте заглушки на редкие события. Логируйте неожиданные payload (тело запроса), чтобы быстро видеть причину падения. Расширьте тесты: poll, shipping_query, pre_checkout_query, chat_join_request. Так вы не поймаете сюрприз в проде.
Проверьте таймзону сервера и расписание cron – не мешают ли они обработке апдейтов. Добавьте окна тишины для ночных часов, если пользователям лучше не писать. Разведите cron и воркеры по очередям, чтобы не блокировать друг друга. Это убирает «мистические» провалы вовлечения.
Держите ключи в секрет‑хранилище и проверяйте квоты заранее. Следите за SLA партнёров и готовьте «план Б» при недоступности. Храните ссылки на статус‑страницы поставщиков. Мы добавляем кеш и фолбэки, чтобы бот не зависел от чужих шипов.
Ставьте таймауты (время ожидания ответа) и ретраи (повторные попытки) на внешних вызовах. Включайте circuit breaker (автовыключатель запросов), чтобы не перегружать сервисы. Сообщайте пользователю дружелюбные тексты при деградации. Это сохраняет доверие и лимиты.
Санитизируйте Markdown/HTML и экранируйте спецсимволы. Валидируйте длины/типы, даже если «по документации всё ок». Не доверяйте внешним JSON и проверяйте поля на входе. Такой слой защиты избавляет от неожиданных падений.
| Код/статус | Ситуация | Диагноз | Действие |
|---|---|---|---|
| 400 Bad Request | Неверный JSON/параметр | Валидация упала | Исправьте поле/тип и пересоберите |
| 401 Unauthorized | Неверный токен | Токен отозван/ошибочный | Получите новый в BotFather |
| 403 Forbidden | Нет прав/заблокирован | PM запрещён/не админ | Запросите права/инвайт |
| 409 Conflict | Два канала апдейтов | Webhook+polling одновременно | Отключите одно, deleteWebhook |
| 413 Payload Too Large | Слишком большой файл | Превышены лимиты | Сжимайте/делите |
| 429 Too Many Requests | Rate limit | Частые запросы | Бэкофф, очереди |
| 502/504 Upstream | Сеть/шлюз | Временный сбой | Ретраи, мониторинг |
| webhook last_error | Не 200 OK/TLS | Сервер не отвечает | Чините TLS/цепочку, ускоряйте |
| Симптом | Причина | Проверка/исправление |
| Бот молчит | Webhook не установлен | getWebhookInfo, TLS/200 OK |
| Двойные сообщения | offset не сдвигается | last_update_id, идемпотентность |
| Не пишет в группу | Privacy Mode/нет прав | /setprivacy, выдать админа |
| Кнопка не отвечает | Неверный callback_data | Длины/JSON, обработчик |
| Падает на медиа | Превышен размер/тип | Лимиты, fallback |
| В PM «blocked» | Пользователь заблокировал | Проверить 403, не слать повторно |
Накрутка соц сетей
Продвижение
Блогcurl -F "url=https://example.com/bot-hook" https://api.telegram.org/bot<TOKEN>/setWebhook
curl https://api.telegram.org/bot<TOKEN>/getWebhookInfocurl "https://api.telegram.org/bot<TOKEN>/deleteWebhook?drop_pending_updates=true"
curl "https://api.telegram.org/bot<TOKEN>/getUpdates?timeout=30"curl -i https://example.com/bot-hook/healthТокен, команды, Privacy Mode, права в чатах. Вебхук: валидный сертификат, 200 OK, таймауты (время ожидания ответа). Лимиты, очереди, мониторинг ошибок и задержек. Задокументируйте версии, домены и режим получения апдейтов.
Остановите шторм запросов и включите бэкофф. Включите расширенный лог апдейтов и ошибок с отметкой времени. Проверьте инфраструктуру (DNS, TLS, сеть), при необходимости сделайте откат/канареечный релиз. Временно перейдите на polling до фикса вебхука.
Единый формат логов ускоряет поиск причины и сравнение релизов. Рекомендуем поля: request_id, update_id, chat_id, handler, t_start, t_finish, duration_ms, status_code, error_class, error_message, retry_count, webhook_url. Держите правило: p95 duration_ms ≤ 3000 (95% запросов быстрее 3 c). Это простая цель, которая хорошо коррелирует с «бот отвечает вовремя».
{
"request_id":"...",
"update_id":123456789,
"chat_id":-100123456,
"handler":"onCallback",
"t_start":"2025-11-14T09:00:00Z",
"t_finish":"2025-11-14T09:00:01Z",
"duration_ms":980,
"status_code":200,
"error_class":null,
"error_message":null,
"retry_count":0,
"webhook_url":"https://example.com/bot-hook"
}Поставьте алерт, если last_error_date в getWebhookInfo обновился за последние 5 минут – это ранний сигнал. Алерт на p95 duration_ms > 2000 ms 5 минут подряд – повод разбирать задержки. SLO: ≥ 99.9% успешных 200 OK вебхука и p95 < 2 s. Эти цели реалистичны и дают предсказуемое качество сервиса.
Быстро проверить цепочку сертификатов можно одной командой OpenSSL. Выполните строку ниже и посмотрите issuer/subject/dates и что цепочка полная (есть intermediate). Обратите внимание на CN/SAN (имя домена) и актуальные даты – просроченный cert «глушит» вебхук. Если chain неполный – настройте веб‑сервер на выдачу полного набора.
echo | openssl s_client -servername example.com -connect example.com:443 -showcerts 2>/dev/null | openssl x509 -noout -issuer -subject -datesПокройте редкие типы событий: poll, shipping_query, pre_checkout_query, chat_join_request. Цель проста: бот не падает на неожиданных payload (тела запросов). Добавьте заглушки и валидаторы схем, чтобы ловить несоответствия. Такой слой предотвращает «тихие» падения после обновлений клиентов.
Сделайте таблицу processed_updates(update_id PK, processed_at) или Redis‑ключи с TTL. Паттерн «check‑then‑set» гарантирует от дублей при ретраях (повторных попытках). Обработка должна быть атомарной: записали – значит обработано. Это убирает «призраков» и неожиданные повторные платежи/действия.
Вынесите в middleware: timeout, экспоненциальный backoff с jitter, max retries, короткое замыкание при 5xx/timeout. Единая политика делает поведение предсказуемым и экономит лимиты. Добавьте дружелюбные сообщения пользователю при деградации. Это повышает доверие и удержание.
Потоки вебхука: количество запросов, доля 200/не‑200, p95/avg задержка. Распределение типов апдейтов: видеть, что реально приходит и где пустоты. Ошибки по кодам: 400/401/403/409/429/5xx – понятная карта неисправностей. Очереди/рассылка: глубина, скорость обработки, отклонения от нормы.
Проверьте Privacy Mode и права: бот видит только команды? Включите/выключите по сценарию. Снимите getWebhookInfo, посмотрите last_error_message: нет ли TLS/timeout. Проверьте TLS chain/CN/SNI и переключитесь временно на polling, затем – откат/канареечный релиз. Такой порядок сокращает MTTR и исключает «гонки» каналов.
Прокси/балансировщик перезаписывает заголовок Host – SNI/маршрут ломается; явно форсируйте proxy_set_header Host ... и корректный SNI на бэкенде. Серверлесс страдает от холодного старта (>3–5 s): держите прогрев по cron. Инлайн‑режим: проверьте лимиты answerInlineQuery и кэш. MarkdownV2: экранируйте спецсимволы _[]()~ – иначе будут «тихие» 400.
Twitter / X 
LinkedIn 
