HTTP Error 429 Too Many Requests: Przyczyny i sposoby naprawy

Czym jest HTTP Error 429?

HTTP error 429 to kod błędu po stronie klienta, który oznacza Too Many Requests (zbyt wiele żądań). Serwer informuje Cię, że wysłałeś zbyt dużo żądań w określonym przedziale czasu i tymczasowo odmawia obsługi kolejnych, dopóki nie zwolnisz tempa.

Błąd ten został zdefiniowany w RFC 6585 i stanowi część mechanizmu ograniczania częstotliwości żądań HTTP (rate limiting). Jest to jeden z najczęstszych błędów, z jakimi spotykają się programiści pracujący z API, ale zwykli użytkownicy również mogą go zobaczyć podczas przeglądania stron internetowych.

Kod statusu 429 różni się od innych błędów 4xx. Błąd 403 oznacza brak uprawnień. Błąd 401 oznacza brak uwierzytelnienia. Błąd 429 natomiast mówi, że Twoje dane logowania są prawidłowe — po prostu wysyłasz żądania zbyt szybko.

Gdy serwer zwraca odpowiedź 429, może dołączyć nagłówek Retry-After, który dokładnie informuje, jak długo należy poczekać przed wysłaniem kolejnego żądania.

Jak wygląda błąd 429?

Błąd 429 prezentuje się różnie w zależności od przeglądarki, aplikacji lub klienta API, którego używasz. Oto najczęstsze warianty:

W odróżnieniu od błędów 500, które wskazują na problem po stronie serwera, błąd 429 jest błędem po stronie klienta — serwer działa poprawnie, ale chroni się przed zbyt dużą liczbą żądań.

Jak działa rate limiting?

Rate limiting to technika, której serwery używają do kontrolowania liczby żądań, jakie klient może wykonać w określonym oknie czasowym. Po przekroczeniu limitu serwer odpowiada kodem HTTP 429.

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.

Większość API komunikuje swoje limity poprzez nagłówki odpowiedzi. Typowe nagłówki to X-RateLimit-Limit (maksymalna liczba dozwolonych żądań), X-RateLimit-Remaining (pozostałe żądania w bieżącym oknie) oraz X-RateLimit-Reset (czas resetu okna).

Zrozumienie, jakiego algorytmu używa dana usługa, pomaga zaprojektować klienta tak, aby mieścił się w limitach i unikał błędów 429.

Najczęstsze przyczyny błędu HTTP 429

Błąd 429 może być wywołany przez wiele różnych sytuacji. Oto najczęstsze przyczyny, pogrupowane według tego, kogo dotyczą:

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

Jeśli widzisz błąd 429 podczas przeglądania strony internetowej, 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, a nie blokuje na stałe.

Odczekaj od 30 sekund do kilku minut, a następnie spróbuj ponownie. Większość limitów resetuje się w ciągu 1–5 minut. Jeśli strona nadal pokazuje 429, poczekaj dłużej — niektóre serwisy stosują limity godzinowe lub dzienne.

Nie odświeżaj strony wielokrotnie. Każde odświeżenie wysyła kolejne żądanie i może wydłużyć okres ograniczenia.

2. Wyczyść pamięć podręczną i ciasteczka przeglądarki

Czasami dane w pamięci podręcznej lub ciasteczka mogą powodować rate limiting. Ich wyczyszczenie może pomóc:

• Chrome: Naciśnij Ctrl+Shift+Delete (Windows) lub Cmd+Shift+Delete (Mac) → zaznacz "Pliki cookie" i "Obrazy w pamięci podręcznej" → kliknij "Wyczyść dane"

• Firefox: Naciśnij Ctrl+Shift+Delete → zaznacz "Pamięć podręczna" i "Ciasteczka" → kliknij "Wyczyść teraz"

• Edge: Naciśnij Ctrl+Shift+Delete → zaznacz "Pliki cookie" i "Dane w pamięci podręcznej" → kliknij "Wyczyść teraz"

