Как устранить ошибку 429 Too Many Requests

Ошибка 429 Too Many Requests — это HTTP-код состояния, определённый в RFC 6585, который сигнализирует о том, что клиент превысил ограничение скорости запросов, установленное сервером или промежуточным прокси. Сервер отклоняет дальнейшие запросы до сброса окна ограничения скорости, при этом опционально возвращая заголовок Retry-After, указывающий, сколько времени клиент должен ждать.

В отличие от ошибки 503 Service Unavailable, которая отражает сбой пропускной способности на стороне сервера, ошибка 429 является намеренным, политически обусловленным отказом. Понимание этого различия критически важно: решение не всегда связано с масштабированием инфраструктуры — речь идёт об определении того, *кто* отправляет слишком много запросов, *почему*, и последующем исправлении поведения на нужном уровне стека.

Что на самом деле вызывает ошибку 429

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

• Ограничение скорости на стороне сервера — веб-серверы (Apache, Nginx), обратные прокси (HAProxy, Varnish) или CDN-узлы (Cloudflare, Fastly) применяют пороговые значения запросов на IP или токен.
• Ограничение на уровне приложения — плагины WordPress, пользовательское промежуточное ПО или API-шлюзы устанавливают собственные ограничения независимо от веб-сервера.
• Исчерпание квоты стороннего API — ваше приложение обращается к внешнему API (Google Maps, Stripe, OpenAI) быстрее, чем позволяет квота провайдера, и ошибка 429 передаётся конечному пользователю.
• Вредоносный или неконтролируемый автоматизированный трафик — попытки брутфорса при входе, агрессивные парсеры, неправильно настроенные скрипты мониторинга или плохо написанные краулеры исчерпывают бюджет запросов.

Часто упускаемый из виду крайний случай: среды общего хостинга, где всплеск трафика соседнего арендатора потребляет общие пулы соединений, из-за чего ваше приложение получает ответы 429 от вышестоящего балансировщика нагрузки, даже если ваш собственный код работает корректно. Если вы используете план Shared Web Hosting и наблюдаете периодические всплески ошибок 429 без соответствующего роста собственного трафика — это первая гипотеза для проверки.

Шаг 1: Определите источник избыточных запросов

Исправлять ошибку 429 без определения её источника — значит действовать наугад. Начните с данных.

Чтение журналов доступа Apache

grep " 429 " /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Эта команда извлекает все ответы 429, подсчитывает их количество по IP-адресам и ранжирует результаты. IP-адрес, появляющийся тысячи раз за несколько минут, — это либо бот, либо неправильно настроенный скрипт, либо злоумышленник.

Чтение журналов доступа Nginx

awk '$9 == 429 {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Корреляция с путями запросов

grep " 429 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Если в выводе преобладает /wp-login.php или /xmlrpc.php, вы имеете дело с кампанией брутфорса или подстановки учётных данных. Если в начале списка находится конечная точка API вроде /api/v1/search, виновником, скорее всего, является неправильно настроенный клиент или парсер.

Использование fail2ban для выявления паттернов

fail2ban-client status
fail2ban-client status nginx-req-limit

Если fail2ban настроен с ловушкой nginx-req-limit, он покажет вам именно те IP-адреса, которые были заблокированы из-за нарушений ограничения скорости, что значительно экономит время на разбор журналов.

Шаг 2: Настройте ограничение скорости на уровне веб-сервера

Apache: использование mod_ratelimit и mod_evasive

Фрагмент .htaccess, широко распространённый в интернете, использует mod_rewrite для возврата кода 403, а не корректного кода 429. Более семантически правильный и операционно надёжный подход использует mod_evasive для защиты от DoS-атак.

Установите и настройте mod_evasive на Debian/Ubuntu:

apt install libapache2-mod-evasive
a2enmod evasive

Затем добавьте в виртуальный хост Apache или глобальную конфигурацию:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
    DOSEmailNotify      admin@yourdomain.com
    DOSLogDir           /var/log/mod_evasive
</IfModule>

Это блокирует любой IP-адрес, который обращается к одной странице более 5 раз в секунду или ко всему сайту более 50 раз в секунду, на период охлаждения в 10 секунд.

Для получения корректного ответа 429 через .htaccess в Apache с mod_rewrite необходим пользовательский документ об ошибке:

