Разбор ошибки · 1 мин чтения

Как исправить 429 Too Many Requests при скрапинге

429 — это лимит частоты, а не бан: сервер просит вас притормозить. Надёжное решение сочетает backoff, уважение к Retry-After и распределение нагрузки между пулом IP. Показываем как, с рабочим кодом на Python.

429 — это ограничение скорости, а не стена

HTTP 429 Too Many Requests означает, что вы отправили слишком много запросов за отведённое окно и сервер вас притормаживает. Это намеренно временно: в отличие от жёсткой блокировки, 429 обычно проходит, как только вы сбавите темп. Многие серверы добавляют заголовок Retry-After, который прямо говорит, сколько секунд ждать; послушаться его — самый действенный шаг, потому что так вы выравниваетесь с реальным лимитом сервера, а не гадаете.

Рычага два. Первый — темп: меньше запросов в секунду с одного IP, паузы, ограниченная параллельность и экспоненциальный откат, когда появился 429. Второй — распределение: раскидать запросы по нескольким IP, чтобы каждый оставался под своим лимитом. Начинать нужно с темпа: пул прокси умножает вашу пропускную способность, но не даёт права долбить сайт. s4m даёт датацентровые прокси с авторизацией (SOCKS5 1080, HTTP 3128, USER:PASS), чтобы развести нагрузку, и это напрямую стыкуется с руководством по ротации прокси и скрапингом на requests.

Уважайте Retry-After, откатывайтесь, потом ротируйте

Цикл загрузки, который слушается Retry-After, откатывается экспоненциально с джиттером и раскидывает запросы по пулу прокси. Замените USER:PASS.

python
import random, time
import requests

USER, PASS, HOST = "USER", "PASS", "proxy.s4m.online"
POOL = [
    f"socks5h://{USER}:{PASS}@{HOST}:1080",
    f"http://{USER}:{PASS}@{HOST}:3128",
]

def polite_get(url, max_tries=6):
    for attempt in range(1, max_tries + 1):
        proxy = random.choice(POOL)
        r = requests.get(url, proxies={"http": proxy, "https": proxy},
                         timeout=(5, 20))
        if r.status_code != 429:
            r.raise_for_status()
            return r

        # 429: prefer the server's Retry-After, else exponential backoff
        retry_after = r.headers.get("Retry-After")
        if retry_after and retry_after.isdigit():
            wait = int(retry_after)
        else:
            wait = min(2 ** attempt, 60) + random.random()  # cap + jitter

        print(f"[{attempt}/{max_tries}] 429; waiting {wait:.1f}s")
        time.sleep(wait)

    raise SystemExit(f"still rate-limited after {max_tries} tries")

# Global throttle: cap how fast you fire, independent of retries.
MIN_INTERVAL = 0.5  # seconds between requests per worker
_last = 0.0
def throttled_get(url):
    global _last
    delta = time.time() - _last
    if delta < MIN_INTERVAL:
        time.sleep(MIN_INTERVAL - delta)
    _last = time.time()
    return polite_get(url)

print(throttled_get("https://httpbin.org/status/200").status_code)

В каком порядке лечить 429

Сначала самое дешёвое и самое вежливое.

Слушайтесь Retry-After

Если в ответе 429 есть заголовок Retry-After, подождите ровно столько, сколько он говорит, и только потом повторяйте. Это сервер сам называет свой лимит — и большинство 429 снимается сразу.

Добавьте экспоненциальный откат с джиттером

Когда Retry-After нет, ждите 2, 4, 8… секунд (с потолком) плюс небольшой случайный джиттер между попытками — так вы перестаёте долбить и избегаете синхронных повторов.

Притормозите темп запросов

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

Раскидывайте нагрузку по IP

Когда поведение на уровне отдельного запроса уже вежливое, ротируйте пул прокси, чтобы каждый IP оставался под своим лимитом. Так безопасная пропускная способность умножается, а темп на любом отдельном адресе не растёт.

Почему одна лишь ротация не спасает

Соблазн велик: считать прокси способом игнорировать лимиты — просто добавь адресов и стреляй дальше. Это выходит боком. Сайт, отдающий 429, следит за паттернами запросов, и поток с меняющегося набора адресов, бьющий в те же эндпоинты в тот же миг, сам по себе является заметной подписью, которая перерастает в жёсткий бан. Ротация умножает вежливую пропускную способность, а не заменяет вежливость. Всегда сочетайте пул прокси с откатом, Retry-After, реалистичным темпом и разумной параллельностью.

Честно говоря, некоторые лимиты стоит просто уважать: проверьте, нет ли официального API или задокументированного разрешённого темпа, прежде чем обходить 429, и читайте условия сайта. А когда распределение действительно нужно, датацентровые прокси s4m с авторизацией разводят нагрузку и тарифицируются по трафику, так что расширять пул дёшево; механика — в руководстве по ротации. Помните: датацентровые IP могут банить целыми диапазонами, а от фингерпринтов ротация не спасает вовсе. Прототипируйте дёшево на бесплатном списке прокси и проверяйте выходы инструментами.

FAQ

Ответы на вопросы

429 — это постоянный бан?

Нет. HTTP 429 Too Many Requests — это временное ограничение темпа, оно обычно проходит, как только вы сбавите ход. Послушайтесь заголовка Retry-After, добавьте откат, снизьте темп запросов — и доступ обычно возвращается.

Что действеннее всего против 429?

Уважать заголовок Retry-After, когда сервер его присылает. Он точно говорит, сколько ждать, так что вы выравниваетесь с лимитом сервера, вместо того чтобы гадать и снова попадать под тормоз.

Уберёт ли ротация прокси ошибки 429?

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

Достаточно ли прокси s4m, чтобы обойти любой лимит?

Ни один честный инструмент такого не пообещает. Датацентровые прокси s4m разводят нагрузку по IP, но откат и притормаживание всё равно нужны, датацентровые диапазоны могут пометить целиком, а часть лимитов стоит просто уважать и пойти через официальный API.

Разводите нагрузку честно

Сочетайте откат и притормаживание с датацентровыми прокси с авторизацией на proxy.s4m.online, чтобы каждый IP оставался под лимитом. Оплата по фактическому трафику, выделенный IP — по желанию.

Эту страницу нашли по запросу

  • как исправить 429 too many requests при скрапинге
  • резидентские прокси
  • свежий список бесплатных прокси
  • список бесплатных прокси
  • как работает openvpn
  • как проверить http прокси
  • как сконфигурировать wireguard
  • прокси для парсинга для бизнеса
  • socks5 прокси пошагово
  • Tinyproxy, 3proxy и Squid
  • безопасен ли авторизация прокси
  • ip адрес настройки
  • UDP через SOCKS5
  • безопасен ли openvpn
  • openvpn
  • обход DPI
  • http прокси
  • ip адрес

Реальные поисковые фразы, на которые отвечает эта страница — по ссылкам откроются материалы, раскрывающие тему глубже.