Błąd HTTP 429 Too Many Requests: co oznacza i jak go naprawić

Czym jest HTTP Error 429?

HTTP 429 Too Many Requests oznacza, że serwer ogranicza liczbę Twoich żądań (rate limiting): Ty, Twój adres IP lub Twoja aplikacja wysłaliście ich więcej, niż serwer dopuszcza w danym czasie. To stan tymczasowy. Serwer działa, ale na razie postanowił Ci nie odpowiadać.

Kod wprowadzono w RFC 6585 (2012) właśnie na taki przypadek, a odpowiedź może zawierać nagłówek Retry-After, który mówi, ile czekać. Spotkasz go podczas przeglądania popularnych stron, wywoływania API, masowego pobierania danych albo przy korzystaniu z VPN-a, którego adres IP dzieli wielu ludzi.

Różni się od sąsiednich kodów: 401 znaczy, że nie jesteś zalogowany, 403, że nie masz uprawnień, a 429, że uprawnienia masz, tylko działasz zbyt szybko.

Jak wygląda błąd 429?

Komunikat zależy od tego, kto odpowiada. Oto te, których ludzie szukają:

W odróżnieniu od błędu 500, który oznacza awarię po stronie serwera, 429 jest w terminologii HTTP błędem klienta: serwer chroni się przed zbyt dużą liczbą żądań.

Jak działa rate limiting?

Rate limiting to technika, której serwery używają do kontrolowania, ile żądań klient może wysłać w danym oknie czasowym. Po przekroczeniu limitu serwer zwykle odpowiada kodem 429 (niektóre zwracają zamiast tego 403 lub 503).

Istnieje kilka popularnych algorytmów rate limitingu:

• Fixed Window (Okno stałe) — Serwer pozwala na N żądań w oknie czasowym (np. 100 żądań na minutę). Licznik resetuje się w stałych odstępach.
• Sliding Window (Okno przesuwne) — Podobne do okna stałego, ale okno przesuwa się z każdym żądaniem. Zapobiega to nagłym skokom na granicach okien.
• Token Bucket (Wiadro tokenów) — Serwer przydziela tokeny, które uzupełniają się ze stałą prędkością. Każde żądanie zużywa jeden token. Gdy tokeny się skończą, żądania są odrzucane.
• Leaky Bucket (Cieknące wiadro) — Żądania przetwarzane są ze stałą prędkością niezależnie od wielkości skoków. Nadmiarowe żądania trafiają do kolejki lub są odrzucane.

Wiele API podaje swoje limity w nagłówkach odpowiedzi. W GitHubie są to na przykład x-ratelimit-limit (liczba żądań dozwolonych na godzinę), x-ratelimit-remaining, x-ratelimit-used i x-ratelimit-reset (kiedy okno się resetuje, w sekundach Unix). Wstępna propozycja IETF wprowadza do tego samego celu standardowe nagłówki RateLimit i RateLimit-Policy.

Wiedza, jakiego algorytmu i jakiego okna używa usługa, pomaga zaprojektować klienta tak, by mieścił się w limicie.

Najczęstsze przyczyny błędu HTTP 429

Przyczyna zależy od tego, kto widzi błąd:

Jak naprawić błąd 429 (dla użytkowników)

Jeśli widzisz błąd 429 podczas przeglądania strony, oto rozwiązania, które możesz wypróbować. Zacznij od najprostszego i przechodź do kolejnych.

1. Poczekaj i spróbuj ponownie

Najprostsze rozwiązanie to poczekać. Błąd 429 jest tymczasowy: serwer prosi Cię o zwolnienie tempa, a nie banuje Cię.

Jak długo, zależy od limitu strony: niektóre resetują się w ciągu minuty, inne co godzinę lub co dobę. Jeśli strona lub API wysyła nagłówek Retry-After, to jest dokładny czas oczekiwania. Potem załaduj stronę jeden raz.

Nie odświeżaj w kółko: każde odświeżenie to kolejne żądanie, które liczy się do tego samego limitu.

