Перейти к содержимому
Надёжность

Код 429 и бережная автоматизация: паузы, лимиты и повтор

Ответ 429 сообщает, что запросов стало слишком много за выбранный сервисом период. Правильная реакция — снизить темп, а не менять IP и продолжать прежнюю нагрузку.

2 мин чтенияПроверено и обновлено: 6 августа 2026 г.

Главное за минуту

  • Учитывайте Retry-After, если сервер его возвращает.
  • Лимитируйте действия по пользователю и бизнес-функции, а не только по IP.
  • Общий бюджет операции важнее количества доступных IP.
  • Retry хранит deadline и завершается явным результатом.

Что означает 429

Стандарт не диктует серверу единственный способ подсчёта: лимит может относиться к учётной записи, ресурсу, cookie или группе серверов.

До автоматизации запросите у владельца API опубликованные квоты либо согласуйте внутренний бюджет. Разделите лимиты по учётной записи, endpoint и операции. Для отчёта собирайте число запросов, долю 429 и время до восстановления, но не пытайтесь экспериментально искать максимальный предел на production без отдельного разрешения.

Алгоритм паузы

Используйте указанную сервером паузу либо ограниченный экспоненциальный backoff с небольшим случайным разбросом. Установите максимальное число попыток.

Алгоритм повтора хранит attempt, nextAttemptAt и окончательный deadline. Если Retry-After задан датой, учитывайте синхронизацию часов; если секундами — применяйте значение как нижнюю границу. Добавляйте jitter, чтобы множество workers не проснулось одновременно. После максимального числа попыток переводите задачу в явную ошибку, а не бесконечное ожидание.

Почему ротация не решает проблему

Смена адреса ради обхода ограничения нарушает смысл защитного механизма и может противоречить правилам сервиса. Нагрузка при этом никуда не исчезает.

Не распределяйте один и тот же запрещённый поток по большему числу IP. Для легитимного параллелизма ограничивайте глобальную интенсивность по бизнес-операции, даже если каждый модем имеет отдельный адрес. При аварийном росте 429 включайте circuit breaker и сохраняйте разрешённые контрольные health-запросы с очень низкой частотой.

Наблюдаемость

Собирайте долю 429, затронутые операции, время восстановления и идентификатор разрешённого сценария без записи секретов.

Панель должна показывать текущий бюджет, использованную долю, следующий разрешённый повтор и источник ограничения. Разделяйте клиентскую ошибку конфигурации и настоящий server-side limit. Уведомление создавайте после устойчивого превышения порога, например нескольких окон подряд, чтобы единичный 429 не будил дежурного без необходимости.

Практический чек-лист

  1. 1Поддержите Retry-After.
  2. 2Ограничьте число повторов.
  3. 3Согласуйте допустимую интенсивность с владельцем сервиса.
  4. 4Добавьте jitter и максимальный deadline.
  5. 5Настройте circuit breaker на устойчивый рост 429.

Источники и документы

Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.

  1. 1.RFC Editor / IETF: RFC 6585: Additional HTTP Status Codes
  2. 2.RFC Editor / IETF: RFC 9110: HTTP Semantics
  3. 3.OWASP Foundation: REST Security Cheat Sheet

Продолжить чтение

Материалы по близкой теме

Пошаговая диагностика

Прокси не подключается: найдите ошибку по этапу соединения

Читать

DNS и SOCKS5

DNS через SOCKS5: где разрешается доменное имя

Читать

Эксплуатация

DNS-кеш и TTL: почему новый адрес появляется не сразу

Читать