Ошибка 429 Too Many Requests: что значит и как исправить

Ошибка 429 Too Many Requests («слишком много запросов») означает, что сервер получил с вашего IP-адреса, аккаунта или API-ключа больше запросов, чем разрешает его лимит, и временно перестал их принимать. Это не поломка сайта и не бан: доступ возвращается сам через несколько секунд или минут. Посетителю нужно подождать и снизить частоту запросов, владельцу сайта — проверить настройки ограничения частоты (rate limiting).

Что означает ошибка 429 и как переводится Too Many Requests

Too Many Requests переводится как «слишком много запросов». Код ответа сервера 429 — сигнал «ты слишком быстро, сбавь темп». Это стандартный ответ rate limiter'а, защищающего API и сайты от злоупотреблений: парсеров, перебора паролей, зациклившихся скриптов и слишком нетерпеливых клиентов.

Согласно RFC 6585 §4, 429 указывает, что пользователь отправил слишком много запросов за единицу времени. Код относится к классу 4xx, то есть формально это ошибка клиента, хотя в быту её часто называют «ошибкой сервера 429». Это отличие от 503 (сервис недоступен) и 403 (запрещено политикой): 429 — временное состояние, клиент может повторить запрос позже.

Когда повторять, сервер сообщает заголовком Retry-After: число секунд (Retry-After: 60) или дата в формате HTTP (RFC 9110 §10.2.3). RFC 6585 не делает его обязательным (MAY), но хороший API отдаёт его всегда — без него клиенту приходится угадывать паузу. Также распространены неформальные заголовки:

• X-RateLimit-Limit — максимум запросов в окне
• X-RateLimit-Remaining — осталось запросов
• X-RateLimit-Reset — Unix timestamp сброса окна

Стандартизированная замена этим заголовкам — поля RateLimit и RateLimit-Policy — пока находится в статусе черновика IETF, поэтому в реальных API чаще встречаются варианты с префиксом X-.

Кто может ответить 429:

• веб-сервер — например, nginx с модулем limit_req;
• WAF или CDN — правила ограничения частоты у облачного фильтра трафика;
• само приложение — счётчик в Redis или в памяти на каждого пользователя;
• внешний API, к которому обращается ваш сервис или программа на вашем компьютере.

Яндекс: ошибка 429 — что это значит и как убрать

Если такую ошибку показывает поиск Яндекса или другой сервис Яндекса, это значит, что с вашего IP-адреса пришло слишком много запросов за короткое время и они похожи на автоматические. Обычно вместе с этим Яндекс предлагает пройти капчу «Я не робот». Сайт при этом работает — ограничение касается только вашего адреса.

Почему так бывает, даже если вы «ничего не делали»:

• открыто много вкладок, которые одновременно обновляются, или стоит расширение с автообновлением страниц;
• SEO-расширения и программы проверки позиций сами отправляют запросы в поиск от вашего имени;
• включён VPN или прокси: через один выходной адрес идут запросы тысяч людей, и лимит исчерпывают они;
• провайдер выдаёт один внешний IP многим абонентам (CGNAT) — часто в мобильном интернете и у домашних провайдеров; то же в офисе, где весь коллектив выходит через один адрес;
• на компьютере работает вредоносная программа, которая шлёт запросы в фоне.

Как убрать ошибку 429 в Яндексе:

1. Подождите несколько минут и не обновляйте страницу — каждое обновление продлевает ограничение.
2. Если появилась капча, пройдите её в том же браузере: после этого запросы с вашего адреса снова принимаются.
3. Отключите VPN или прокси и проверьте, остаётся ли ошибка.
4. Закройте лишние вкладки с поиском, отключите расширения с автообновлением и SEO-плагины (в Chrome — меню «Расширения» → «Управление расширениями»).
5. Войдите в аккаунт Яндекса: авторизованные запросы реже принимаются за автоматические.
6. Если ошибка повторяется постоянно на всех устройствах в сети, проверьте компьютер антивирусом и узнайте у провайдера, не выдаёт ли он общий IP-адрес.

Узнать, с какого адреса вы выходите в интернет и принадлежит ли он VPN-сервису или мобильному оператору, можно на странице проверки IP-адреса.

Ошибка 429 в браузере, приложениях и API

Сообщения вида «Ошибка 429», «HTTP Error 429», «429 Limited» или «Сервер вернул ошибку 429» в браузере и программах значат одно и то же: удалённый сервис ограничил частоту запросов. Разница только в том, чей это лимит.