2. Wyczyść ciasteczka tej witryny

Rzadko ma to znaczenie, ale niektóre strony liczą żądania na podstawie ciasteczka sesji. Wyczyść ciasteczka tylko tej jednej witryny, aby zacząć nową sesję bez wylogowywania się ze wszystkiego innego:

• Chrome / Edge: otwórz chrome://settings/content/all (Edge: edge://settings/content/all), wyszukaj witrynę i usuń jej dane
• Firefox: kliknij kłódkę w pasku adresu → Wyczyść ciasteczka i dane witryny
• Safari: Safari → Ustawienia → Prywatność → Zarządzaj danymi witryn → znajdź witrynę → Usuń

Po wyczyszczeniu zamknij i ponownie otwórz przeglądarkę, zanim odwiedzisz stronę.

3. Odłącz VPN lub proxy

Jeśli korzystasz z VPN-a lub proxy, możesz dzielić adres IP z setkami innych użytkowników. Gdy ich łączne żądania przekroczą limit serwera, wszyscy na tym IP dostają ograniczenie.

Spróbuj odłączyć VPN i wejść na stronę przez zwykłe połączenie. Jeśli błąd 429 zniknie, problemem był adres IP VPN-a.

Jeśli VPN jest Ci potrzebny, przełącz się na inną lokalizację serwera: jego adres może być współdzielony przez mniej osób.

4. Wyłącz rozszerzenia przeglądarki

Niektóre rozszerzenia w tle wysyłają żądania do odwiedzanych stron: narzędzia do śledzenia cen, narzędzia SEO i rozszerzenia do automatycznego odświeżania potrafią zsumować się do limitu. (Blokery reklam zwykle robią odwrotnie i zmniejszają liczbę żądań.)

Aby to sprawdzić, otwórz stronę w oknie incognito/prywatnym, gdzie większość rozszerzeń jest wyłączona. Incognito startuje też bez ciasteczek, więc jeśli 429 zniknie, w grę wchodzi rozszerzenie albo limit oparty na sesji.

Wyłączaj rozszerzenia jedno po drugim, aby znaleźć to problematyczne. W Chrome przejdź do chrome://extensions/ i wyłączaj je pojedynczo.

5. Sprawdź, czy twój adres IP jest współdzielony

Jeden publiczny adres IP może dzielić wiele osób: sieć biurowa lub szkolna, sieć operatora komórkowego (CGNAT) albo serwer VPN. Ich żądania liczą się do tego samego limitu co Twoje.

Jeśli jesteś w takiej sieci, załadowanie strony z własnego łącza domowego lub z danych komórkowych pokaże, czy problemem jest współdzielony adres. Jeśli limit dotyczy Twojego własnego adresu, poczekaj na jego reset zamiast zmieniać sieć, by go obejść. Swój aktualny publiczny adres IP sprawdzisz w narzędziu Moje IP.

Jak naprawić błąd 429 (dla programistów)

Jeśli Twój kod dostaje 429, wysyła żądania szybciej, niż pozwala API. Obsłuż to w tej kolejności: odczytaj Retry-After, opóźniaj z jitterem, a potem zmniejsz liczbę żądań.

1. Zastosuj wykładnicze opóźnianie (exponential backoff)

Wykładnicze opóźnianie to standardowa strategia ponawiania: zamiast powtarzać żądanie od razu po 429, podwajaj czas oczekiwania za każdym razem (1 sekunda, 2, 4, 8…) i dodaj jitter, czyli losowe dodatkowe opóźnienie, żeby wielu klientów nie ponawiało w tej samej chwili.

