Как исправить ошибку "Too Many Requests"

Ошибка «Too Many Requests» (HTTP 429) в Telegram означает, что вы превысили лимиты на количество запросов — встроенный механизм защиты платформы от злоупотреблений. Чтобы исправить эту ошибку, нужно понять, какой именно лимит вы нарушили, выждать период охлаждения и скорректировать своё поведение, чтобы не вызывать ошибку повторно.

Почему возникает ошибка «Too Many Requests»

Telegram применяет строгие ограничения на частоту запросов ко всем своим API: Bot API, Client API (MTProto/TDLib), а также к действиям обычных пользователей. Когда количество запросов за короткий промежуток времени превышает допустимый порог, сервер возвращает код ответа 429 Too Many Requests с параметром retry_after, который указывает, сколько секунд необходимо подождать.

Эта система защищает инфраструктуру Telegram от перегрузок и обеспечивает стабильную работу для всех пользователей — от владельца канала с 500 подписчиками до крупного медиа с миллионной аудиторией.

Основные причины появления ошибки

  • Слишком быстрая отправка сообщений — боты ограничены примерно 30 сообщениями в секунду глобально и 1 сообщением в секунду в один и тот же чат
  • Массовые операции — добавление участников, редактирование или удаление постов подряд без пауз
  • Частый поллинг API — вызов getUpdates или других методов без корректных интервалов
  • Массовый форвардинг — пересылка множества сообщений из канала или в каналы за короткое время
  • Быстрое вступление и выход из групп — Telegram расценивает такое поведение как подозрительное
  • Inline-запросы к боту — обработка слишком большого количества inline-результатов без троттлинга

Примерные лимиты по типам действий

Действие Примерный лимит Период охлаждения Сообщения в один чат ~20 в минуту 1–60 секунд Сообщения в разные чаты ~30 в секунду Варьируется Массовые уведомления ~30 пользователей в секунду Растёт при повторных нарушениях Действия в группах/каналах ~20 в минуту 1–15 минут Редактирование сообщений ~30 в минуту на чат 30–60 секунд Загрузка файлов ~10 в минуту на бота 60 секунд

Важно: Telegram не публикует официальные значения лимитов. Приведённые цифры — это приблизительные данные, собранные сообществом разработчиков. Они могут измениться без предупреждения. Всегда ориентируйтесь на значение retry_after из ответа сервера.

Пошаговое исправление для разработчиков ботов

Шаг 1: Считайте значение retry_after

Каждый ответ с кодом 429 содержит поле retry_after — минимальное количество секунд, которое необходимо выждать перед следующим запросом.

{
  "ok": false,
  "error_code": 429,
  "description": "Too Many Requests: retry after 35",
  "parameters": {
    "retry_after": 35
  }
}

Парсите это значение и реализуйте задержку (sleep) не менее указанной длительности. Не пытайтесь отправить запрос раньше — это только усугубит ситуацию.

Шаг 2: Реализуйте экспоненциальный откат (exponential backoff)

Вместо того чтобы повторять запрос сразу после окончания периода охлаждения, используйте экспоненциально увеличивающиеся задержки:

  1. Первая попытка: ждите значение retry_after (например, 35 секунд)
  2. Вторая попытка: удвойте время ожидания (70 секунд)
  3. Третья попытка: удвойте снова (140 секунд)
  4. Установите потолок в 5–10 минут, чтобы избежать бесконечного ожидания

Такой подход демонстрирует серверам Telegram, что ваше приложение ведёт себя ответственно.

Шаг 3: Добавьте очередь сообщений

Вместо прямой отправки сообщений помещайте их в очередь и обрабатывайте с контролируемой скоростью:

  • Глобальный лимит: не более 25–28 сообщений в секунду (оставляя запас от лимита ~30)
  • Лимит на чат: 1 сообщение каждые 3 секунды для безопасного запаса
  • Для групп и каналов: не более 15–18 сообщений в минуту на один чат
  • Обрабатывайте очередь с равномерными интервалами между отправками

