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 дозволяє скриптам керувати підтримуваними операціями проксі паралельно з вашим існуючим кодом збору даних.