Ta wersja używa Retry-After, gdy serwer wyśle poprawny nagłówek w jednym z dwóch formatów, w przeciwnym razie wraca do opóźniania z jitterem, a po kilku próbach rezygnuje. (W przeglądarce, wywołującej API innej witryny, Retry-After da się odczytać tylko wtedy, gdy API udostępnia go przez Access-Control-Expose-Headers.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Respektuj nagłówek Retry-After

Gdy serwer wysyła Retry-After razem z 429, podaje dokładnie, ile czekać. RFC 9110 dopuszcza dwie formy: liczbę sekund albo datę HTTP.

Retry-After: 60 oznacza czekaj 60 sekund. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT oznacza czekaj do tej chwili. Sprawdź go przed własną logiką opóźniania: serwer wie lepiej niż Twój kod.

W Pythonie obsłuż obie formy i przerwij po kilku próbach zamiast rekurencji bez końca:

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

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. Cachuj odpowiedzi API

Jeśli aplikacja wielokrotnie wykonuje to samo wywołanie API, cachuj odpowiedź zamiast odpytywać API za każdym razem. To drastycznie zmniejsza liczbę żądań.

Użyj cache'u w pamięci (np. Redis lub zwykłej mapy) dla często używanych danych. Ustaw rozsądny TTL (czas życia) zależnie od tego, jak często dane się zmieniają.

Na przykład jeśli sprawdzasz rekordy DNS domeny, wyniki raczej nie zmienią się w ciągu najbliższych 5 minut: zcachuj je.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Używaj webhooków zamiast pollingu

Jeśli wielokrotnie odpytujesz API w celu sprawdzenia zmian (np. sprawdzasz status zamówienia co 10 sekund), przejdź na webhooki, jeśli usługa je obsługuje.

Dzięki webhookom serwer wysyła aktualizacje do Twojej aplikacji, gdy coś się zmieni — nie trzeba ciągle odpytywać. Może to zmniejszyć liczbę zapytań API z tysięcy na godzinę do zaledwie kilku.

Większość nowoczesnych API (Stripe, GitHub, Twilio, Shopify) obsługuje webhooki. Sprawdź dokumentację API pod kątem konfiguracji webhooków.

5. Poproś o wyższe limity

Jeśli naprawdę potrzebujesz więcej wywołań API, skontaktuj się z dostawcą usługi. Wiele API oferuje wyższe limity w płatnych planach lub dla zweryfikowanych aplikacji.

Prosząc o wyższe limity, opisz swój przypadek użycia i podaj szacowaną liczbę żądań. Wiele API, w tym Google, ma formularz albo płatny pakiet z wyższymi limitami.

Niektóre API oferują też endpointy masowe (bulk), które pozwalają pobrać wiele zasobów jednym żądaniem, zmniejszając łączną liczbę wywołań.

Jak naprawić błąd 429 (dla administratorów)

Jeśli Twoi odwiedzający albo odbiorcy API dostają błędy 429, problem leży w konfiguracji serwera. Oto jak go zdiagnozować i naprawić.

1. Dostosuj limity żądań

Jeśli prawdziwi użytkownicy dostają 429, ustal, która warstwa odpowiada pierwsza: CDN lub WAF, serwer WWW czy aplikacja. Potem dostosuj limity tej warstwy.

W nginx pracę wykonuje limit_req. Uwaga: domyślnie odpowiada on 503, więc dodaj limit_req_status 429;, aby klienci wiedzieli, że mają zwolnić, a nie uznali, że serwer nie działa:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Parametr burst przepuszcza krótkie skoki bez 429; bez niego zwykłe załadowanie strony z wieloma żądaniami może trafić w limit.

Apache nie ma wbudowanego ogranicznika liczby żądań: jego mod_ratelimit ogranicza przepustowość, a nie liczbę żądań, a zewnętrzny mod_evasive odpowiada 403. Dla 429 użyj reverse proxy, WAF albo własnej aplikacji. W Node.js express-rate-limit domyślnie odpowiada 429.

2. Dodaj zaufane adresy IP do białej listy

Jeśli limit dostają konkretni klienci (usługi monitoringu, operatorzy płatności, Twoje własne mikroserwisy), dodaj ich adresy IP do białej listy.

W nginx geo i map nadają zaufanym adresom pusty klucz, a nginx nie liczy żądań z pustym kluczem. To zastępuje linię limit_req_zone z poprzedniego przykładu:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

Nie ograniczaj przypadkiem robotów wyszukiwarek: Google traktuje 429 jak błąd serwera i zwalnia indeksowanie (Google Search Central). Prawdziwe żądania Googlebota i Bingbota weryfikuj wyszukiwaniem Reverse DNS Lookup potwierdzonym wyszukiwaniem wprost tej nazwy albo wyłącz z limitów opublikowane zakresy IP robotów.

3. Sprawdź ustawienia WAF i CDN

Jeśli używasz Cloudflare, AWS WAF, Sucuri lub innej usługi bezpieczeństwa, jej reguły limitów mogą odpowiedzieć, zanim serwer w ogóle zobaczy żądanie.

Cloudflare pokazuje odwiedzającym „Error 1015: You are being rate limited”, gdy zadziała reguła rate limiting. Znajdź regułę w regułach bezpieczeństwa w panelu, sprawdź jej zdarzenia i podnieś próg albo zawęź jej zakres.

Reguły oparte na liczbie żądań w AWS WAF zliczają żądania na adres IP (lub inny klucz) w oknie 1, 2, 5 albo 10 minut, z minimalnym limitem 10. Zablokowane żądanie domyślnie dostaje 403; ustaw własną odpowiedź 429, aby klienci wiedzieli, że mają zwolnić.

Zanim cokolwiek zmienisz, sprawdź analitykę CDN, aby odróżnić prawdziwych odwiedzających od botów.

4. Zoptymalizuj wydajność serwera

Niektóre usługi ograniczają ostrzej, gdy są pod obciążeniem, jako zawór bezpieczeństwa. Poprawa wydajności serwera pozwala bezpiecznie podnieść limity.

Kluczowe optymalizacje obejmują: włączenie cachowania odpowiedzi w celu odciążenia backendu, użycie CDN dla zasobów statycznych, dodanie cachowania zapytań bazodanowych z Redis lub Memcached, wdrożenie poolingu połączeń do bazy danych oraz skalowanie horyzontalne z load balancingiem, jeśli ruch tego wymaga.

Użyj naszego narzędzia Checker nagłówków HTTP, aby sprawdzić, czy nagłówki cachowania są ustawione poprawnie.

Błąd 429 a inne kody HTTP

Błąd 429 łatwo pomylić z innymi kodami HTTP. Oto czym się różnią:

Kluczowa różnica: 429 jest celowy i tymczasowy: serwer postanowił Cię na razie odesłać. Większość kodów 5xx oznacza, że coś zawiodło na serwerze, choć 503 może też oznaczać planowaną konserwację albo, w nginx, limit żądań.

Jak zapobiegać błędom 429

Zapobieganie jest lepsze niż leczenie. Oto najlepsze praktyki, aby unikać błędów 429:

• Czytaj dokumentację API — Poznaj limity żądań, zanim zaczniesz pisać kod. Większość usług publikuje swoje limity w czytelny sposób.
• Monitoruj swoje użycie — Śledź nagłówki X-RateLimit-Remaining, aby wiedzieć, jak blisko jesteś limitu.
• Grupuj żądania — Korzystaj z endpointów masowych (bulk), gdy są dostępne, zamiast wykonywać pojedyncze zapytania.
• Rozkładaj żądania w czasie — Wysyłaj zapytania API równomiernie w czasie, zamiast wysyłać je seriami.
• Używaj kluczy API — Uwierzytelnione żądania zazwyczaj mają wyższe limity niż anonimowe.
• Wdrażaj circuit breakery — Jeśli wielokrotnie otrzymujesz 429, całkowicie wstrzymaj wysyłanie żądań na okres ochłodzenia.
• Testuj z symulatorami rate limitów — Symuluj odpowiedzi 429 w środowisku deweloperskim, aby upewnić się, że obsługa błędów działa poprawnie.
• Loguj odpowiedzi 429 — Śledź, kiedy i gdzie występuje rate limiting, aby zoptymalizować wzorce żądań.