429 too many requests: решения для скрейпинга и AI API

Представьте скрейпер, который собирает публичные страницы товаров через прокси CyberYozh App, а затем отправляет извлечённый текст в AI API для анализа. На полпути работа останавливается с ошибкой «429 too many requests». Первое желание — повторить попытку, но сначала нужно выяснить, где именно произошёл сбой запроса.

Вернул ошибку сайт, промежуточный сервис или AI API? Каждый из них может применять разные лимиты, поэтому изменение не того параметра может оставить проблему нерешённой.

Во время сбора данных проверьте частоту запросов, количество одновременных подключений и то, применяется ли лимит к IP-адресу или к сессии. CyberYozh App позволяет управлять сменой IP прокси и поведением сессий на этом этапе. Во время обработки AI проверяйте вместо этого лимиты запросов и токенов провайдера. Этот гайд проведёт вас через оба этапа, чтобы вы могли определить ограничение, применить правильное решение и избежать повторения уже выполненной работы.

Коротко

• 429 too many requests означает, что сервис применяет лимит частоты или использования. Это не означает автоматически, что ваш прокси неисправен или навсегда заблокирован.

• Сначала найдите источник: целевой сайт, промежуточный сервис или AI API. Проверьте тело ответа и заголовки.

• Замедлитесь и повторяйте попытки осторожно. Соблюдайте Retry-After, координируйте воркеры, снижайте количество одновременных запросов и используйте backoff с джиттером и максимальным количеством попыток.

• Сохраняйте выполненную работу. Повторяйте неудачный этап сбора или анализа без перезапуска всего процесса.

• Проверяйте лимиты запросов AI, квоты токенов и общие квоты отдельно. Смена IP не увеличивает лимиты аккаунта.

• Подбирайте прокси-инфраструктуру под требования сбора данных. CyberYozh App предоставляет геотаргетинг, sticky-сессии до 24 часов и безлимитный трафик.

Что означает 429 too many requests?

Ошибка 429 too many requests означает, что сервис ограничивает дальнейшие запросы, потому что вы достигли одного из его порогов использования. Обычно это связано с отправкой слишком большого количества запросов в определённом временном окне. Сам ответ не сообщает, какой именно лимит был достигнут или как долго продлится ограничение.

Чтобы понять, что означает «429 too many requests» для вашего процесса, проверьте, как сервис учитывает активность. Как объясняет документация MDN по 429, лимиты могут применяться ко всему серверу, к конкретному ресурсу или в зависимости от IP-адреса, аутентифицированного пользователя или приложения. Несколько воркеров могут поэтому делить один лимит, даже если каждый отправляет относительно мало запросов.

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

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

Выясните, какой сервис возвращает ошибку

Вернёмся к примеру со страницами товаров: сбор данных завершился неудачей до того, как текст попал в AI API, или анализ остановился после сохранения страниц?

В браузере откройте инструменты разработчика, выберите панель Network и изучите запрос со статусом 429. В Postman проверьте статус ответа, заголовки и тело. В логах приложения сопоставьте сбой с его временной меткой и этапом рабочего процесса.

Запишите имя хоста, тело ответа, соответствующие заголовки, временную метку и ID запроса, если они доступны. Удалите пароли, API-ключи, значения авторизации и сессионные куки перед передачей диагностических записей.

Как исправить ошибку 429 too many requests

Как только вы определите сервис, возвращающий ошибку 429, пусть детали ответа укажут на решение. Выполните эти шаги, прежде чем перезапускать всю задачу.

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

2. Соблюдайте заголовок Retry-After
   Retry-After: 60 означает ожидание минимум 60 секунд. HTTP-дата указывает, когда повторить попытку. Документация MDN по Retry-After объясняет оба формата. Когда заголовок отсутствует, обратитесь к документированным лимитам сервиса и используйте увеличивающиеся задержки повтора вместо того, чтобы предполагать универсальный период ожидания.

3. Снизьте частоту запросов и параллелизм
   Частота означает запросы, отправляемые за определённое время; параллелизм означает запросы, выполняемые одновременно. Контролируйте и то, и другое. Воркерам, использующим общий лимит, требуется скоординированная регулировка темпа, например общая очередь с ограничителем скорости, поскольку индивидуальные задержки не контролируют их совокупный трафик.

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

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

