Лимиты скрейпинга: 429, Retry-After и параллелизм

Лимит частоты скрейпинга: решение сервера, а не настройка мощности браузера. Ответ HTTP 429 сообщает об избытке запросов за некоторый период; он не определяет ключ подсчёта и не разрешает смену маршрута. BotBrowser документирует прокси на уровне браузера и отдельных контекстов, но он не меняет квоту сервиса и не гарантирует доступ. Диагностика начинается с ответа, разрешённой нагрузки и журнала отправок, после чего отдельно рассматриваются частота, незавершённые операции и повторные запросы.

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

Кратко

• До изменения настроек сохраните HTTP 429, время получения и значение Retry-After, если оно есть.
• Считайте ключ подсчёта неизвестным, пока его не установят документация сервиса или записи собственного сервера.
• Параллелизм считает незавершённую работу, частота: отправки за интервал. Одна навигация может вызвать несколько запросов.
• На собственном стенде прекратите увеличение нагрузки при первом 429. Не исследуйте рабочий предел стороннего сервиса пробными нагрузками.
• Соблюдайте и временную границу, и бюджет повторов. Отложенный запрос может истечь без повторной отправки.

Содержание

• Что устанавливает ответ 429
• Область подсчёта по серверным данным
• Отдельные измерения частоты и параллелизма
• Две формы Retry-After
• Общая очередь и конечный бюджет
• Запись инцидента с причиной остановки
• Настройки BotBrowser и политика сервера
• Практический вывод

Что устанавливает ответ 429

RFC 6585, раздел 4 определяет 429 как ответ об ограничении частоты. Он может включать Retry-After; отсутствие заголовка не разрешает неограниченный трафик. Тело может объяснять ситуацию, но один статус не устанавливает блокировку аккаунта, оценку репутации IP или обнаружение отпечатка браузера. Отделяйте наблюдаемый статус от возможных объяснений, пока для одного из них не появятся доказательства. Для сбоев до любого ответа 429 послойная диагностика блокировки скрапера разделяет данные DNS, TLS, HTTP и страницы.

Установите, какой запрос получил ответ. Основной документ, endpoint данных того же источника и ресурс: разные записи запросов. Успешная навигация не доказывает успех загрузки данных; приложение может показывать устаревшую оболочку после ограничения API. Свяжите ответ с отсутствующим полем или записью вместо классификации всей страницы по внешнему виду. В требованиях к SERP-нагрузке завершённая навигация отделена от принятых данных; это различие полезно и здесь.

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

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

Область подсчёта по серверным данным

RFC 6585 намеренно оставляет серверу идентификацию пользователя и подсчёт запросов. Ограничение может охватывать ресурс, более широкий сервис или авторизованный аккаунт. Поэтому один 429 не отличает правило по IP от правила по аккаунту или сессии. Справочник MDN по 429 описывает статус, а не конкретную политику ответившего сервера.

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

Для сторонней интеграции используйте опубликованные квоты или согласованный ответ поддержки. Если область не определена ни там, ни там, запишите scope=unknown. Смена IP, cookie или аккаунта до изменения ответа меняет несколько входных условий и не устанавливает исходное правило. Она также может нарушать политику сервиса. Неизвестная область: допустимый результат; догадка об идентичности не улучшает диагностику.

Разделяйте намерение настройки и наблюдение. Развёртывание может изолировать задания по контекстам браузера, а сервер: учитывать всё в общей квоте аккаунта. Маршрут прокси может отличаться при общей сессии приложения. Записывайте это как разные факты. Границы хранилищ браузера и сетевые пути сами по себе не подтверждают разделение серверных квот или модель разрешений.

Отдельные измерения частоты и параллелизма

Частота: число отправок за интервал, например запросов в секунду. Параллелизм: число ещё не завершённых операций. Ни то ни другое не равно числу вкладок. Считайте на уровне, к которому относится политика: задания, навигации и HTTP-запросы могут иметь разные итоги. Помимо документа страница может запрашивать скрипты, изображения и данные; задания в минуту не дают полного журнала HTTP-частоты.

