Ошибка 429 Too Many Requests: стратегии с прокси
Код 429 Too Many Requests — официальный сигнал сервера: вы превысили лимит частоты обращений. В отличие от 403, это не всегда перманентный бан — часто достаточно подождать или сменить IP. Но наивная ротация прокси без backoff может усугубить ситуацию и перевести временный throttle в блокировку подсети. Разберём рабочие стратегии для автоматизации с NEONPROXY.
Откуда берётся 429
Rate limiting применяют на разных уровнях: CDN (Cloudflare, Akamai), reverse proxy (nginx limit_req), application middleware и API gateway. Лимит может считаться по IP, по API-ключу, по cookie/fingerprint или по комбинации факторов.
Прокси меняет только IP — если лимит привязан к заголовку Authorization или device-id, смена адреса не поможет. Диагностика: получите 429 с одного IP, смените прокси — если ошибка осталась, проблема не в rate limit по IP.
Заголовки ответа
Изучайте ответ сервера, а не только status code:
Retry-After — секунды или HTTP-date, когда можно повторить запрос. Уважайте это значение: немедленный retry удваивает «штраф». X-RateLimit-Remaining и X-RateLimit-Reset — типичны для REST API; планируйте паузу до reset timestamp. CF-Ray и заголовки Cloudflare — признак edge-limit; иногда помогает смена гео прокси, но не always.
Стратегия 1: снижение частоты
Самый дешёвый и устойчивый подход — уменьшить rps. Token bucket или leaky bucket на стороне клиента: не более N запросов в секунду на прокси. Добавьте random jitter 100–500 ms между запросами — синхронные burst'ы от нескольких воркеров выглядят как бот-атака.
Если API публикует лимит «100 req/min», закладывайте запас 80% — погрешность часов и сетевые ретраи съедают маржу.
Стратегия 2: ротация прокси
При 429 на IP A переключитесь на IP B из пула и поставьте A в «cooldown» на 5–15 минут. Не используйте A снова, пока не истечёт Retry-After или ваш таймер. Пул из 20–50 IPv6-адресов NEONPROXY даёт запас для ротации без простоя — см. ротацию прокси.
Ошибка: мгновенно крутить все адреса подряд на тот же URL. Целевой сайт видит десятки IP с одинаковым User-Agent и паттерном — включается WAF на уровне ASN или /24 подсети.
Стратегия 3: exponential backoff
Алгоритм: пауза = min(base × 2^attempt + random(0,1), max_delay). Типичные параметры: base=1 s, max=120 s, max_attempts=5. После исчерпания попыток — dead letter, не бесконечный цикл.
Комбинируйте backoff с ротацией: первые 2 retry — пауза на том же IP (если Retry-After короткий), далее — смена прокси. Так вы не «сжигаете» весь пул на одной «горячей» странице.
Стратегия 4: распределение нагрузки
Разнесите запросы по времени: cron вместо continuous crawl, ночные окна для тяжёлых задач. Горизонтально — больше прокси при том же aggregate rps: 10 IP × 2 rps = 20 rps total при 2 rps на каждый IP (безопаснее, чем 1 IP × 20 rps).
Для параллельных воркеров см. параллельные запросы через пул: семафор на concurrency критичен именно при 429.
Когда прокси не спасёт
Лимит по аккаунту API (OAuth token) — нужен другой ключ или тариф. CAPTCHA после серии 429 — автоматическая смена IP не пройдёт challenge. Global ban ASN датацентровых прокси — попробуйте другой провайдер или тип IP, проверьте адрес в blacklist-чекере.
GraphQL и REST с pagination: иногда лимит на «глубину» скrolling, а не на rps — замедление не поможет, нужен другой метод сбора данных.
Мониторинг и алерты
Считайте 429 rate отдельно от 5xx. Spike 429 на одном proxy_id — cooldown этого IP. Spike на всех — вы превысили global limit или изменились правила сайта. Логируйте URL, proxy, Retry-After, timestamp для post-mortem.
Dashboard: requests/min, 429/min, avg backoff time, pool size healthy. Алерт при 429 rate > 10% в скользящем окне 5 минут.
Чеклист действий при 429
1) Прочитать Retry-After и rate limit headers. 2) Поставить паузу, не retry сразу. 3) Снизить concurrency. 4) Ротировать прокси после 2–3 неудачных retry. 5) Проверить, не один ли URL генерирует весь поток ошибок. 6) Убедиться, что прокси жив через чекер. 7) При систематических 429 — пересмотреть архитектуру или запросить официальный API.
NEONPROXY позволяет быстро расширить пул IPv6 — дешевле масштабировать адреса, чем воевать с жёстким throttle одним IP.