• Safari: Przejdź do Safari → Ustawienia → Prywatność → Zarządzaj danymi witryn → Usuń wszystko

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, prawdopodobnie współdzielisz adres IP z setkami innych użytkowników. Gdy ich łączna liczba żądań przekroczy limit serwera, wszyscy na tym IP zostają zablokowani.

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

Jeśli potrzebujesz VPN-a, spróbuj przełączyć się na inną lokalizację serwera, aby uzyskać nowy adres IP.

4. Wyłącz rozszerzenia przeglądarki

Niektóre rozszerzenia przeglądarki wysyłają żądania w tle bez Twojej wiedzy. Blokery reklam, narzędzia do porównywania cen, rozszerzenia SEO i wtyczki automatycznego odświeżania mogą generować dodatkowe żądania, które uruchamiają rate limiting.

Aby to sprawdzić, otwórz stronę w oknie incognito/prywatnym (które domyślnie wyłącza większość rozszerzeń). Jeśli błąd 429 zniknie, winne jest jedno z Twoich rozszerzeń.

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

5. Spróbuj innej sieci

Jeśli nic innego nie pomoże, serwer może ograniczać konkretnie Twój adres IP. Spróbuj:

Przełącz się z Wi-Fi na dane komórkowe (da Ci to inny adres IP). Odwiedź stronę z zupełnie innej sieci. Jeśli jesteś w sieci firmowej lub szkolnej, spróbuj z domu — duże sieci współdzielą jeden publiczny adres IP.

Możesz sprawdzić swój aktualny adres IP za pomocą naszego narzędzia Jaki jest mój IP, aby potwierdzić, że się zmienił.

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

Jeśli budujesz aplikację korzystającą z API, błąd 429 oznacza, że Twój kod wysyła żądania zbyt szybko. Oto jak sobie z tym prawidłowo poradzić.

1. Zastosuj wykładnicze opóźnianie (Exponential Backoff)

Wykładnicze opóźnianie to standardowa branżowa strategia ponawiania prób. Zamiast ponawiać żądanie natychmiast po otrzymaniu 429, stopniowo zwiększasz czas oczekiwania między próbami:

Pierwsza próba: czekaj 1 sekundę. Druga próba: czekaj 2 sekundy. Trzecia próba: czekaj 4 sekundy. Czwarta próba: czekaj 8 sekund. I tak dalej.

Oto podstawowa implementacja w JavaScript:

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    const response = await fetch(url, options);
    
    if (response.status !== 429) return response;
    
    // Check Retry-After header first
    const retryAfter = response.headers.get('Retry-After');
    const delay = retryAfter
      ? parseInt(retryAfter) * 1000
      : Math.pow(2, attempt) * 1000; // Exponential backoff
    
    console.log(`Rate limited. Retrying in ${delay / 1000}s...`);
    await new Promise(resolve => setTimeout(resolve, delay));
  }
  throw new Error('Max retries exceeded');
}

Dodaj jitter (losowe wahanie) do opóźnienia, aby zapobiec sytuacji, w której wielu klientów ponawia próby dokładnie w tym samym momencie. Zamień obliczanie opóźnienia na Math.pow(2, attempt) * 1000 + Math.random() * 1000.

2. Respektuj nagłówek Retry-After

Gdy serwer zwraca odpowiedź 429, często dołącza nagłówek Retry-After, który informuje dokładnie, jak długo czekać. Nagłówek ten może zawierać liczbę sekund lub datę HTTP:

Retry-After: 60 oznacza czekanie 60 sekund. Retry-After: Thu, 06 Mar 2026 12:00:00 GMT oznacza czekanie do określonego momentu.

Zawsze sprawdzaj ten nagłówek, zanim zastosujesz własną logikę opóźniania. Serwer wie lepiej niż Twój kod, jak długo powinieneś czekać.

import requests
import time

