Referencja błędu proxy · Kody statusu HTTP

429 Too Many Requests podczas scrapingu: co oznacza i jak to naprawić

Q: Jak długo czekać po 429?

Czekaj tyle sekund, ile podaje nagłówek Retry-After lub do daty w nim zawartej. Bez nagłówka zacznij od 1-2 sekund i podwajaj opóźnienie po każdym kolejnym 429, z losową nadwyżką i limitem około minuty. Wznów działanie przy niższym tempie, nie takim, które spowodowało 429.

Kod statusu HTTP (4xx, błąd klienta): dokładny komunikat w każdym narzędziu, możliwe przyczyny w kolejności oraz działające rozwiązanie.

Ostatnia aktualizacja: 13 października 2026 · 4 min czytania

Szybka odpowiedź

Co oznacza 429 Too Many Requests w kontekście proxy?

429 Too Many Requests oznacza, że strona ogranicza liczbę zapytań: wysłałeś ich więcej, niż akceptuje w czasie. Naprawa to wysyłanie mniej zapytań, nie ich ukrywanie. Przy residential proxy CrawlRelay respektuj nagłówek Retry-After, ogranicz współbieżność na hosta i stosuj wykładniczy backoff z losowym jitterem. Rotacja IP, by przekroczyć limit strony, łamie większość regulaminów.

429 Too Many Requests w skrócie

Błąd	429 Too Many Requests
Typ	Kod statusu HTTP (4xx, błąd klienta)
Wysłane przez	Docelowa strona lub jej brama API
Zdefiniowano w	RFC 6585, section 4 (Retry-After: RFC 9110, section 10.2.3)
Spróbować ponownie?	Tak, po upływie opóźnienia Retry-After lub zastosowaniu wykładniczego backoff
Najpierw sprawdź	Odczytaj nagłówek Retry-After i monitoruj swoje zapytania na sekundę na hosta

Co oznacza 429 Too Many Requests?

RFC 6585 wprowadziło kod 429 dla ograniczeń szybkości. Serwer może dołączyć nagłówek Retry-After, podający liczbę sekund lub datę HTTP, kiedy wrócić. API często dodają swoje nagłówki, np. X-RateLimit-Remaining.

429 to najbardziej uprzejma odpowiedź serwera dla scrapera. Oznacza, że zawartość jest dostępna, tylko nie w tym tempie. Strony ignorujące 429 zazwyczaj eskalują do 403, CAPTCHA lub blokad.

Jak wygląda a 429 w Python, curl, Node.js i przeglądarkach?

Ten sam błąd wyświetla się inaczej w każdym narzędziu. Oto komunikaty, które warto wyszukać w logach:

Python requests / httpx: status_code == 429, często z Retry-After: 30
Scrapy: obsługiwane przez RetryMiddleware, ponieważ 429 jest w domyślnych RETRY_HTTP_CODES
curl: HTTP/2 429 a potem retry-after: w nagłówkach
API: ciało JSON jak {"error": "rate_limited"}

Co powoduje a 429?

Najczęściej na początku:

Zbyt duża współbieżność na hosta. Pięćdziesięciu równoległych workerów na jednej domenie wygląda jak atak.
Brak opóźnienia między zapytaniami lub stałe opóźnienie, które synchronizuje wielu workerów naraz.
Ponowne próby bez backoff. Burza retry po pierwszym 429 potęguje obciążenie.
Wspólne limity. Niektóre strony liczą zapytania na konto, klucz API lub cookie sesji, nie na IP.
Ciężkie endpointy. URL-e wyszukiwania i filtrowania mają często ostrzejsze limity niż statyczne strony.

Jak krok po kroku zdiagnozować a 429?

Zaloguj wartość Retry-After i inne nagłówki limitów przy pierwszym 429.
Zmierz rzeczywistą liczbę zapytań na host, nie łączną.
Sprawdź, czy limit dotyczy IP, cookie czy klucza API: zmieniaj je pojedynczo.
Przeczytaj dokumentację API lub robots.txt strony; linia Crawl-delay ustala wymaganą prędkość.

Przetestuj nie działający URL za pomocą curl (port HTTP, tryb verbose)

# Use the URL that fails; with https://api.ipify.org instead, you test the gateway alone.
# "HTTP/1.1 200 Connection established" first, then the site's own status: the site answered.
curl -v -x http://USERNAME:[email protected]:7777 https://TARGET_URL

