Источник ответа
Определяем, кто вернул 429: CDN, WAF, веб-сервер, приложение, API-шлюз или внешний сервис.
Too Many Requests
Диагностика и исправление ошибки 429 на сайте
Определяем, кто и где превышает лимит запросов: браузер, бот, cron-задача, мобильное приложение, интеграция или общий трафик. Исправляем причину и сохраняем защиту от перегрузки.
Ограничение частоты
Кто создаёт
лишние запросы
RFC 6585 связывает 429 с превышением числа запросов за определённое время. Правило может считать их по ресурсу, IP, учётной записи, cookie или токену. Поэтому сначала устанавливаем точку ограничения и идентификатор клиента.
Правило лимита
Проверяем окно времени, порог, burst, ключ учёта и различия для авторизованных, анонимных и служебных запросов.
Клиент и интеграция
Ищем цикл, повтор при каждой перерисовке, параллельные cron-задачи, отсутствие кэша и агрессивные повторные попытки.
Реальный трафик
Разделяем обычных посетителей, поисковых роботов, мониторинг, сканирование и подозрительный поток по журналам.
Ответ 429
Проверяем понятное сообщение и Retry-After, если система действительно знает допустимый момент повторной попытки.
Повторные запросы
Настраиваем очередь, кэш и увеличение паузы между повторами, затем проверяем сценарий в безопасных пределах.
Проверка источника нагрузки
Разбираем сценарии, в которых возникает 429
Уточните, ограничивается ли весь сайт или отдельное действие. Сохраните время ответа и заголовки, скрыв секреты. Сопоставляем запрос с правилом защиты и проверяем, какие обращения система объединяет в один счётчик.
Общий адрес сети
Несколько сотрудников могут выходить через один внешний IP. Проверяем, суммирует ли правило их запросы. Если обычная работа команды вызывает блокировку, обсуждаем подходящий ключ учёта и границы доступа, сохраняя защиту анонимного трафика.
Фоновый опрос
Проверяем запросы при открытой вкладке, возврате фокуса и нескольких окнах. Таймер или повторный обработчик может отправлять обращения без действия посетителя. Записываем число запросов до и после исправления и проверяем обновление данных в интерфейсе.
Обмен с сервисом
Сверяем несколько интеграций, использующих один аккаунт или ключ. У каждой может быть допустимая частота, но общий поток превышает квоту. Согласуем очередь и приоритет важных операций, вместо независимых повторов из каждого процесса.
Пауза после отказа
Проверяем поведение клиента после 429: прекращает ли он немедленные повторы и учитывает ли указанный срок ожидания. Ограничиваем число попыток и сохраняем операцию для проверки. Перед повтором записи выясняем, не создалась ли она ранее.
Контроль исправления
Принимаем настройку лимита по двум сценариям
Для ошибок внешнего обмена смотрите API-интеграции. Наблюдение за повторными отказами рассматриваем в разделе мониторинга сайта.
Как проверить полезный трафик?
Повторяем согласованное действие обычного пользователя и работу служебного клиента. Проверяем правильный результат и частоту обращений в журнале. Отдельно тестируем несколько сотрудников, если они используют общий адрес сети.
Как подтвердить сохранение защиты?
В тестовой среде или в согласованном безопасном диапазоне проверяем превышение порога и восстановление после паузы. Нагрузку ограничиваем заранее. Проверка не должна нарушать правила внешнего API или мешать посетителям рабочего сайта.
Что передаём после исправления?
Источник ответа, изменённое правило, ключ учёта и контрольные действия. Фиксируем исключения и владельца настройки. При ограничении провайдера описываем доступную частоту и поведение очереди, не обещая изменить чужую квоту.
Результат
Лимит защищает, а не мешает
Понятен источник
Известно, какой клиент и какое правило создавали 429.
Снижен лишний поток
Повторы, циклы и дубли не нагружают сервис без необходимости.
Сохранена защита
Полезный трафик проходит, а опасные всплески ограничиваются.
Порядок действий
Исправляем причину, не выключая защиту
Повышать лимит до измерений рискованно: это может перенести перегрузку на приложение или базу. Сначала выясняем источник и только затем меняем клиент или правило.
Воспроизводим
Фиксируем URL, пользователя, IP, токен, время и число обращений до ошибки.
Читаем журналы
Находим правило, счётчик и общий объём запросов в том же временном окне.
Убираем лишнее
Исправляем цикл, объединяем запросы, добавляем кэш, очередь или корректную паузу.
Настраиваем границы
Корректируем подтверждённое правило и проверяем полезный и защитный сценарии.
Ограничение
Отключить rate limiting — плохой первый шаг
Без ограничения один неисправный клиент или бот способен занять все ресурсы. Безопаснее устранить дубли, разделить классы трафика и выбрать измеряемый предел.
Для диагностики подготовьте
- URL или API-метод с ошибкой;
- время, IP или аккаунт пользователя;
- тело ответа и заголовки, включая Retry-After;
- недавно запущенные боты, cron и интеграции;
- доступ к журналам CDN, сервера и приложения.
Лимиты внешнего сервиса нельзя изменить со стороны сайта: в таком случае адаптируем очередь и частоту обращений к его правилам.
Вопросы
Перед исправлением
Что означает 429 Too Many Requests?
Клиент отправил слишком много запросов за заданный промежуток времени и попал под ограничение частоты.
Нужно отключить ограничение?
Обычно нет. Сначала определяем источник всплеска и корректность правила, затем исправляем клиент или границы лимита.
Что означает Retry-After?
Заголовок может сообщать, сколько ждать до повторной попытки. Клиенту также нужна пауза между следующими повторами.
Чем 429 отличается от 403?
429 связан с частотой запросов, а 403 — с отказом в доступе. Диагностируются эти коды по разным правилам.
Первый шаг
Покажите ошибку 429
Пришлите URL, время, заголовки ответа и сценарий перед блокировкой. Определим точку ограничения и безопасный следующий шаг.