HTTP 429 при аудите сайта: лимит или недоступность

Обход проверил несколько страниц и начал получать HTTP 429. В браузере главная открывается. Это ещё не означает, что аудитор сломан или сайт полностью недоступен. Сервер мог ограничить частоту запросов определённого клиента, WAF мог применить правило, а приложение — исчерпать ресурс для конкретной операции. Проверка должна установить границы ограничения, сохраняя безопасную нагрузку.

Сначала остановите массовые повторные запросы. Сохраните один проблемный ответ и согласуйте дальнейшее обследование с владельцем сайта. Повторять обход быстрее ради «достоверной статистики» при ответе 429 — плохой способ понять происходящее: вы меняете условия, которые пытаетесь исследовать.

Прочитайте ответ и зафиксируйте границы вывода

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

Запишите URL, метод, время, исходящий IP проверяющего, доступный идентификатор запроса, статус и заголовки. Сохраните короткий фрагмент тела ответа: он иногда содержит имя защитного слоя или пояснение. Исключите cookies, ключи и другие чувствительные значения из общего отчёта. Для дальнейшей диагностики их наличие можно отметить без раскрытия.

Формулируйте наблюдение буквально: «Запрос аудитора к этому адресу получил 429 в указанное время». Вывод «сайт лежал десять минут» требует иных данных. Значение самого статуса и соседних кодов сверяйте с руководством по HTTP-ответам.

Найдите слой, который применил ограничение

Владелец сайта сопоставляет время и идентификатор запроса с журналами CDN, WAF, веб-сервера и приложения. Если запись есть на защитном слое, но отсутствует в приложении, запрос мог быть остановлен раньше. Если приложение записало отказ, исследуйте его правила и ресурсы. Отсутствие записи само по себе не доказывает конкретный источник ошибки: журналирование может быть неполным.

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

Изменяйте правила только после согласования. Общее отключение WAF снимает защиту с иных запросов. Для авторизованного аудита обсуждают ограниченное исключение, понятный источник и срок действия. Обход ограничений сменой адресов мешает диагностике и нарушает согласованный режим проверки.

Сравните малую контрольную выборку

Выберите главную, один проблемный URL и одну страницу такого же типа. Выполните согласованные одиночные проверки после паузы. Сравнивайте метод и вид запроса: браузер с сессией, обычный HTTP-клиент и массовый обход могут попадать под разные правила. Результат одного клиента не описывает все остальные.

Укажите размер выборки. Не превращайте три успешно открытые страницы в вывод о полном восстановлении каталога. Отдельно сохраните адреса, которые ещё не удалось повторно проверить.

Уважайте Retry-After и ограничьте повторы

В ответе может быть Retry-After. MDN описывает два варианта значения: число секунд задержки или HTTP-дата. Это ориентир для следующего запроса, который нужно прочитать до повторной проверки.

Условный ответ ниже предлагает выдержать две минуты. Значение приведено для примера; фактический интервал задаёт проверяемый сервер.

HTTP/1.1 429 Too Many Requests
Retry-After: 120

После указанной паузы начните с одного URL. Заранее задайте предел повторных попыток и остановку при новом ограничении. Когда заголовка нет, согласуйте интервал с владельцем инфраструктуры, уменьшите параллелизм и избегайте непрерывного цикла. Отсутствие подсказки не означает разрешение отправлять запросы без задержки.

Сохраняйте первоначальный статус в отчёте. Успешный ответ после повтора подтверждает результат повтора, но не делает первый отказ несуществовавшим. Это особенно полезно, когда коллеги сравнивают отчёт аудитора с журналом доступности.

Отделите ограниченный аудит от доступности бизнеса

Сверьте историю мониторинга, обращения посетителей и серверные события за тот же промежуток. Для магазина отдельно проверяют каталог, корзину и разрешённые операции оформления; для сервиса — публичные страницы и важные API. Доступная главная не подтверждает работу остальных сценариев.

Если тревога возникла только у проверяющего, разберите её по протоколу проверки недоступности сайта. Зафиксируйте, откуда выполнялась проверка и какие ответы получили независимые разрешённые точки. Не увеличивайте нагрузку ради количества подтверждений.

Три возможных результата требуют разных задач: лимит проверяющего, слишком жёсткое правило для посетителей или перегрузка инфраструктуры. Они могут сочетаться. Например, одно правило ограничивает аудит, а отдельный маршрут действительно испытывает сбой. Поэтому журнал лучше хранить по URL и клиенту, сохраняя несколько состояний.

Проверьте влияние на поисковый обход отдельно

Ответ аудитору не подтверждает, что такой же ответ получает Googlebot. Для поискового обхода сверяйте доступные данные Search Console и серверные журналы. Показанное имя клиента нельзя автоматически считать проверенной принадлежностью поисковому роботу. Владельцу инфраструктуры нужна корректная проверка источника запроса.

Документация Google о HTTP-статусах указывает, что 429 и серверные ошибки уменьшают частоту обхода; длительно недоступные URL могут перестать использоваться. Поэтому устойчивый 429 для настоящих поисковых запросов требует исследования, даже если для аудитора ограничение было намеренным.

Не ставьте исключение только по строке User-Agent. Согласуйте проверку происхождения трафика и нужный режим доступа с ответственным за защиту. Срок и область изменения фиксируют в задаче. После настройки ищут реальные новые запросы и ответы, сохраняя техническую проверку отдельно от изменения поисковых показателей.

Передайте конкретную задачу владельцу инфраструктуры

Задание должно содержать временной интервал, URL, ответ, параметры разрешённой проверки и найденный слой ограничения. Добавьте ожидаемый результат: например, согласованный медленный обход проходит выбранные страницы, тогда как защита остальных маршрутов остаётся включённой. Приложите критерий остановки при росте ошибок.

Для исследования отдельного адреса можно начать с технического анализа страницы. Если доступ ограничен, результат следует дополнить журналами владельца сервера. Внешняя проверка видит ответ на свой запрос и не раскрывает автоматически конфигурацию WAF, занятость базы данных или причины отказа приложения.

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

Закройте проверку по подтверждённому восстановлению

Приёмка включает четыре результата: источник 429 установлен или обозначен как неизвестный; режим повторов согласован; выбранные URL успешно отвечают после паузы; остаточные ограничения перечислены. Если массовый обход ещё не завершён, отчёт должен говорить о восстановлении проверенных запросов.

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

Полезный итог: «429 возникал у аудитора из-за подтверждённого порога. Параллелизм уменьшен; контрольные страницы проверены; оставшийся обход согласован». Если происхождение ограничения не найдено, закрывайте только завершённые действия и оставляйте исследование причины отдельной задачей.