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

Что такое ошибка HTTP 429?

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

Код появился в RFC 6585 (2012) именно для такого случая, а в ответ может быть добавлен заголовок Retry-After, который говорит, сколько ждать. С ошибкой сталкиваются на загруженных сайтах, при работе с API, при массовых загрузках и в VPN, где одним IP-адресом пользуются многие.

От соседних кодов она отличается так: 401 значит, что вы не вошли в аккаунт, 403 — что доступ вам запрещён, а 429 — что доступ есть, но вы действуете слишком быстро.

Как выглядит ошибка 429?

Текст зависит от того, кто отвечает. Вот варианты, которые чаще всего ищут:

В отличие от ошибки 500, которая означает сбой на стороне сервера, 429 в терминах HTTP — клиентская ошибка: сервер защищается от слишком большого числа запросов.

Как работает ограничение частоты запросов

Ограничение частоты запросов (rate limiting) — приём, с помощью которого сервер контролирует, сколько запросов клиент может отправить за период времени. При превышении лимита сервер обычно отвечает 429 (некоторые отвечают 403 или 503).

Есть несколько распространённых алгоритмов ограничения:

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

Многие API сообщают свои лимиты в заголовках ответа. У GitHub, например, это x-ratelimit-limit (сколько запросов разрешено в час), x-ratelimit-remaining, x-ratelimit-used и x-ratelimit-reset (когда окно сбросится, в секундах Unix). Черновик IETF предлагает для этого стандартные заголовки RateLimit и RateLimit-Policy.

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

Частые причины ошибки HTTP 429

Причина зависит от того, кто видит ошибку:

Как исправить ошибку 429 (для посетителей)

Если вы видите ошибку 429 при просмотре сайта, попробуйте эти способы. Начинайте с самого простого и двигайтесь дальше по списку.

1. Подождите и повторите попытку

Самое простое решение — подождать. Ошибка 429 временная: сервер просит вас сбавить темп, а не банит вас.

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

Не обновляйте страницу снова и снова: каждое обновление — ещё один запрос, и он засчитывается в тот же лимит.

2. Очистите куки сайта

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

• Chrome / Edge: откройте chrome://settings/content/all (в Edge: edge://settings/content/all), найдите сайт и удалите его данные
• Firefox: нажмите на замок в адресной строке → «Удалить куки и данные сайта…»
• Safari: Safari → «Настройки» → «Конфиденциальность» → «Управлять данными веб-сайта» → найдите сайт → «Удалить»

После очистки закройте и снова откройте браузер, а затем зайдите на сайт.

3. Отключите VPN или прокси

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

Отключите VPN и зайдите на сайт через обычное интернет-соединение. Если ошибка 429 исчезла, проблема была в IP-адресе VPN.

Если VPN нужен, переключитесь на другой сервер: его адресом, возможно, пользуется меньше людей.

4. Отключите расширения браузера

Некоторые расширения в фоне отправляют запросы к посещаемым вами сайтам: трекеры цен, SEO-инструменты и расширения автообновления могут в сумме превысить лимит. (Блокировщики рекламы обычно, наоборот, сокращают число запросов.)

Чтобы проверить, откройте сайт в режиме инкогнито (приватном окне), где большинство расширений отключено. В инкогнито к тому же нет ваших кук, поэтому, если 429 пропала, дело в расширении или в лимите по сессии.

Отключайте расширения по одному, чтобы найти виновника. В Chrome откройте chrome://extensions/ и выключайте их по очереди.

5. Проверьте, не общий ли у вас IP-адрес

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

Если вы в такой сети, зайдите на сайт из домашнего интернета или через мобильные данные: так станет ясно, виноват ли общий адрес. Если лимит исчерпан на вашем собственном адресе, дождитесь сброса, а не меняйте сети, чтобы его обойти. Свой текущий публичный IP можно узнать в инструменте Мой IP-адрес.

Как исправить ошибку 429 (для разработчиков)

Если ваш код получает 429, он отправляет запросы быстрее, чем позволяет API. Действуйте по порядку: прочитайте Retry-After, повторяйте запросы с нарастающей задержкой и джиттером, затем сократите число запросов.

1. Внедрите экспоненциальную задержку (exponential backoff)

Экспоненциальная задержка (exponential backoff) — стандартная стратегия повторов: вместо немедленного повтора после 429 вы удваиваете паузу каждый раз (1 секунда, 2, 4, 8…) и добавляете джиттер — случайную добавку к задержке, чтобы множество клиентов не повторяли запросы в один и тот же момент.

Эта версия использует Retry-After, если сервер прислал корректное значение (в любом из двух форматов), иначе переходит на задержку с джиттером и сдаётся после нескольких попыток. (В браузере при вызове API другого сайта Retry-After доступен, только если API раскрывает его через Access-Control-Expose-Headers.)

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

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Учитывайте заголовок Retry-After

Когда сервер присылает Retry-After вместе с 429, он точно говорит, сколько ждать. RFC 9110 допускает две формы: число секунд или дату HTTP.

Retry-After: 60 значит «ждите 60 секунд». Retry-After: Wed, 21 Oct 2026 07:28:00 GMT значит «ждите до этого времени». Проверяйте его раньше собственной логики задержки: сервер знает лучше, чем ваш код.

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

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. Кэшируйте ответы API

Если приложение делает один и тот же вызов API несколько раз, кэшируйте ответ, а не обращайтесь к API каждый раз. Это резко сокращает число запросов.

Используйте кэш в памяти (например, Redis или обычный Map) для часто запрашиваемых данных. Задайте разумный TTL (время жизни) в зависимости от того, как часто данные меняются.