В иллюстративном расчёте 2 отправки в секунду при средней длительности 3 секунды могут поддерживать около 6 незавершённых запросов при стационарной нагрузке. Это планировочное приближение, а не результат измерения браузера или рекомендованная квота. Всплески, переменные длительности и производные запросы могут нарушать модель. На собственном стенде сохраняйте реальные времена отправок и число операций, а не выводите их из заданного количества работников.

inflight ≈ dispatches_per_second * mean_request_seconds

Раздельно задавайте частоту отправок и потолок одновременных операций. Параллелизм 4 не определяет частоту: быстрое завершение допускает много отправок за короткий интервал. И наоборот, даже редкие отправки накапливают работу при замедлении ответов. Сохраняйте возраст очереди, длительности ответов, активную работу, отправленные повторы и принятые записи, чтобы отличать рост очереди от полезной производительности.

Ограниченная лестница нагрузки на собственном стенде

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

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

Две формы Retry-After

HTTP Semantics, раздел 10.2.3 определяет Retry-After как HTTP-дату либо неотрицательное целое число секунд. Справочник MDN по Retry-After иллюстрирует обе формы. Разбирайте заголовок до планирования и храните исходный текст вместе с интерпретацией. Это предотвращает путаницу секунд с миллисекундами и даты с длительностью.

Для Retry-After: 120 предлагаемая граница: через 120 секунд после получения именно этого ответа. При времени получения 12:00:00 GMT арифметическая граница равна 12:02:00 GMT. Это иллюстративные входные данные, не перехваченный обмен. Отсчитывайте от получения ответа, не от создания задания, запуска браузера или запоздалого чтения работником. Отставший потребитель журналов не должен незаметно запускать уже истёкший интервал заново.

Retry-After: Mon, 09 Nov 2026 12:02:00 GMT указывает дату, не длительность. При сравнении с местным временем важна точность часов. Сохраняйте время получения и серверный Date, если он присутствует, как диагностические входные данные; наличие Date само по себе не доказывает точность часов. Прошлая дата не создаёт будущего ожидания, но и не разрешает немедленный цикл повторов.

Используйте одну единицу времени во всём расчёте. Следующие поля предложены для записи инцидента, а не являются API браузера или обязательным алгоритмом обработки. headerNotBefore: разобранная граница; policyNotBefore: более строгая задержка документированной политики. Срок задания определяет, полезно ли ещё ждать:

eligibleAt = max(headerNotBefore, policyNotBefore)
if eligibleAt > jobDeadline: stop

Если заголовок отсутствует, некорректен или выходит за поддерживаемый числовой либо календарный диапазон, сохраняйте это состояние вместо неявного превращения в ноль. Примените установленную политику, если она есть; иначе остановитесь для решения. Retry-After: 0 отличается от отсутствующего или ошибочного значения, но ни один случай не оправдывает бесконечные немедленные попытки. Консервативный разбор также должен сообщать о неподдерживаемой форме, а не принимать любую похожую на дату строку через слишком свободный парсер.

Общая очередь и конечный бюджет

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

Храните минимум три независимых бюджета: срок задания, максимум попыток и остаток разрешённой работы. Запрос может стать допустимым по времени, но оставаться недопустимым из-за срока или исчерпания попыток. Тогда очередь должна выдать конечный результат, а не вернуть запрос в начало. Держите attemptsUsed, eligibleAt и jobDeadline в одной предлагаемой записи для проверки решения.

Нарастающая задержка и случайный сдвиг: разные регуляторы. Документированная политика может увеличивать задержку после повторных неудач; неотрицательный сдвиг распределяет разрешённые возобновления на более позднее время. Ни один не должен сокращать корректное ожидание сервера. Не урезайте 120 секунд до 10 из-за короткого тайм-аута работника: завершите или отложите задание вне него. Бюджет: причина отказаться от повтора, а не повторить раньше.