• Сайт в браузере на ПК. Помогают те же шаги, что и для Яндекса: пауза, капча, отключение VPN и расширений.
• Программа или мобильное приложение (менеджер файлов для iPhone, клиент облачного сервиса, чат-бот на нейросети). 429 отдаёт API разработчика или сервиса, к которому приложение обращается. Со своей стороны вы можете только подождать и реже повторять действие; если ошибка держится часами — это вопрос к поддержке сервиса.
• Ваш собственный API-ключ (например, к LLM-API). У некоторых провайдеров, в том числе OpenAI, 429 приходит в двух разных случаях: превышена частота запросов или исчерпана квота/баланс. Первое лечится паузой, второе — только пополнением или сменой тарифа. Различайте их по тексту ошибки в теле ответа.

Код 429 в играх и лаунчерах — это ответ их собственных серверов; разбирать её здесь мы не будем.

Ошибка 429 на сайте: что делать владельцу

Если 429 видят ваши посетители или поисковые роботы, сначала выясните, кто именно получает ошибку и какой механизм её отдаёт — nginx, WAF/CDN или приложение.

Найти, кому сервер отдаёт 429

В стандартном формате журнала nginx (combined) код ответа — девятое поле. Подробнее о форматах и расположении журналов — в статье про логи nginx.

# Сколько всего ответов 429
awk '$9 == 429' /var/log/nginx/access.log | wc -l

# Какие IP-адреса чаще всего упираются в лимит
awk '$9 == 429 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Какие URL чаще всего отвечают 429
awk '$9 == 429 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Срабатывания limit_req пишутся в error.log
grep "limiting requests" /var/log/nginx/error.log | tail -n 20

Если среди «виновников» один-два адреса с тысячами запросов — лимит работает как задумано. Если адресов много и это обычные посетители, лимит слишком строгий или считает не того клиента. Резкий рост с сотен адресов одновременно может означать атаку — порядок действий описан в статье DDoS-атака на сайт: что делать в первый час.

Проверить, что лимит считает реальный IP посетителя

Частая причина массовых 429: nginx стоит за балансировщиком, CDN или другим обратным прокси, и переменная $binary_remote_addr содержит адрес прокси, а не посетителя. Тогда все пользователи делят одно «ведро», и лимит исчерпывается за секунды. Лечится модулем realip:

# Адреса ваших прокси/балансировщиков (или диапазоны CDN)
set_real_ip_from 10.0.0.0/8;
real_ip_header   X-Forwarded-For;   # для Cloudflare: CF-Connecting-IP
real_ip_recursive on;

Доверять заголовку можно только от своих прокси: если указать set_real_ip_from 0.0.0.0/0, любой клиент подставит чужой адрес и обойдёт лимит.

Настройка limit_req в nginx

# Zone: 10MB хватит на ~160k уникальных IP
limit_req_zone $binary_remote_addr zone=api:10m rate=60r/m;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
        proxy_pass http://backend;
    }

    location /api/auth/login {
        limit_req zone=login burst=3 nodelay;
        limit_req_status 429;
        proxy_pass http://backend;
    }
}

Параметры:

• rate=60r/m — 1 запрос в секунду в среднем
• burst=20 — допускает всплеск до 20, остальные отбрасываются
• nodelay — не задерживает, сразу отдаёт 429 при превышении
• limit_req_status 429 — без этой строки nginx при превышении лимита отвечает 503, и владелец ищет «падение сервера», которого нет

Полное описание директив — в документации модуля ngx_http_limit_req_module. После правки проверьте конфигурацию и перечитайте её: sudo nginx -t && sudo systemctl reload nginx.

nginx не добавляет Retry-After к своим ответам 429 сам. Его можно выдать через именованный location:

location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;
    error_page 429 = @too_many;
    proxy_pass http://backend;
}

location @too_many {
    default_type application/json;
    add_header Retry-After 60 always;
    return 429 '{"error":"too_many_requests"}';
}

Чтобы исключить из лимита свои сервисы (мониторинг, офис, внутренние интеграции), сделайте ключ пустым — запросы с пустым ключом nginx не учитывает:

geo $limit {
    default        1;
    192.0.2.10     0;   # сервер мониторинга
    10.0.0.0/8     0;   # внутренняя сеть
}
map $limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}
limit_req_zone $limit_key zone=api:10m rate=60r/m;

