Как да разрешите грешката 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 плъгини, персонализиран middleware или API шлюзове налагат собствени ограничения, независимо от уеб сървъра.
• Изчерпване на квотата на API на трети страни — Вашето приложение извиква външен API (Google Maps, Stripe, OpenAI) по-бързо, отколкото квотата на доставчика позволява, и грешката 429 се предава обратно до крайния потребител.
• Злонамерен или неконтролиран автоматизиран трафик — Опити за влизане с груба сила, агресивни скрейпъри, неправилно конфигурирани скриптове за мониторинг или лошо написани кроулъри изчерпват бюджетите за заявки.

Често пропускан краен случай: среди за споделен хостинг, при които скок в трафика на съседен наемател изчерпва споделените пулове от връзки, карайки вашето приложение да получава отговори 429 от upstream балансьор на натоварването, въпреки че вашият собствен код се държи правилно. Ако използвате план за Споделен Уеб Хостинг и виждате периодични изблици на 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 срещу без флаг:

• Без 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: Блокирайте и управлявайте ботове на множество слоеве

Ботовете рядко се обявяват честно, но оставят отпечатъци в низовете на потребителския агент, моделите на заявки и аномалиите в заглавките.

Блокирайте известни лоши ботове в 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 и прегледайте:

• Как трябва да третираме кроулърите на Google — задайте на „Verified Google crawlers are not rate limited”, за да предотвратите въздействие върху SEO.
• Ако заявките на някого надвишат — увеличете прага от стойността по подразбиране (напр. от 240 на 480 заявки в минута за влезли потребители на сайтове с богато съдържание).
• Ако прегледите на страниците от кроулър надвишат — настройте въз основа на действителните ви изисквания за бюджет за обхождане.

След коригирането наблюдавайте изгледа на живия трафик на 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 произхожда от upstream балансьор на натоварването или обратен прокси, който не контролирате.
• Анализът на логовете показва, че вашето приложение е в рамките на очакваните обеми на заявки, но грешката продължава.
• Имате нужда от временно освобождаване от ограничението за заявки по време на планиран скок в трафика (пускане на продукт, маркетингова кампания).
• Грешката се появява само в конкретни географски региони, което предполага проблеми с CDN или anycast маршрутизиране.

При работа с план за VPS Хостинг, имате директен достъп до конфигурационните файлове на сървъра и можете да приложите всички промени в Nginx и Apache, описани по-горе, без да отваряте тикет за поддръжка. При управлявана инфраструктура като Dedicated сървъри, екипът за поддръжка на вашия доставчик може да помогне с проследяване на връзките на ниво ядро и правила за хардуерна защитна стена, които надхвърлят възможностите на конфигурацията на ниво приложение.

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

Защита на API крайни точки с SSL

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

Техническа матрица за вземане на решения: Избор на правилното решение

Използвайте този контролен списък, за да насочите диагнозата си към правилното решение:

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

ЧЗВ

Каква е разликата между грешка 429 и грешка 503?

429 е умишлен отказ, основан на политика, издаван когато клиент надвиши определена скорост на заявките. 503 указва, че сървърът временно не може да обработва заявки поради претоварване или поддръжка. Решението за 429 е коригиране на ограничението за заявки или поведението на клиента; решението за 503 е мащабиране на капацитета или възстановяване на услугата.

Трябва ли винаги да увеличавам ограниченията за заявки, когато видя 429?

Не. Увеличаването на ограниченията е подходящо само когато легитимният трафик се блокира. Ако 429 е причинена от ботове, опити за груба сила или неправилно конфигуриран скрипт, повишаването на ограничението влошава проблема, като позволява преминаването на повече злонамерен трафик. Винаги идентифицирайте първо източника.

Какво прави заглавката Retry-After и трябва ли винаги да я включвам?

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

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

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

Как да предотвратя собственото си приложение да задейства грешки 429 на външни API?

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