Этот пример GET на Python обрабатывает оба формата заголовка, возвращается к задержке при отсутствующих или некорректных значениях и останавливается после пяти неудачных попыток:

import random
import time
from datetime import timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_backoff(url):
    for attempt in range(5):
        response = requests.get(url, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response
        if attempt == 4:
            response.raise_for_status()

        value = response.headers.get("Retry-After", "").strip()
        delay = 2 ** attempt
        try:
            if value.isascii() and value.isdigit():
                delay = max(delay, int(value))
            elif value:
                retry_at = parsedate_to_datetime(value)
                if retry_at.tzinfo is None:
                    retry_at = retry_at.replace(tzinfo=timezone.utc)
                delay = max(delay, retry_at.timestamp() - time.time())
        except (ValueError, TypeError, OverflowError):
            pass  # Invalid header: keep the backoff delay.

        response.close()
        time.sleep(delay + random.uniform(0, 1))

Устранение повторяющихся ошибок 429 при скрейпинге

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

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

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

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

Устранение ошибок 429 в AI API и рабочих процессах агентов

Ваш скрейпер может успешно собрать все страницы товаров, а затем столкнуться с ошибкой 429 при отправке результатов на анализ. Завершение пакета сбора может вызвать всплеск вызовов модели, каждый из которых потребляет часть лимита запросов или токенов AI-провайдера.

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

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

Запись в логе вроде last status: 429 too many requests фиксирует финальный HTTP-статус; диагностика по-прежнему зависит от базового ответа. Проверьте тип ошибки провайдера, сообщение, ID запроса и заголовки лимитов, затем сравните их с информацией об использовании и биллинге. Временное ограничение скорости и исчерпанный лимит требуют разных действий. Claude, например, документирует ответ о превышении месячного лимита расходов уровня, который продолжает выдавать ошибку до восстановления доступа.

Храните собранные страницы независимо от задачи анализа. Когда AI-запрос терпит неудачу, повторите только этот этап обработки после устранения ограничения. Проверьте существующее поведение повторов SDK, чтобы внешний рабочий процесс не перезапускал повторно вызовы, которые клиент уже повторяет.

Если ответ противоречит наблюдаемому использованию, проверьте страницу статуса сервиса провайдера и исследуйте другие рабочие нагрузки, использующие общий лимит. Сохраните временную метку и ID запроса для поддержки. Изменение IP прокси скрейпера не увеличит лимиты запросов или токенов AI-аккаунта.

Как CyberYozh App вписывается в рабочий процесс скрейпинга

Как только диагностика выявит потребность в региональном доступе, непрерывности сессии или лучшем контроле над подключениями для сбора, CyberYozh App предоставляет несколько вариантов инфраструктуры. Сопоставьте подключение с задачей, включая то, как долго связанные запросы должны сохранять один и тот же IP.

• Мобильные прокси: Безлимитный трафик на реальных LTE/4G/5G-тарифах позволяет точно прогнозировать расходы на подключение при регулярном сборе данных. Выделенные планы резервируют мобильный канал для вашей задачи, тогда как совместные планы используют канал наряду с другими клиентами. Выделенные подключения поддерживают смену IP вручную и через API, что позволяет планировать смену адресов в зависимости от границ задач. 

• Ротационные резидентские прокси: Используйте региональный таргетинг для сбора объявлений или цен, зависящих от местоположения. Выбирайте ротацию для независимых задач сбора данных или sticky-сессии до 24 часов, когда связанные запросы требуют временного сохранения одного IP. Трафик тарифицируется по факту использования, при этом неиспользованный трафик переносится на следующий расчётный месяц.

• Статичные ISP-прокси: Фиксированный адрес на период аренды подходит для повторяющихся сессий сбора данных, требующих одного и того же IP. Это обеспечивает непрерывность между отдельными запусками без зависимости от временной sticky-сессии.

• Выделенные датацентровые прокси: Они обеспечивают фиксированное подключение через датацентр для задач, где целевой сайт принимает этот тип сети. Подходят для регулярного сбора данных, не требующего резидентского или мобильного подключения.

CyberYozh App поддерживает подключение прокси в Scrapy, Postman, Playwright, Puppeteerи Selenium. Полный доступ к API позволяет скриптам управлять поддерживаемыми операциями прокси параллельно с вашим существующим кодом сбора данных.