def make_request(url):
    response = requests.get(url)
    
    if response.status_code == 429:
        retry_after = response.headers.get('Retry-After', '5')
        wait_time = int(retry_after)
        print(f"Rate limited. Waiting {wait_time} seconds...")
        time.sleep(wait_time)
        return make_request(url)  # Retry after waiting
    
    return response

3. Cachuj odpowiedzi API

Jeśli Twoja aplikacja wykonuje te same zapytania API wielokrotnie, cachuj odpowiedzi 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 odczytywanych danych. Ustaw rozsądny TTL (czas życia) w zależności od częstotliwości zmian danych.

Na przykład, jeśli sprawdzasz rekordy DNS dla domeny, wyniki prawdopodobnie 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);
  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 zapytań 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 szacunkową liczbę żądań. Usługi takie jak Google APIs, Twitter API i GitHub API mają procedury wnioskowania o podwyższone limity.

Niektóre API oferują również endpointy masowe (bulk), które pozwalają pobrać wiele zasobów w jednym żądaniu, zmniejszając łączną liczbę zapytań.

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

Jeśli Twoi użytkownicy lub konsumenci API otrzymują błędy 429, problem leży w konfiguracji serwera. Oto jak go zdiagnozować i naprawić.

1. Dostosuj limity żądań

Jeśli uprawnieni użytkownicy napotykają błędy 429, Twoje limity mogą być zbyt restrykcyjne. Przejrzyj je i dostosuj.

W Nginx moduł rate limitingu (ngx_http_limit_req_module) kontroluje częstotliwość żądań:

# 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/ {
        # Allow bursts of 20, no delay for first 10
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Parametr burst jest kluczowy — pozwala na krótkie skoki ruchu bez wywoływania błędu 429. Bez niego nawet normalne wzorce przeglądania mogą trafić w limit.

W Apache użyj mod_ratelimit lub mod_evasive. W Node.js skorzystaj z pakietów takich jak express-rate-limit.

2. Dodaj zaufane adresy IP do białej listy

Jeśli określoni klienci (usługi monitoringu, procesory płatności, Twoje własne mikroserwisy) są ograniczani, dodaj ich adresy IP do białej listy.

W Nginx możesz użyć mapy do pominięcia rate limitingu dla zaufanych adresów IP:

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;

Dodaj też do białej listy boty wyszukiwarek (Googlebot, Bingbot), jeśli są ograniczane — ich blokowanie szkodzi Twojemu SEO. Możesz zweryfikować tożsamość botów za pomocą zapytań odwrotnego DNS.

3. Sprawdź ustawienia WAF i CDN

Jeśli korzystasz z Cloudflare, AWS WAF, Sucuri lub innej usługi bezpieczeństwa, to ich reguły rate limitingu mogą być źródłem błędów 429 — nie Twój serwer źródłowy.

W Cloudflare sprawdź Security → WAF → Rate Limiting Rules. Możesz zobaczyć, które reguły się uruchamiają, i dostosować progi. Tryb "I'm Under Attack" w Cloudflare jest szczególnie agresywny.

W AWS WAF sprawdź reguły ACL pod kątem reguł opartych na częstotliwości. Minimalny próg to 100 żądań na 5 minut — upewnij się, że jest odpowiedni dla Twojego poziomu ruchu.

Przeanalizuj statystyki CDN, aby odróżnić uprawniony ruch od ruchu botów, zanim zmienisz limity.

4. Zoptymalizuj wydajność serwera

Czasami błędy 429 pojawiają się, ponieważ serwer nie radzi sobie z obciążeniem, a rate limiting włącza się jako mechanizm 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 Nagłówki HTTP, aby sprawdzić, czy nagłówki cachowania są prawidłowo ustawione.

Błąd 429 a inne kody HTTP

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

Kluczowa różnica: 429 jest tymczasowy i celowy. Serwer jest zdrowy — aktywnie decyduje się odrzucić Twoje żądanie, aby się chronić. Inne błędy 5xx oznaczają, że coś faktycznie nie działa.

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ń.