ErrorDocument 429 "Too Many Requests"

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} ^.*(SemrushBot|AhrefsBot|MJ12bot|DotBot).*$ [NC]
    RewriteRule .* - [R=429,L]
</IfModule>

Nginx: limit_req_zone с правильной обработкой всплесков

Директива ngx_http_limit_req_module в Nginx является одним из наиболее эффективных инструментов ограничения скорости. Ключевые параметры, которые часто настраиваются неверно, — это burst и nodelay.

В /etc/nginx/nginx.conf или выделенном файле подключения:

http {
    # Zone keyed by client IP, 10MB shared memory, 10 requests/second baseline
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

    # Return 429 instead of the default 503
    limit_req_status 429;

    server {
        location /api/ {
            limit_req zone=api_limit burst=20 nodelay;
        }

        location /wp-login.php {
            limit_req zone=login_limit burst=3 nodelay;
        }
    }
}

Важный нюанс: без limit_req_status 429 Nginx по умолчанию возвращает код 503 для запросов с превышением лимита. Установка значения 429 семантически корректна и позволяет клиентам реализовать правильную логику отступа Retry-After.

nodelay vs. без флага:

• Без nodelay: избыточные запросы ставятся в очередь и обслуживаются с задержкой, потребляя рабочие соединения.
• С nodelay: избыточные запросы сверх всплеска немедленно отклоняются с кодом 429, что быстрее освобождает ресурсы. Используйте nodelay для конечных точек входа и публичных API.

Добавление заголовка Retry-After

Клиенты, соблюдающие RFC 6585, будут учитывать заголовок Retry-After. В Nginx добавьте его в ответ об ошибке:

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    add_header Retry-After 60 always;
}

Шаг 3: Диагностика и устранение конфликтов плагинов WordPress

WordPress является распространённым источником самостоятельно вызванных ошибок 429. Плагины, опрашивающие внешние API при каждой загрузке страницы — SEO-инструменты, получающие данные о ключевых словах, аналитические плагины, отправляющие данные домой, или расширения WooCommerce, запрашивающие платёжные шлюзы, — могут быстро исчерпать лимиты запросов.

Систематическая процедура изоляции:

1. Деактивируйте все плагины через панель управления WordPress или, если панель недоступна, через WP-CLI:

wp plugin deactivate --all

1. Активируйте плагины по одному, тестируя после каждой активации:

wp plugin activate plugin-slug

1. Отслеживайте журнал доступа в отдельном терминале во время повторной активации:

tail -f /var/log/nginx/access.log | grep " 429 "

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

Распространённые виновники: Jetpack (модули статистики и синхронизации), Yoast SEO (при подключении к MyYoast), WooCommerce Subscriptions и любой плагин, использующий встроенный wp_remote_get() WordPress в цикле без кэширования транзиентов.

Правильное решение почти никогда не заключается в удалении плагина — необходимо обеспечить кэширование ответов API с помощью транзиентов WordPress:

$cached = get_transient( 'my_api_response' );
if ( false === $cached ) {
    $response = wp_remote_get( 'https://api.example.com/data' );
    set_transient( 'my_api_response', $response, HOUR_IN_SECONDS );
    $cached = $response;
}

Шаг 4: Реализуйте ограничение запросов к API в коде приложения

Когда ваше приложение является *клиентом*, обращающимся к стороннему API, вы несёте ответственность за соблюдение их лимитов запросов. Полагаться на реактивный перехват ответов 429 — это плохая инженерная практика; реализуйте проактивное ограничение скорости.

Node.js с p-throttle

import pThrottle from 'p-throttle';

const throttle = pThrottle({
    limit: 10,       // max 10 calls
    interval: 1000   // per 1000ms (1 second)
});

const throttledFetch = throttle(async (url) => {
    const response = await fetch(url);
    return response.json();
});

Python с tenacity для экспоненциального отступа

Одного ограничения скорости недостаточно, если API устанавливает лимиты всплесков. Сочетайте ограничение скорости с экспоненциальным отступом при получении ответов 429:

import requests
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception

def is_rate_limited(exception):
    return (
        isinstance(exception, requests.HTTPError)
        and exception.response.status_code == 429
    )

@retry(
    retry=retry_if_exception(is_rate_limited),
    wait=wait_exponential(multiplier=1, min=2, max=60),
    stop=stop_after_attempt(5)
)
def call_api(url):
    response = requests.get(url)
    response.raise_for_status()
    return response.json()

