429 Too Many Requests

Применение

Код состояния 429 Too Many Requests означает, что количество HTTP-запросов превысило допустимый порог. Так происходит, например, когда сервер хочет ограничить число вызовов API за час.

Спецификация не определяет, как сервер подсчитывает HTTP-запросы или идентифицирует пользователей. Ограничение частоты применяется к отдельному ресурсу, к отдельному пользователю, ко всему серверу целиком или к нескольким серверам сразу. Идентификация пользователя выполняется по учётным данным либо, как вариант, с помощью Cookie.

Сервер может дополнительно включить HTTP-заголовок Retry-After, чтобы сообщить клиенту, когда запросы снова будут приниматься.

Примечание

Ограничение частоты (rate limiting) задаёт верхний предел общего числа запросов во временном окне (жёсткая отсечка), тогда как троттлинг (throttling) замедляет обработку запросов, ставя их в очередь или задерживая ответы. Длительность ожидания зависит от заголовка Retry-After. Без Retry-After распространённые окна составляют от 60 секунд до 24 часов в зависимости от API. Пользователи VPN делят IP-адреса со множеством других пользователей, поэтому ограничения по IP затрагивают всех пользователей VPN на одном и том же сервере.

Влияние на SEO

Googlebot воспринимает 429 как сигнал о серверной ошибке. Когда сайт возвращает ответы 429, Google временно снижает скорость сканирования по всему сайту. Как только нормальные ответы возобновляются, скорость сканирования постепенно восстанавливается. В отличие от других кодов 4xx, ответы 429 влияют на краулинговый бюджет. Устойчивые ответы 429 на проиндексированных URL приводят к удалению из результатов поиска. Чтобы замедлить Googlebot, 429 — правильный код состояния. Коды 401 и 403 скорость сканирования не снижают. Bingbot также снижает скорость сканирования при ответах 429. Кроме того, Bing поддерживает директиву crawl-delay в robots.txt как альтернативу троттлингу на основе кодов состояния.

Пример

Клиент запрашивает ресурс, и сервер отвечает кодом 429 Too Many Requests.

Запрос

GET /current-news HTTP/1.1
Host: example.com

Ответ

HTTP/1.1 429 Too Many Requests
Retry-After: 1800
Content-Type: text/html
Content-Length: 173

<html>
  <head>
    <title>Request Limit Exceeded</title>
  </head>
  <body>
   <p>The request limit has been reached.
   Try again in 30 minutes.</p>
  </body>
</html>

Как исправить

Проверьте заголовок Retry-After в ответе. Его значение задаёт либо число секунд, либо HTTP-дату, указывающую, когда сервер снова начнёт принимать запросы. Приостановите все запросы до указанного момента.

Реализуйте экспоненциальную выдержку (backoff) с джиттером между попытками повтора. Удваивайте время ожидания после каждой неудачи (1 с, 2 с, 4 с, 8 с) и добавляйте случайное смещение, чтобы несколько клиентов не повторяли запросы одновременно и не создавали новый всплеск трафика.

Следите за заголовками ограничения частоты, не дожидаясь достижения потолка. Многие API включают заголовки X-RateLimit-Limit, X-RateLimit-Remaining и X-RateLimit-Reset. Отслеживайте остаток и заблаговременно снижайте темп запросов.

Стандартизованные поля ограничения частоты

Помимо де-факто стандартных заголовков X-RateLimit-*, IETF стандартизирует поля ответа RateLimit и RateLimit-Policy для передачи сведений о квоте и сбросе.

Ставьте исходящие запросы в очередь на стороне клиента. Очередь запросов с контролируемой скоростью отправки не даёт всплескам превысить лимит. Объединяйте несколько операций в один вызов API, если конечная точка поддерживает пакетные операции.

Кэшируйте ответы для данных, которые между запросами меняться не должны. Повторные одинаковые вызовы — самый частый источник излишнего расходования лимита.

На стороне сервера в nginx директивы limit_req_zone и limit_req управляют ограничениями частоты по IP или по конечной точке. Задайте limit_req_status 429;, чтобы ограниченные запросы возвращали правильный код состояния вместо используемого по умолчанию 503. Применяйте параметры burst и nodelay, чтобы допускать короткие всплески трафика, не отклоняя клиентов немедленно.

Для AWS API Gateway настройте параметры троттлинга на уровне стадии (stage) или метода. Увеличьте скорость и запас на всплески под ожидаемый профиль трафика, если пороги по умолчанию слишком жёсткие.

Примеры кода

.NET

HttpStatusCode.TooManyRequests

Rust

http::StatusCode::TOO_MANY_REQUESTS

Rails

:too_many_requests

http.StatusTooManyRequests

Symfony

Response::HTTP_TOO_MANY_REQUESTS

Python3.5+

http.HTTPStatus.TOO_MANY_REQUESTS

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_TOO_MANY_REQUESTS

Angular

@angular/common/http/HttpStatusCode.TooManyRequests