Для реализации очереди в Ruby on Rails отлично подходят Solid Queue или Sidekiq. Например, если вы разрабатываете сервис синхронизации контента канала (как это делает tgchannel.space), очередь позволит надёжно обрабатывать сотни постов без риска блокировки.

Шаг 4: Переключитесь на вебхуки

Если вы используете getUpdates (long polling), переходите на вебхуки. Каждый вызов поллинга считается запросом к API и расходует ваш лимит. Вебхуки позволяют Telegram самому отправлять обновления на ваш сервер, полностью устраняя лишние запросы.

Настройка вебхука через @BotFather или через API-вызов setWebhook занимает несколько минут, но экономит тысячи ненужных запросов в сутки.

Шаг 5: Распределяйте массовые операции во времени

Когда нужно отредактировать или удалить множество сообщений, делайте паузу 1–2 секунды между операциями. Для массовых уведомлений пользователям обрабатывайте их пакетами по 25–30 получателей с паузой в 1 секунду между пакетами.

Исправление ошибки для обычных пользователей

Если вы столкнулись с «Too Many Requests» как обычный пользователь Telegram (не разработчик), причины и решения будут другими.

Вступление в большое количество групп и каналов

Telegram ограничивает количество групп и каналов, в которые можно вступить за короткий период. Если вы столкнулись с этим лимитом:

  • Подождите 24 часа перед попыткой вступить в новые группы
  • Вступайте постепенно — не более 5–10 групп в час
  • Если на вас недавно жаловались как на спам, ограничение может длиться дольше

Слишком быстрая отправка сообщений

Интенсивная переписка, особенно в нескольких чатах одновременно, может вызвать троттлинг:

  • Снизьте темп отправки сообщений
  • Не копируйте одно и то же сообщение в десятки чатов — Telegram распознаёт это как спам
  • Подождите 15–30 минут после появления ошибки, затем продолжайте в нормальном темпе

Массовая пересылка контента

Пересылка сообщений во множество чатов одновременно — одна из самых частых причин ошибки:

  • Пересылайте не более чем в 5–10 чатов за раз
  • Делайте паузу не менее 30 секунд между пакетами
  • Рассмотрите альтернативу: создайте канал и делитесь ссылкой на него вместо пересылки каждого поста

FloodWait в MTProto/TDLib

Если вы работаете с полноценным Client API Telegram (MTProto), ошибка приходит в виде исключения FLOOD_WAIT_X, где X — количество секунд ожидания. Лимиты здесь, как правило, строже:

  • Ограничения на уровне аккаунта действуют для всех сессий одновременно
  • Лимиты по методам различаются для разных API-вызовов
  • Повторные нарушения приводят к экспоненциально растущим задержкам — от секунд до часов и даже дней
  • Методы channels.getParticipants, messages.search и contacts.resolveUsername особенно строго ограничены

Для сервисов, которые взаимодействуют с данными Telegram-каналов (например, tgchannel.space при синхронизации контента), соблюдение этих лимитов критически важно для стабильной и бесперебойной работы.

Советы и лайфхаки

  • Всегда соблюдайте retry_after: Никогда не игнорируйте это значение. Повторные попытки без ожидания приводят к прогрессивно более длительным блокировкам — от секунд до часов
  • Закладывайте запас прочности: Если наблюдаемый лимит составляет 30 сообщений в секунду, целесь на 20–25, чтобы учесть колебания и общие лимиты между операциями вашего бота
  • Логируйте все 429-ответы: Отслеживайте, когда и где срабатывают ограничения. Записывайте временные метки, ID чатов и названия методов — это поможет найти узкие места
  • Используйте отдельных ботов для разных задач: Если бот одновременно рассылает уведомления и обрабатывает команды, рассмотрите разделение на двух ботов — у каждого будет независимый лимит
  • Кешируйте ответы API: Сохраняйте результаты методов getChat, getChatMember или getFile локально, вместо того чтобы вызывать API повторно для тех же данных
  • Реализуйте circuit breaker: Если за короткий период получили несколько 429-ошибок, временно приостановите все некритичные вызовы API
  • Координируйте несколько инстансов: Если бот запущен на нескольких серверах, все они делят один лимит. Используйте общий ограничитель запросов (например, на базе Redis)

