HTTP status 429 Too Many Requests¶

HTTP 429 Too Many Requests — код состояния HTTP, возвращаемый сервером клиенту в ответ на запрос, когда клиент превысил установленное ограничение на количество запросов за определённый промежуток времени (rate limiting). Код относится к классу 4xx (клиентские ошибки) и определён в стандарте RFC 6585 «Additional HTTP Status Codes», опубликованном в апреле 2012 года. Основная цель ответа 429 — защита серверных ресурсов от перегрузки, вызванной чрезмерной активностью отдельного пользователя, автоматизированного скрипта или вредоносного бота.

¶История и стандартизация

До появления RFC 6585 серверы, сталкивающиеся с превышением лимитов запросов, использовали другие коды, чаще всего 403 Forbidden («доступ запрещён») или 503 Service Unavailable («сервис недоступен»). Это создавало неоднозначность: клиент не мог понять, вызвана ли ошибка проблемами с правами доступа, временной перегрузкой сервера или же политикой ограничения частоты запросов.

Код 429 был официально введён в обиход группой IETF (Internet Engineering Task Force) в документе RFC 6585, который также стандартизировал коды 428 (Precondition Required) и 431 (Request Header Fields Too Large). Впоследствии код был включён в обновлённый реестр HTTP-статусов в RFC 9110 (2022 год), который заменил устаревший RFC 7231.

¶Механизм работы и заголовки

Ответ сервера с кодом 429 должен содержать заголовок Retry-After, который информирует клиента о том, через какое время можно повторить запрос. Значение заголовка может быть указано в двух форматах:

количеством секунд (например, Retry-After: 120);
конкретной датой в формате HTTP-date (например, Retry-After: Wed, 21 Oct 2025 07:28:00 GMT).

На практике также часто используются нестандартные заголовки, такие как X-RateLimit-Limit (максимальное количество запросов), X-RateLimit-Remaining (оставшееся количество) и X-RateLimit-Reset (время сброса счётчика), однако они не регламентированы стандартом и зависят от реализации конкретного сервиса.

¶Причины возникновения

Код 429 возвращается в ситуациях, когда клиент отправляет запросы слишком часто. Основные сценарии включают:

Интенсивный веб-скрапинг — автоматизированный сбор данных поисковыми роботами, парсерами или конкурентными сервисами.
Перебор паролей (brute force) — попытки подбора учётных данных к системам аутентификации.
DoS-атаки — целенаправленная отправка большого числа запросов для вывода сервера из строя (в этом случае 429 может выступать как промежуточная мера защиты).
Некорректная логика приложений — например, бесконечные циклы повторных запросов без задержек в коде клиентского программного обеспечения.
Публичные API — разработчики, превышающие квоты бесплатных тарифов сервисов (например, лимиты на количество запросов в минуту).

¶Отличие от смежных кодов

Важно различать 429 и другие похожие коды ошибок:

403 Forbidden — сервер понял запрос, но отказывается его выполнять из-за недостатка прав. Ограничение частоты не является причиной.
503 Service Unavailable — сервер временно не может обработать запрос из-за перегрузки или технических работ. Причина — состояние сервера, а не действия конкретного клиента.
420 Enhance Your Calm — неофициальный код, используемый сервисами Twitter (ныне X) и Spring Framework, выполняющий функцию, аналогичную 429.

¶Стратегии обработки на стороне клиента

Корректное поведение клиента при получении кода 429 предполагает:

Чтение и соблюдение заголовка Retry-After.
Применение экспоненциальной задержки (backoff) — увеличение паузы между повторными попытками в геометрической прогрессии (например, 1, 2, 4, 8, 16 секунд).
Ограничение параллельных запросов и введение случайной «джиттер»-задержки для избежания синхронных всплесков нагрузки.
Кэширование полученных данных для снижения числа повторных обращений.

Игнорирование этих правил может привести к временной или постоянной блокировке IP-адреса или учётной записи пользователя.

¶Методы защиты на стороне сервера

Для реализации ограничения частоты запросов серверы используют алгоритмы:

Fixed Window (фиксированное окно) — подсчёт запросов за фиксированный интервал времени (например, 100 запросов в минуту).
Sliding Window Log (скользящее окно с логом) — учёт точного времени каждого запроса в пределах окна, более точный, но ресурсоёмкий метод.
Token Bucket (корзина токенов) — алгоритм, позволяющий накапливать «токены» для кратковременных всплесков активности.
Leaky Bucket (дырявое ведро) — выравнивание скорости обработки запросов до фиксированного значения.

¶Примеры использования в реальных сервисах

Код 429 широко применяется крупными интернет-платформами:

GitHub API — ограничивает неавторизованные запросы до 60 в час, авторизованные — до 5000 в час.
ВКонтакте API — использует собственные ограничения на количество вызовов в секунду, возвращая 429 при превышении.
Яндекс.Карты API — ограничивает бесплатные запросы в зависимости от тарифного плана.
Поисковые системы (Google, Yandex) — возвращают 429 при автоматизированных запросах, превышающих лимиты.

¶Значение в контексте веб-разработки

Для веб-разработчиков корректная обработка 429 является обязательной частью создания отказоустойчивых интеграций. Ответственность за соблюдение лимитов лежит на разработчике клиентского приложения, а не на пользователе конечного продукта. Несоблюдение лимитов может привести к юридическим последствиям, если автоматизированный доступ нарушает условия использования сервиса.