Это выполняет до 5 повторных попыток с экспоненциальным отступом (2 с, 4 с, 8 с, 16 с, 32 с) с максимальным значением 60 секунд — паттерн, который уважает инфраструктуру провайдера API и обеспечивает корректное восстановление.

Соблюдение заголовка Retry-After

Если API возвращает заголовок Retry-After, используйте его вместо фиксированного отступа:

def call_with_retry_after(url):
    response = requests.get(url)
    if response.status_code == 429:
        retry_after = int(response.headers.get("Retry-After", 5))
        time.sleep(retry_after)
        return call_with_retry_after(url)
    response.raise_for_status()
    return response.json()

Шаг 5: Блокировка ботов и управление ими на нескольких уровнях

Боты редко честно идентифицируют себя, но оставляют следы в строках user-agent, паттернах запросов и аномалиях заголовков.

Блокировка известных вредоносных ботов в Nginx

map $http_user_agent $bad_bot {
    default         0;
    ~*SemrushBot    1;
    ~*AhrefsBot     1;
    ~*MJ12bot       1;
    ~*DotBot        1;
    ~*PetalBot      1;
    ~*serpstatbot   1;
}

server {
    if ($bad_bot) {
        return 429;
    }
}

Управление скоростью обхода через robots.txt

User-agent: Googlebot
Crawl-delay: 2

User-agent: *
Crawl-delay: 10

Обратите внимание, что Crawl-delay соблюдается не всеми краулерами, однако сигнализирует о намерениях и учитывается Bing, Yandex и большинством добросовестных ботов.

Интеграция с брандмауэром веб-приложений (WAF)

WAF, работающий на CDN-узле (Cloudflare, AWS WAF, Sucuri), может применять ограничения скорости до того, как трафик достигнет вашего исходного сервера, что значительно снижает нагрузку. Например, правила ограничения скорости Cloudflare можно настроить для проверки или блокировки IP-адресов, превышающих пороговое значение, без каких-либо изменений в конфигурации исходного сервера — это существенное операционное преимущество для сайтов с высоким трафиком.

Шаг 6: Настройте параметры плагина безопасности в WordPress

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

Перейдите в Wordfence > Firewall > All Firewall Options > Rate Limiting и проверьте:

• How should we treat Google’s crawlers — установите значение «Verified Google crawlers are not rate limited», чтобы предотвратить негативное влияние на SEO.
• If anyone’s requests exceed — увеличьте порог по умолчанию (например, с 240 до 480 запросов в минуту для авторизованных пользователей на контентоёмких сайтах).
• If a crawler’s page views exceed — настройте в соответствии с фактическими требованиями к бюджету обхода.

После настройки отслеживайте представление Live Traffic в Wordfence в течение 24–48 часов, чтобы убедиться, что легитимные пользователи больше не блокируются.

Шаг 7: Очистите кэш на стороне клиента и диагностируйте проблемы на уровне браузера

Кэшированный ответ 429 в браузере встречается редко, но возможен, если ответ содержал заголовки Cache-Control: max-age (неправильная конфигурация сервера). Стандартные ответы 429 не должны кэшироваться.

Chrome:

Settings > Privacy and Security > Clear browsing data

Выберите Cached images and files и Cookies and other site data, затем выполните очистку.

Проверьте заголовки ответа напрямую с помощью curl, чтобы исключить поведение, специфичное для браузера:

curl -I -X GET https://yourdomain.com/problematic-endpoint

Обратите внимание на заголовки Cache-Control, Retry-After и X-RateLimit-* в ответе. Эти заголовки точно указывают, какой уровень применяет ограничение и когда клиент может повторить попытку.

Сравнение: подходы к ограничению скорости по уровням

Когда обращаться к хостинг-провайдеру

Обратитесь к хостинг-провайдеру, если:

• Ошибка 429 исходит от вышестоящего балансировщика нагрузки или обратного прокси, которые вы не контролируете.
• Анализ журналов показывает, что ваше приложение находится в пределах ожидаемых объёмов запросов, но ошибка сохраняется.
• Вам необходимо временное исключение из ограничения скорости во время запланированного всплеска трафика (запуск продукта, маркетинговая кампания).
• Ошибка появляется только в определённых географических регионах, что указывает на проблемы с CDN или anycast-маршрутизацией.