В Apache модуль mod_ratelimit ограничивает скорость отдачи данных клиенту, а не число запросов, поэтому для ограничения частоты там используют сторонние модули или выносят лимит на nginx, WAF или в приложение.

Не ограничивайте поисковых роботов вслепую

Частые 429 для поисковых роботов замедляют обход сайта. Google прямо пишет, что считает 429 признаком перегрузки сервера: робот снижает частоту сканирования, а URL, которые долго отвечают ошибкой, со временем могут выпасть из индекса (документация Google Search Central). Не режьте роботов по User-Agent вслепую — его легко подделать. Настоящие Googlebot и YandexBot проверяются обратной DNS-записью: host 66.249.66.1 должен вернуть имя в домене робота, а прямой запрос этого имени — тот же IP.

Стратегии rate limiting

Token Bucket

Ведро с токенами пополняется с фиксированной скоростью. Каждый запрос забирает токен. Пусто — 429.

Leaky Bucket

Очередь фиксированного размера, обрабатывается с постоянной скоростью. Переполнена — 429. По этому принципу работает limit_req в nginx.

Fixed Window

Счётчик на минуту/час. Простой, но даёт всплески на границах окна: клиент может отправить полный лимит в конце одной минуты и ещё один — в начале следующей.

Sliding Window

Гибрид: учитывает запросы в предыдущем окне пропорционально. Самый равномерный подход. Подробнее про выбор алгоритма — в статье Защита API от перегрузки: token bucket, 429, Retry-After.

Rate limiting на уровне приложения (Redis sliding window)

<?php
function checkRateLimit(Redis $redis, string $key, int $max, int $window): array {
    $now = microtime(true);
    $pipe = $redis->multi();
    $pipe->zRemRangeByScore($key, 0, $now - $window);
    $pipe->zAdd($key, $now, "$now:" . bin2hex(random_bytes(4)));
    $pipe->zCard($key);
    $pipe->expire($key, $window * 2);
    $results = $pipe->exec();

    $count = $results[2];
    return [
        'allowed' => $count <= $max,
        'limit' => $max,
        'remaining' => max(0, $max - $count),
        'reset' => time() + $window,
    ];
}

// Использование
$rl = checkRateLimit($redis, "rl:user:{$userId}", 60, 60);
header("X-RateLimit-Limit: {$rl['limit']}");
header("X-RateLimit-Remaining: {$rl['remaining']}");
header("X-RateLimit-Reset: {$rl['reset']}");

if (!$rl['allowed']) {
    http_response_code(429);
    header('Retry-After: 60');
    header('Content-Type: application/json');
    echo json_encode(['error' => 'Too many requests']);
    exit;
}

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

Идентификация клиента: IP, User, API Key

Правильный tracker зависит от контекста:

• API с ключами — лимит по API Key
• Логин-эндпоинты — по IP (препятствует brute force)
• Пользовательские действия — по user_id (чтобы NAT не блокировал много пользователей одного IP)

// Иерархия: user ID > API key > IP
function getRateLimitKey(Request $req): string {
    if ($req->user?->id) return "user:{$req->user->id}";
    if ($req->apiKey) return "apikey:{$req->apiKey}";
    return "ip:{$req->ip}";
}

Как исправить ошибку 429 в клиенте API: exponential backoff

Если 429 получает ваш код, исправление — не «убрать ошибку», а научить клиент ждать. Правило: сначала уважайте Retry-After, при его отсутствии увеличивайте паузу экспоненциально и добавляйте случайный разброс (jitter), чтобы сотни клиентов не повторили запрос в одну и ту же секунду.

function retryDelayMs(res, attempt) {
  const header = res.headers.get('Retry-After');
  if (header) {
    const seconds = Number(header);
    if (Number.isFinite(seconds)) return seconds * 1000;      // "60"
    const date = Date.parse(header);                          // HTTP-дата
    if (!Number.isNaN(date)) return Math.max(0, date - Date.now());
  }
  const base = Math.min(1000 * 2 ** attempt, 60000);
  return base / 2 + Math.random() * (base / 2);               // jitter
}

async function fetchWithRetry(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const res = await fetch(url, options);
    if (res.status !== 429) return res;

    const waitMs = retryDelayMs(res, attempt);
    console.warn(`429 received, retrying in ${waitMs}ms`);
    await new Promise(r => setTimeout(r, waitMs));
  }
  throw new Error('Rate limit exceeded after retries');
}