# Same test through the SOCKS5 port, with DNS resolved at the exit
curl -v --socks5-hostname gw.crawlrelay.com:7778 --proxy-user USERNAME:PASSWORD https://TARGET_URL

Jak naprawić a 429?

Respektuj Retry-After. Czekaj co najmniej tak długo, jak prosi serwer.
Ogranicz współbieżność na host, nie tylko globalnie. Scrapy ma CONCURRENT_REQUESTS_PER_DOMAIN i AUTOTHROTTLE_ENABLED.
Stosuj wykładniczy backoff z jitterem: 1 s, 2 s, 4 s itd., plus losowa wartość, z limitem maksymalnym.
Pobieraj mniej. Pamiętaj cache, wysyłaj If-Modified-Since albo If-None-Match, pomijaj niezmienione strony.
Używaj oficjalnego API, jeśli jest dostępne; limity zwykle są udokumentowane.

Python: ponów próbę z Retry-After, wykładniczym opóźnieniem i jitterem

import random
import time

import requests

PROXY = "http://USERNAME:[email protected]:7777"
PROXIES = {"http": PROXY, "https": PROXY}
RETRY_STATUSES = {429, 502, 503, 504}


def fetch(url, attempts=5, timeout=(10, 30)):
    for attempt in range(attempts):
        try:
            r = requests.get(url, proxies=PROXIES, timeout=timeout)
        except (requests.exceptions.ConnectionError, requests.exceptions.Timeout):
            r = None  # dropped exit, reset or timeout: a new connection gets a new exit
        if r is not None and r.status_code not in RETRY_STATUSES:
            return r
        retry_after = r.headers.get("Retry-After", "") if r is not None else ""
        if retry_after.isdigit():
            wait = int(retry_after)
        else:
            wait = min(60, 2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)
    raise RuntimeError("giving up on %s after %d attempts" % (url, attempts))

Czy warto ponawiać próbę po a 429?

Tak, 429 można powtórzyć później. Poczekaj na opóźnienie Retry-After, jeśli serwer je podał; w przeciwnym razie stosuj wykładniczy backoff z jitterem i limitem. Licz kolejne 429 na host i zmniejszaj na nim współbieżność, gdy rośnie liczba błędów. Poniższa funkcja w Python robi podstawową część.

Jak 429 Too Many Requests odnosi się do CrawlRelay?

429 przez CrawlRelay niesie oryginalne nagłówki i ciało celu: limit jest po stronie serwisu, a synchro zapytań na host zależy od Ciebie. Używaj sticky sessions, gdy strona liczy zapytania na sesję, aby tempo było mierzalne. Zobacz przewodnik po współbieżności z wartościami startowymi.

Gateway: gw.crawlrelay.com, port 7777 (HTTP, HTTPS przez CONNECT) i port 7778 (SOCKS5). Format nazwy użytkownika: USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}. Powiązane: 403 Forbidden · 503 Service Unavailable · Przewodnik po współbieżności.

429 Too Many Requests: pytania, które zadają deweloperzy

Czy powinienem rotować IP, żeby uniknąć błędów 429?

Nie. 429 to prośba strony, by zwolnić tempo. Rozdzielanie tego samego tempa na wiele IP, by mieścić się pod limitem na IP, to obejście i większość regulaminów tego zabrania. Rotacja jest przydatna do rozłożenia obciążenia i lokalizacji, ale nie do przekraczania limitu. Zmniejsz tempo i korzystaj z cache.

Jak długo czekać po 429?

Czekaj tyle sekund, ile podaje nagłówek Retry-After lub do daty w nim zawartej. Bez nagłówka zacznij od 1-2 sekund i podwajaj opóźnienie po każdym kolejnym 429, z losową nadwyżką i limitem około minuty. Wznów działanie przy niższym tempie, nie takim, które spowodowało 429.

Dlaczego dostaję 429 przy kilku zapytaniach na minutę?

Limit może dotyczyć konta, cookie lub klucza API, a nie IP, albo endpoint może być kosztowny, jak strona wyszukiwania. Niektóre strony ustawiają też niskie limity dla klientów klasyfikowanych jako boty. Sprawdź nagłówki i dokumentację API, ewentualnie poproś o dostęp.

Inne błędy proxy w tym odniesieniu

Kody statusu HTTP

Błędy w przeglądarce i kliencie

Błędy połączenia i TLS

Proxy rezydencjalne z dokumentacją opisującą przypadki błędów

CrawlRelay proxy rezydencjalne od 0,50 USD/GB, ruch, który nigdy nie wygasa.

Zobacz ceny Szybki start