Например, если вы проверяете DNS-записи домена, в ближайшие 5 минут они, скорее всего, не изменятся — кэшируйте их.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Используйте вебхуки вместо опроса

Если вы постоянно опрашиваете API, чтобы узнать об изменениях (например, проверяете статус заказа каждые 10 секунд), перейдите на вебхуки, если сервис их поддерживает.

При использовании вебхуков сервер сам отправляет обновления в ваше приложение, когда что-то меняется, и постоянный опрос не нужен. Так количество обращений к API может снизиться с тысяч в час до нескольких штук.

Большинство современных API (Stripe, GitHub, Twilio, Shopify) поддерживают вебхуки. Как их настроить, смотрите в документации API.

5. Запросите более высокие лимиты

Если вам действительно нужно больше вызовов API, обратитесь к провайдеру сервиса. Многие API предлагают повышенные лимиты на платных тарифах или для проверенных приложений.

Запрашивая повышение, опишите свой сценарий и оцените ожидаемый объём запросов. У многих API, в том числе у Google, есть форма заявки или платный тариф для повышенных лимитов.

Некоторые API также предлагают пакетные эндпоинты (bulk endpoints), которые позволяют получить несколько ресурсов одним запросом и сократить общее число вызовов.

Как исправить ошибку 429 (для владельцев сайтов)

Если ваши посетители или потребители API получают ошибки 429, проблема в конфигурации вашего сервера. Вот как её найти и исправить.

1. Настройте лимиты запросов

Если реальные пользователи получают 429, выясните, какой уровень отвечает первым: CDN или WAF, веб-сервер или само приложение. Затем настройте лимиты именно этого уровня.

В nginx работу выполняет limit_req. Учтите, что по умолчанию он отвечает 503: добавьте limit_req_status 429;, чтобы клиенты понимали, что нужно сбавить темп, а не думали, что сервер лежит:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Параметр burst пропускает короткие всплески без 429; без него обычная загрузка страницы с множеством запросов может упереться в лимит.

В Apache нет встроенного ограничителя частоты запросов: его mod_ratelimit ограничивает пропускную способность, а не число запросов, а сторонний mod_evasive отвечает 403. Для 429 используйте обратный прокси, WAF или само приложение. В Node.js express-rate-limit по умолчанию отвечает 429.

2. Добавьте доверенные IP-адреса в белый список

Если ограничения получают определённые клиенты (сервисы мониторинга, платёжные процессоры, ваши собственные микросервисы), добавьте их IP-адреса в белый список.

В nginx geo и map дают доверенным адресам пустой ключ, а запросы с пустым ключом nginx не считает. Это заменяет строку limit_req_zone из предыдущего примера:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

Не ограничивайте поисковых роботов по ошибке: Google считает 429 ошибкой сервера и замедляет сканирование (Google Search Central). Подлинные запросы Googlebot и Bingbot проверяйте обратным DNS-запросом (reverse DNS) с подтверждением прямым запросом по полученному имени или исключите опубликованные диапазоны IP этих роботов.

3. Проверьте настройки WAF и CDN

Если вы используете Cloudflare, AWS WAF, Sucuri или другой сервис защиты, его правила ограничения запросов могут сработать раньше, чем запрос дойдёт до вашего сервера.

Cloudflare показывает посетителям «Error 1015: You are being rate limited», когда срабатывает правило ограничения запросов. Найдите правило среди правил безопасности в панели, посмотрите его события и поднимите порог или сузьте область действия.

Правила AWS WAF на основе частоты (rate-based) считают запросы с одного IP (или по другому ключу) за окно в 1, 2, 5 или 10 минут, минимальный лимит — 10. Заблокированный запрос по умолчанию получает 403; задайте собственный ответ 429, чтобы клиенты знали, что нужно сбавить темп.

Прежде чем что-то менять, посмотрите аналитику CDN, чтобы отделить реальных посетителей от ботов.

4. Оптимизируйте производительность сервера

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

Основные меры: включите кэширование ответов, чтобы снизить нагрузку на бэкенд, используйте CDN для статики, добавьте кэширование запросов к базе данных через Redis или Memcached, примените пул соединений с базой и масштабируйтесь горизонтально с балансировкой нагрузки, если трафик это оправдывает.

Правильность заголовков кэширования можно проверить нашим инструментом Проверка HTTP-заголовков.

429 и другие ошибки HTTP

Ошибку 429 легко спутать с другими HTTP-кодами. Вот чем они отличаются:

Главное отличие: 429 — это намеренное и временное решение: сервер сам отказывает вам на время. Большинство кодов 5xx означают, что на сервере что-то сломалось, хотя 503 может быть и плановым обслуживанием или, в nginx, ограничением частоты.

Как предотвратить ошибки 429

Профилактика лучше лечения. Вот практики, которые помогут вообще не получать ошибки 429:

• Читайте документацию API — узнайте лимиты до написания кода. Большинство сервисов публикуют их чётко.
• Следите за расходом — отслеживайте заголовки X-RateLimit-Remaining, чтобы понимать, как близко вы к лимиту.
• Объединяйте запросы — используйте пакетные эндпоинты, если они есть, вместо отдельных вызовов.
• Распределяйте запросы — равномерно растягивайте вызовы API во времени, а не отправляйте всплесками.
• Используйте ключи API — запросы с аутентификацией обычно получают более высокие лимиты, чем анонимные.
• Внедрите circuit breaker — если вы раз за разом получаете 429, полностью прекратите отправку запросов на время паузы.
• Тестируйте на симуляторах лимитов — имитируйте ответы 429 при разработке, чтобы убедиться, что обработка ошибок работает.
• Логируйте ответы 429 — отслеживайте, когда и где срабатывает ограничение, чтобы оптимизировать свои запросы.