Безопасность повтора зависит и от операции. Чтение данных и отправка покупки имеют разные последствия при повторении. Сам по себе HTTP 429 не определяет, изменила ли предыдущая бизнес-операция состояние. Исключайте изменяющие операции из общей очереди скрейпинга и следуйте документированной защите от дубликатов. Не вкладывайте повторы библиотеки в повторы планировщика без общего бюджета: одно видимое задание может породить несколько неучтённых запросов.

Запись инцидента с причиной остановки

Запись должна связывать HTTP-ответ с решением планировщика. Используйте непрозрачный ID запуска, ревизию стенда или интеграции, версии браузера и пакета и обезличенную ссылку на маршрут. Сохраните время, статус, роль запроса, исходный Retry-After, состояние разбора, частоту, параллелизм и возраст очереди. Это предлагаемые поля ограниченного диагностического журнала, не обещание их автоматической доступности в любом браузере.

Наблюдение	Сохранённое значение	Поддерживаемое решение
Ответ	Статус, ID и время получения	Конкретный запрос получил 429
Заголовок	Исходное значение и разбор	Ожидание известно или нет
Область	Правило или unknown	Какая очередь остановлена и почему
Нагрузка	Отправки, работа и повторы	Частота не равна числу работников
Бюджет	Попытки, срок и eligibleAt	Ждать, истечь или остановиться
Результат	Принятая запись или причина завершения	Навигация не равна принятым данным

Отделяйте наблюдение от политики. pauseReason=429 фиксирует событие; resumePolicy=documented-window: выбранное правило. «Вероятно, IP заблокирован» относится, если вообще сохраняется, к неподтверждённым гипотезам, а не серверным фактам. Такое разделение позволяет пересмотреть диагноз, не переписывая действительное содержимое ответа.

Ведите журнал запросов для ограниченного окна наблюдения. Включайте неудачные попытки в число отправок даже без принятых записей. Раздельно учитывайте отмену до отправки и после начала запроса. На страницах с несколькими ресурсами сохраняйте роль запроса, чтобы изменение загрузки изображений не принять за изменение извлечения данных. Ограничьте сохраняемое содержимое ответов необходимым, удаляйте секреты из записей и соблюдайте политику хранения.

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

Настройки BotBrowser и политика сервера

Документация прокси BotBrowser описывает --proxy-server и поддерживаемую маршрутизацию. Документация динамического прокси описывает изменение прокси BrowserContext через CDP-сессию уровня браузера. Это возможности настройки. Ни один документ не устанавливает ключ подсчёта, окно сброса или разрешённую частоту внешнего сервиса.

Сохраняйте объявленный маршрут стабильным при диагностике, чтобы посторонние изменения не скрывали последовательность ответов. Записывайте обезличенные ссылки на контекст и маршрут, если интеграции нужно их различать. BotBrowser не гарантирует отдельную квоту для другого контекста, исчезновение 429 после смены маршрута или получение разрешения после настройки браузера. Серверное ограничение продолжает действовать для нагрузки.

Вопросы и ответы

Меньше работников всегда означает меньше запросов?

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

Каждый 429 содержит Retry-After?

Нет. RFC 6585 делает заголовок необязательным. Зафиксируйте отсутствие указаний, затем примените установленную политику интеграции или решение об остановке.

Смена прокси доказывает ограничение по IP?

Нет. Другой результат не определяет исходное правило. Используйте документацию сервиса или решения собственного сервера; не меняйте маршрут ради обхода квоты.

Прошедшее время повтора гарантирует успех?

Нет. Это временная граница, не резерв мощности и не обещание доступа. Разрешение, безопасность операции и оставшийся бюджет по-прежнему обязательны.

Источники

• RFC 6585, раздел 4: 429 Too Many Requests
• RFC 9110, раздел 10.2.3: Retry-After
• MDN: 429 Too Many Requests
• MDN: Retry-After
• BotBrowser: настройка прокси
• BotBrowser: динамический прокси
• Требования браузера для SERP-скрейпинга
• Критерии выбора браузера

Практический вывод

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