При использовании плана VPS Hosting у вас есть прямой доступ к файлам конфигурации сервера, и вы можете реализовать все описанные выше изменения Nginx и Apache без открытия заявки в службу поддержки. На управляемой инфраструктуре, такой как Dedicated Servers, команда поддержки провайдера может помочь с отслеживанием соединений на уровне ядра и правилами аппаратного брандмауэра, которые выходят за рамки возможностей конфигурации на уровне приложения.

Если ваш стек включает панель управления, VPS с cPanel предоставляет доступ к настройкам ModSecurity и ограничения скорости Apache через графический интерфейс, что упрощает конфигурацию для команд без глубоких знаний командной строки.

Защита конечных точек API с помощью SSL

Часто упускаемый из виду фактор: незашифрованные HTTP-конечные точки более уязвимы для атак повторного воспроизведения и подстановки учётных данных, которые провоцируют ошибки 429, вызванные брутфорсом. Принудительное использование HTTPS с действующим SSL-сертификатом гарантирует, что токены аутентификации и сессионные куки не могут быть перехвачены и воспроизведены автоматизированными инструментами, что устраняет одну категорию трафика, вызывающего превышение лимитов запросов, у самого источника.

Матрица технических решений: выбор правильного исправления

Используйте этот контрольный список для направления диагностики к правильному решению:

• 429 на /wp-login.php или /xmlrpc.php — усильте limit_req Nginx для этих путей, полностью заблокируйте xmlrpc.php, если не требуется, включите защиту от брутфорса в Wordfence.
• 429 на конечных точках API из собственного кода приложения — реализуйте экспоненциальный отступ с разбором заголовка Retry-After; добавьте кэширование транзиентов/Redis для снижения частоты исходящих вызовов.
• 429, периодически затрагивающая всех пользователей на общем хостинге — перейдите на VPS для изолированных ресурсов и настраиваемых ограничений скорости.
• 429 от стороннего API, используемого вашим приложением — проверьте частоту вызовов, реализуйте очередь запросов, агрессивно кэшируйте ответы и свяжитесь с провайдером API для обсуждения увеличения квоты.
• 429, вызванная конкретным ботом или краулером — заблокируйте на уровне WAF или map Nginx по user-agent; проверьте легитимные краулеры (Googlebot) через обратный DNS перед блокировкой.
• 429, появляющаяся только в браузере, но не в curl — очистите кэш браузера; проверьте, не кэширует ли ответ об ошибке service worker; изучите заголовки Cache-Control в ответе 429.
• 429 без идентифицируемого паттерна в журналах — проверьте журналы вышестоящего CDN или балансировщика нагрузки; ограничение может применяться на уровне инфраструктуры, невидимом в журналах приложения.

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

В чём разница между ошибками 429 и 503?

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

Следует ли всегда увеличивать лимиты скорости при появлении ошибки 429?

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

Что делает заголовок Retry-After и следует ли всегда его включать?

Заголовок Retry-After сообщает клиенту, сколько секунд ждать перед повторной попыткой. RFC 6585 рекомендует включать его в каждый ответ 429. Добросовестные HTTP-клиенты и потребители API будут его учитывать, снижая количество повторных запросов, которые усугубляют исходную проблему ограничения скорости.

Может ли ошибка 429 навредить SEO?

Да, если Googlebot постоянно получает ответы 429, он снизит частоту обхода вашего сайта, что может задержать индексацию нового или обновлённого контента. Wordfence и аналогичные плагины следует настроить так, чтобы верифицированные краулеры Google были освобождены от ограничений скорости. Отслеживайте отчёт Crawl Stats в Google Search Console на предмет всплесков ошибок сервера.

Как предотвратить генерацию ошибок 429 на внешних API собственным приложением?

Реализуйте сочетание проактивного ограничения скорости (ограничьте частоту исходящих запросов ниже задокументированного порога API), агрессивного кэширования ответов (сохраняйте результаты API в Redis или Memcached с соответствующими TTL) и реактивного экспоненциального отступа (разбирайте заголовки Retry-After и выполняйте отступ соответственно). Никогда не выполняйте вызовы API синхронно при каждой загрузке страницы без кэширующего уровня перед ними.