Артём Савельев 
Ошибка 429 Too Many Requests: что означает и как исправить
429 — «слишком много запросов»: вы (или кто-то с вашего адреса) стучитесь чаще, чем сервер готов терпеть. Это не поломка, а работа ограничителя — rate limit. Интересна эта ошибка в первую очередь владельцам сайтов: неправильно настроенный лимит банит не парсеров, а живых покупателей, поисковых роботов и собственный мониторинг. Разбираем обе стороны и правила настройки лимитов без самострела.
Как работает rate limit
Ограничитель считает запросы по какому-то признаку — обычно по IP-адресу, иногда по токену или аккаунту — и, когда частота превышает порог (скажем, 10 запросов в секунду), начинает отвечать 429 вместо содержимого. Хорошо воспитанный сервер добавляет заголовок Retry-After: через сколько секунд можно возвращаться. Лимиты стоят почти везде: у API (у каждого сервиса свои квоты), у защит от перебора паролей, у анти-бот систем и CDN. Так что встреча с 429 — вопрос времени для любого, кто автоматизирует работу с вебом.
Если вы посетитель или разработчик клиента
Живой человек ловит 429 в двух случаях. Первый — общий адрес: вы в офисной сети, за CGNAT мобильного оператора или за VPN, и лимит исчерпали «соседи» по IP; лечится сменой сети или ожиданием. Второй — вы действительно частите: обновляете страницу как дятел, открыли двадцать вкладок одного сайта, запустили расширение-качалку. Подождите время из Retry-After (или пару минут, если заголовка нет) — и всё вернётся.
Разработчику клиента API правило одно, зато железное: уважать 429. Экспоненциальная пауза между повторами (1 → 2 → 4 → 8 секунд), чтение Retry-After, кэширование ответов, батчи вместо очередей одиночных запросов. Клиент, который в ответ на 429 просто ретраит без паузы, устраивает сам себе DDoS и рано или поздно переезжает из «лимитированных» в «забаненные».
Если вы владелец: лимит, который бьёт по своим
Rate limit — необходимая защита: без него боты и парсеры выедают ресурсы, а перебор паролей идёт со скоростью канала. Но у неправильного лимита есть три любимые жертвы, и все три — ваши:
| Жертва | Почему попадает под лимит | Последствие |
|---|---|---|
| Посетители за общим IP | Офисы, кампусы, CGNAT операторов: сотни людей = один адрес | 429 у реальных покупателей в час пик |
| Поисковые роботы | Обходят сайт пачками запросов по расписанию | Замедление индексации; при систематических 429 — деградация в поиске |
| Собственный мониторинг и вебхуки | Регулярные автоматические запросы с постоянных адресов | Ложные тревоги; потерянные уведомления платёжных систем |
Рецепт без самострела: лимиты — по путям, а не «одним куском» (форма логина — жёстко, каталог — мягко, статика — вообще без лимита); всплеск (burst) — разрешён, чтобы нормальная страница с десятком ресурсов не считалась атакой; белые списки — для официальных диапазонов поисковиков и адресов своего мониторинга; и обязательно Retry-After в ответе, чтобы корректные клиенты знали, когда вернуться. И главное — смотрите в логи: кто реально ловит ваши 429. Если там пользовательские User-Agent из России — лимит настроен против собственных клиентов.
Как это выглядит в конфиге nginx — минимальный лимит на форму логина, не задевающий остальной сайт:
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location = /login {
limit_req zone=login burst=3;
limit_req_status 429; # по умолчанию nginx отдаёт 503 — явно ставим честный код
...
}
Обратите внимание на последнюю директиву: nginx исторически отвечает на превышение лимита кодом 503, что путает диагностику — перегрузка и лимит выглядят одинаково. Явный 429 разводит эти ситуации и в логах, и для клиентов. Параметр burst разрешает короткий всплеск (человек трижды ошибся паролем подряд — это не атака), а rate=5r/m держит перебор паролей на скорости, при которой он бессмыслен.
Поисковый робот, регулярно получающий 429, ведёт себя вежливо: снижает частоту обхода. Звучит безобидно, но на практике это значит, что новые страницы попадают в индекс неделями, а обновления цен и наличия поисковик видит с большим опозданием. Сайт «работает», позиции ползут вниз — и связать одно с другим без анализа логов почти невозможно.
429 от внешних API: планируйте квоты
Вторая жизнь этой ошибки — в интеграциях: ваш сайт сам ходит в чужие API (платёжки, карты, доставки, маркетплейсы), и у каждого — квоты. Пока запросов мало, о лимитах никто не думает; потом каталог вырастает, синхронизация начинает упираться в квоту, и обновление остатков молча останавливается на середине. Правила выживания: знать квоты каждого API, на который завязан бизнес; закладывать паузы и батчи в синхронизации заранее, а не после первого инцидента; и мониторить результат синхронизаций, а не только их запуск — «запустилась и умерла на 429» внешне неотличима от «отработала».
Пруфен проверяет сайт с разумной частотой — интервал вы выбираете сами, от 2 минут — и с постоянных адресов, опубликованных на странице серверов мониторинга: внесите их в белый список, и лимиты не будут воевать с проверками. А если сайт начал отдавать 429 реальным посетителям, HTTP-проверки из 13 точек это заметят — особенно характерна картина «зелёное ночью, красное в часы пик».
Частые вопросы
Сколько ждать при 429? Сколько сказано в заголовке Retry-After; если его нет — начните с пары минут. Агрессивные повторы без пауз только продлевают бан.
Почему я получаю 429, хотя почти не пользуюсь сайтом? Лимит считается по адресу, а не по человеку: за общим IP (офис, мобильный оператор, VPN) квоту исчерпывают соседи. Смените сеть — и лимит «обнулится».
Чем 429 отличается от 503 при перегрузке? 429 — персональный отказ конкретному источнику за частоту («вы частите»), 503 — общий отказ из-за нехватки ресурсов («мне плохо»). Первый — работа защиты, второй — симптом перегрузки.
Нужен ли rate limit небольшому сайту? Минимальный — да, хотя бы на форму входа и поиск: перебор паролей и тупые парсеры приходят на сайты любого размера. Просто настройте его по путям и с белыми списками, а не «10 запросов в минуту на всё».