Коротко. 429 Too Many Requests означает, что сервер получил слишком много запросов за короткое время и временно отказывается их обрабатывать. Это не поломка страницы и не запрет доступа. Чаще всего лимит включён на уровне nginx, CDN, API или формы. Смотреть нужно заголовок Retry-After и логи того участка, который поставил ограничение.
Как читать материал. В ключевых разделах два пути: проверить руками и ускорить разбор нейросетью. Третий пункт — проверка. Нейросеть не видит сервер и не знает, кто поставил лимит, поэтому выводы сверяем с заголовками ответа и логами.
Что означает ошибка 429
Код появился в RFC 6585 как ответ на rate limiting — ограничение частоты запросов. Сервер говорит: запрос понятен, но сейчас я его не обслужу, потому что запросов слишком много.
В ответе может быть Retry-After — сколько секунд подождать. Это рекомендация, а не гарантия: через указанное время лимит может снова сработать.
429, 503 и 403: в чём разница
| Код | Что означает | Кто обычно ставит |
|---|---|---|
| 429 Too Many Requests | Слишком много запросов от одного клиента | nginx, CDN, API, WAF |
| 503 Service Unavailable | Сервис временно недоступен целиком | хостинг, приложение, обслуживание |
| 403 Forbidden | Доступ запрещён правилом | права, WAF, конфиг |
429 почти всегда про конкретного клиента или IP. 503 — про весь сервис. Если ошибку видит один посетитель, а остальные сайт открывают, это чаще 429 или блокировка.
Кто отдаёт 429
- nginx. Директивы
limit_reqиlimit_connограничивают частоту и число соединений. По умолчанию они отвечают 503, но код меняют черезlimit_req_statusиlimit_conn_status. - CDN и WAF. Cloudflare и аналогичные сервисы включают правила rate limiting для защиты от ботов и перебора.
- API. У внешних сервисов есть квоты: запросов в минуту, в сутки, на ключ.
- Формы и CMS. Плагины антиспама ограничивают отправки с одного IP.
- Хостинг. Некоторые панели ограничивают число процессов и могут отдать 429 при всплеске.
Как проверить
Начните с заголовков. Команда покажет код и служебные поля:
curl -I https://site.ru/api/search
Если в ответе есть Retry-After: 120, сервер прямо говорит, сколько ждать. Если заголовка нет, смотрите логи nginx:
grep "limiting requests" /var/log/nginx/error.log | tail -20
Строка вида limiting requests, excess: … by zone означает, что сработал limit_req. Для соединений ищите limiting connections.
Классический путь. Снимите заголовки через curl -I, затем найдите в логах зону, которая сработала.
С нейросетью. Отдайте ей фрагмент лога и конфиг nginx, попросите назвать зону и порог.
Вот строки error.log и блок limit_req из конфига. Определи, какая зона
сработала, какой порог задан и какие запросы его превышают. Не предлагай
менять лимит, пока не назовёшь источник всплеска. Ответь таблицей:
строка лога, зона, порог, что проверить.
Проверка. Сверьте название зоны с конфигом, а частоту — с логом доступа. Модель может перепутать зоны, если в файле несколько limit_req_zone.
Как исправить
| Причина | Что делать |
|---|---|
| Всплеск от бота или парсера | ограничить по IP и user-agent, включить challenge в CDN |
| Форма отправляется повторно | блокировать кнопку после отправки, добавить серверную проверку |
| API-клиент делает слишком много запросов | кэшировать ответы, объединять запросы, повторять с паузой (backoff) |
| Лимит слишком жёсткий | поднять порог для доверенных сценариев, оставить защиту для остальных |
| 429 от чужого сервиса | проверить квоту в кабинете, дождаться окна или сменить тариф |
| 429 на всём сайте | проверить, не стоит ли лимит на весь сервер, и не атакуют ли сайт |
Не отключайте лимит целиком. Если снять защиту, всплеск вернётся и уложит сайт уже с 502 или 504.
Как настроить лимит правильно
Пример для nginx: ограничение на поиск и API, код ответа 429 вместо 503.
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_req_status 429;
}
}
burst разрешает короткий всплеск, nodelay обрабатывает его сразу, а не ставит в очередь. Точные значения зависят от нагрузки: ставьте их по логам, а не по совету из статьи.
Хорошая практика — отдавать заголовок Retry-After вместе с 429. Тогда клиент и краулер понимают, когда возвращаться.
Влияет ли 429 на SEO
Сам по себе код не скрывает страницу из индекса. Проблема начинается, когда 429 отдают все URL подряд: робот не получает HTML и не может обновить страницы.
Если лимит стоит только на API, формах поиска или в админке, на индексацию это не влияет. Если 429 появляется на обычных страницах, проверьте, не ограничен ли весь трафик и не попадает ли Googlebot под общий лимит.
Где помогает нейросеть
| Задача | Что делает модель | Что проверять руками |
|---|---|---|
| Разбор логов | группирует строки по зонам и IP | названия зон и пороги в конфиге |
| Настройка nginx | предлагает блок limit_req | синтаксис через nginx -t |
| Письмо хостингу | формулирует вопрос по лимитам | цифры и факты из логов |
| Объяснение клиенту | переводит техническую причину на язык бизнеса | что именно уже исправлено |
Частые ошибки
- Путать 429 с 503 и чинить не тот участок.
- Снимать лимит вместо поиска источника всплеска.
- Ставить
rateнаугад, без логов. - Игнорировать
Retry-Afterи повторять запрос без паузы. - Ограничивать весь сайт из-за одной формы.
- Забывать, что за CDN у сайта другой IP и другие правила.
Вопросы
429 — ошибка клиента или сервера?
Формально это 4xx: сервер считает, что проблема в частоте запросов клиента. Но решать её часто приходится владельцу сайта: настроить лимит, кэш или защиту.
Это опасно для сайта?
Нет, если код стоит на API или формах. Опасно, когда 429 отдают все страницы: посетители и роботы не получают контент.
Что делать посетителю?
Подождать время из Retry-After и обновить страницу. Если ошибка повторяется, написать владельцу сайта: возможно, лимит настроен слишком жёстко.
Может ли нейросеть найти причину 429?
Она помогает разобрать лог и конфиг, но не видит трафик в реальном времени. Источник всплеска всё равно ищут в логах и на стороне CDN.
Связанные материалы
Источники
Официальные документы 6
- RFC 6585: 429 Too Many Requestsrfc-editor.org
- MDN: 429 Too Many Requestsdeveloper.mozilla.org
- nginx: ngx_http_limit_req_modulenginx.org
- Cloudflare: Rate limiting rulesdevelopers.cloudflare.com
- Google Search Central: HTTP status codesdevelopers.google.com
- Яндекс Вебмастер: коды HTTPyandex.ru