HTTP 429: клиент превысил лимит запросов
Сервер или промежуточный слой применил rate limiting. Нужно определить ключ ограничения, окно, затронутых клиентов и корректный момент повторного запроса.
Мониторинг покажет, когда состояние изменится
Добавьте сайт или сервер один раз — perfMon будет проверять его автоматически, сохранит историю и сообщит о сбое и восстановлении.
С чего начать поиск
клиент отправляет запросы в цикле без backoff
лимит настроен слишком жёстко для нормального burst
все пользователи видны под одним proxy IP
повторные попытки нескольких слоёв усиливают нагрузку
Проверка по шагам
Прочитайте Retry-After
Значение может быть числом секунд или HTTP-датой и задаёт минимальную паузу перед повтором.
Определите ключ лимита
Проверьте, считается ли IP, user ID, API token, route или общий ресурс.
Найдите источник burst
Сопоставьте access log, request id, cron, retry и параллельность клиента.
Проверьте proxy headers
Неверный real IP может объединить разных пользователей в один лимит.
Что делать после подтверждения
- добавить exponential backoff с jitter и соблюдать Retry-After
- разделить лимиты по маршрутам и типам клиентов
- исправить real IP/trusted proxy без безусловного доверия заголовкам
- добавить метрики rejected requests и уведомление по устойчивому росту
Продолжить диагностику
Частые вопросы
429 означает падение сервера?
Не обязательно. Сервер может быть исправен и сознательно ограничивать частоту запросов, но массовый 429 остаётся пользовательским инцидентом.
Нужно ли сразу увеличить лимит?
Сначала найдите источник запросов и ключ ограничения. Увеличение может скрыть цикл клиента или перенести перегрузку на backend.
Как клиенту повторять запрос?
Соблюдать Retry-After, использовать exponential backoff с jitter и ограничивать общее число попыток.
Не ждите повторения ошибки
Добавьте сайт или сервер в perfMon, чтобы сохранить историю, увидеть восстановление и получить уведомление при следующем инциденте.