Частые ошибки

Ошибка 1: Мгновенный повтор запроса после ошибки
Почему это неправильно: отправка нового запроса до истечения периода retry_after сбрасывает или продлевает ваше ожидание, усугубляя проблему.
Как избежать: всегда парсите и соблюдайте значение retry_after. Добавляйте небольшой буфер (2–5 секунд сверху) для надёжности.

Ошибка 2: Фиксированные задержки вместо динамического троттлинга
Почему это неправильно: захардкоженный sleep(1) между сообщениями может работать сегодня, но сломается завтра, если Telegram скорректирует лимиты или ваш трафик вырастет.
Как избежать: реализуйте адаптивное ограничение скорости, которое реагирует на реальные 429-ошибки и подстраивается динамически.

Ошибка 3: Отправка одинаковых сообщений во множество чатов
Почему это неправильно: антиспам-система Telegram специально отслеживает идентичный контент, рассылаемый по нескольким получателям. Это вызывает более строгие ограничения, чем разнообразные сообщения.
Как избежать: если нужна рассылка, используйте небольшие вариации в тексте или, что лучше, создайте Telegram-канал и делитесь ссылкой на него.

Ошибка 4: Неразличение лимитов по чату и глобальных лимитов
Почему это неправильно: вы можете быть в рамках глобального лимита, но превышать лимит для конкретного чата, или наоборот. Обработка как единого лимита ведёт к неэффективному троттлингу.
Как избежать: отслеживайте количество запросов как глобально, так и для каждого чата по отдельности. Применяйте оба ограничения независимо.

Ошибка 5: Игнорирование лимитов при разработке и тестировании
Почему это неправильно: быстрые итерации тестирования с реальными API-вызовами могут привести к пометке вашего токена бота, и эти ограничения перенесутся в продакшен.
Как избежать: используйте тестовое окружение Telegram, когда это возможно, и всегда включайте логику ограничения запросов даже в dev-сборках.

Часто задаваемые вопросы

Как долго длится блокировка «Too Many Requests»?
Длительность указана в поле retry_after и обычно составляет от 5 секунд до нескольких минут при первом нарушении. Повторные нарушения могут увеличить срок до часов и даже дней. Постоянной блокировки только из-за превышения лимитов не бывает, но систематическое злоупотребление может привести к полному ограничению аккаунта или бота.

Может ли бот получить перманентный бан за превышение лимитов?
Само по себе превышение лимитов не приведёт к перманентному бану. Однако агрессивное поведение в сочетании с жалобами пользователей может побудить Telegram отозвать ваш токен бота. Регулярные 429-ошибки — это сигнал к пересмотру архитектуры обработки запросов.

У каждого токена бота свой лимит?
Да, лимиты применяются для каждого токена бота отдельно. Однако если несколько ботов работают с одного IP-адреса, может действовать дополнительное ограничение на уровне IP. Запуск нескольких ботов на одном сервере не умножает линейно общую допустимую пропускную способность.

Можно ли запросить у Telegram повышение лимитов?
Telegram не предоставляет официального повышения лимитов для стандартных ботов. Однако верифицированные через @BotFather боты с большой легитимной аудиторией могут получить чуть более лояльное обращение. Для очень высоконагруженных сценариев рассмотрите обращение в поддержку Telegram для бизнес-аккаунтов.

Влияет ли выбор вебхуков или поллинга на лимиты?
Вебхуки устраняют накладные расходы на вызовы getUpdates, которые учитываются в вашем лимите. Переход на вебхуки высвобождает ресурс запросов для реальных операций — отправки сообщений, загрузки файлов. Одно только это переключение способно решить проблему 429-ошибок у ботов, которые слишком часто опрашивают сервер.