Две ловушки. Первая: parseInt от HTTP-даты в Retry-After даёт NaN, пауза превращается в ноль, и клиент долбит сервер без остановки — поэтому дата разбирается отдельно. Вторая: при запросах из браузера к API на другом домене заголовок Retry-After не виден скрипту, пока сервер не перечислит его в Access-Control-Expose-Headers; то же касается X-RateLimit-*.

В Python то же поведение даёт встроенный механизм повторов urllib3:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

retry = Retry(
    total=5,
    backoff_factor=1,                  # паузы растут экспоненциально
    status_forcelist=[429, 503],
    respect_retry_after_header=True,
    allowed_methods=["GET", "HEAD"],   # POST повторять только с ключом идемпотентности
)
session = requests.Session()
session.mount("https://", HTTPAdapter(max_retries=retry))
resp = session.get("https://api.example.com/v1/items", timeout=10)

Никогда не ретрайте агрессивно без backoff — это усугубит rate limit и может триггерить бан на уровне WAF.

429 от внешнего API: что делать

1. Читайте Retry-After — это не рекомендация, а требование.
2. Используйте circuit breaker — временно отключайте запросы к деградирующему API.
3. Кэшируйте ответы Redis'ом с разумным TTL.
4. Пакуйте запросы в batch, если API поддерживает.
5. Разнесите фоновые задачи во времени: крон, запускающий сотню запросов ровно в 00:00, упирается в лимит сильнее, чем та же сотня, растянутая на минуту.
6. Попросите повышения лимита — обычно платные тарифы дают больше.

Для мониторинга доступности вашего API используйте Enterno.io Monitors с expected_code=200 — увидите 429-регрессии моментально.

429, 503 и 403: в чём разница

Подробнее о соседних кодах — в статьях Ошибка 503 Service Unavailable и все HTTP-коды ответа сервера.

Как проверить, отдаёт ли сайт код 429

Быстрее всего посмотреть код ответа и заголовки проверкой HTTP-заголовков: если там 429, видно и Retry-After, и X-RateLimit-*. Чтобы убедиться, что лимит на своём API срабатывает там, где задумано, отправьте серию запросов и посчитайте коды (делайте это только на своём сайте):

# Linux / macOS
for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{http_code}\n" https://example.com/api/
done | sort | uniq -c

# Заголовки ответа
curl -sI https://example.com/api/ | grep -iE "^(HTTP|retry-after|x-ratelimit|ratelimit)"

# Windows PowerShell
1..30 | ForEach-Object { curl.exe -s -o NUL -w "%{http_code}\n" https://example.com/api/ } | Group-Object | Select-Object Count, Name

Разовой проверки мало: лимит, который сегодня срабатывает на тридцатом запросе, после очередной правки конфигурации может начать резать всех подряд. Мониторинг с ожидаемым кодом 200 пришлёт уведомление, как только вместо него придёт 429 или 503.

Частые вопросы

Сколько ждать, если сервер ответил 429?

Столько, сколько указано в заголовке Retry-After. Если его нет, обычно хватает нескольких минут. Главное — не обновлять страницу и не повторять запрос в цикле: каждая попытка продлевает ограничение.

Почему лимит срабатывает, если я сделал всего пару запросов?

Лимит считается по IP-адресу, а вы можете делить его с другими: через VPN, прокси, офисную сеть или общий адрес провайдера (CGNAT). Запросы также могут отправлять расширения браузера и программы в фоне.

Влияет ли 429 на SEO?

Для Googlebot — да, если частый. Googlebot уменьшает crawl rate, а страницы, которые долго отвечают ошибкой, могут выпасть из индекса. Поддерживайте Retry-After и не ограничивайте проверенных поисковых роботов.

Какой rate limit для API адекватен?

Зависит от нагрузки и сценария. Типичные ориентиры: 60 req/min для общих API, 5 req/min для login, 10 req/sec для реалтайм-эндпоинтов. Отталкивайтесь от реального трафика в журналах, а не от чужих цифр.

Можно ли обойти ограничение 429?

Честный путь: запросить повышение лимита, оптимизировать количество запросов, кэшировать и соблюдать паузы. Обход через ротацию IP = нарушение ToS и риск бана.