Błąd 429 Too Many Requests – co oznacza i jak go naprawić?

Data publikacji: 3 listopada 2026

Strona działała jeszcze przed chwilą, ale po kilku odświeżeniach pojawia się komunikat 429 Too Many Requests. Innym razem sklep otwiera się normalnie, lecz wyszukiwarka przestaje odpowiadać, aplikacja mobilna nie pobiera danych albo integracja z API nagle zaczyna zwracać błędy. To nie musi oznaczać awarii serwera. Często jest to efekt mechanizmu, który celowo ogranicza liczbę żądań przyjmowanych od jednego użytkownika, adresu IP lub aplikacji.

Takie ograniczanie nazywa się rate limitingiem. Chroni ono serwis przed przeciążeniem, automatycznym nadużywaniem formularzy, próbami odgadywania haseł i niekontrolowanymi skryptami. Źle dobrane limity mogą jednak odcinać także prawdziwych użytkowników. W tym poradniku pokazujemy, jak rozpoznać przyczynę błędu 429, jak bezpiecznie go usunąć i jak skonfigurować ochronę, żeby nie szkodziła dostępności strony.

Kluczowe wnioski

• 429 Too Many Requests oznacza, że serwer lub usługa pośrednicząca uznała liczbę żądań za zbyt dużą w stosunku do przyjętego limitu.
• Nagłówek Retry-After, jeśli jest obecny, podpowiada, ile trzeba poczekać przed kolejną próbą. Nie każdy serwis go wysyła.
• Limit może dotyczyć adresu IP, konta, tokenu API, konkretnego adresu URL lub całej aplikacji. Sam komunikat nie wskazuje, który wariant obowiązuje.
• Wielokrotne odświeżanie strony lub automatyczne ponawianie żądań bez opóźnienia może przedłużyć problem.
• W Nginx mechanizm limit_req domyślnie zwraca 503, a nie 429. Kod 429 można ustawić dyrektywą limit_req_status 429.
• Po stronie administratora najważniejsze są logi, reguły WAF, identyfikacja prawdziwego IP klienta i testy z rzeczywistym ruchem.

Co dokładnie oznacza błąd 429?

Kod HTTP 429 Too Many Requests należy do grupy 4xx. Informuje, że klient wysłał zbyt wiele żądań w określonym czasie. Definicję tego kodu zawiera RFC 6585, sekcja 4.

Wyobraź sobie usługę, która dopuszcza 60 zapytań na minutę z jednego konta. Jeżeli skrypt spróbuje wysłać ich 200, część żądań może otrzymać odpowiedź 429. Nie oznacza to automatycznie, że dane zapytanie było niepoprawne. Serwer może po prostu odmówić jego wykonania w tej chwili.

Ograniczenia bywają bardziej złożone. Dostawca API może stosować osobny limit dla każdego klucza, serwis logowania — dla konkretnego konta, a zapora aplikacyjna — dla adresu IP. W systemach rozproszonych limity mogą być liczone w kilku warstwach jednocześnie. Dlatego dwie osoby otwierające tę samą stronę mogą otrzymać różne odpowiedzi.

Warto pamiętać, że kod 429 opisuje decyzję o ograniczeniu ruchu, a nie dowodzi sam w sobie ataku, błędu przeglądarki czy awarii hostingu.

Czym 429 różni się od 403, 502 i 503?

Te komunikaty mogą wyglądać podobnie, ale prowadzą do innych działań diagnostycznych:

Więcej o innych problemach przeczytasz w poradnikach Błąd 403 Forbidden – co oznacza i jak go naprawić? oraz Błąd 502 Bad Gateway – co oznacza i jak go naprawić?.

Dlaczego strona zwraca 429 Too Many Requests?

Najczęściej przyczyną jest jedna z kilku sytuacji. Zdarza się też, że kilka z nich występuje równocześnie.

Zbyt częste odświeżanie lub automatyczne zapytania

Pojedyncze odświeżenie strony może uruchomić wiele żądań: o dokument HTML, pliki JavaScript, dane z API, obrazy, powiadomienia i informacje o zalogowanym użytkowniku. Nie wszystkie serwisy liczą je razem, ale błędnie ustawiona reguła może obejmować więcej adresów, niż zamierzał administrator.

Szczególnie problematyczny jest skrypt, który po otrzymaniu błędu natychmiast ponawia zapytanie. Powstaje pętla: więcej żądań powoduje kolejne blokady, a blokady wywołują jeszcze więcej prób.

Wspólny adres IP

W biurze, hotelu, sieci komórkowej lub za VPN wielu użytkowników może wychodzić do internetu pod tym samym publicznym adresem IP. Jeśli limit jest przypisany wyłącznie do IP, działania jednej osoby lub automatu mogą wpływać na pozostałych. Nie musi to oznaczać, że komputer użytkownika wykonuje podejrzane operacje.

Zabezpieczenia logowania i formularzy

Mechanizmy ochrony przed atakami na hasła i spamem często ograniczają liczbę prób logowania, resetowania hasła, wysyłania formularzy albo wyszukiwania. To pożyteczne zabezpieczenie, ale nieprawidłowo skonfigurowane może blokować użytkowników, którzy popełnili kilka literówek lub pracują ze wspólnej sieci.

Limity zewnętrznego API

Integracja pobierająca kursy walut, dane zamówień czy wyniki wyszukiwania może mieć limit na minutę, godzinę lub dzień. Po jego przekroczeniu API może zwrócić 429. Czasami samo odczekanie wystarcza, a czasami konieczna jest zmiana harmonogramu, ograniczenie liczby wywołań albo zwiększenie przydzielonego limitu zgodnie z zasadami dostawcy.

Reguła CDN, WAF albo wtyczki

Blokadę może wygenerować nie tylko aplikacja. Czasem odpowiada za nią Cloudflare, inny dostawca CDN, reverse proxy, moduł bezpieczeństwa hostingu albo wtyczka WordPressa. Jeśli problem zaczął się po zmianie reguł ochronnych, to ważny trop, ale nie powód, by od razu wyłączać całą zaporę.

Co zrobić, jeśli jesteś zwykłym użytkownikiem strony?

Zacznij od najprostszej czynności: przestań odświeżać stronę i odczekaj kilka minut. Jeżeli komunikat zawiera informację o czasie blokady, zastosuj się do niej. Ponawianie żądań co sekundę zwykle nie przyspieszy odblokowania.

Następnie sprawdź, czy problem dotyczy całej witryny, czy tylko jednej czynności, np. wyszukiwania lub logowania. Jeżeli inne podstrony działają, limit może być nałożony na konkretną funkcję. Zamknij zbędne karty, wstrzymaj automatyczne odświeżanie i sprawdź, czy jakieś rozszerzenie przeglądarki nie wykonuje zapytań w tle.

Jeśli korzystasz z VPN, spróbuj — o ile jest to zgodne z zasadami dostępu do serwisu — sprawdzić działanie strony bez niego. Gdy problem dotyczy tylko sieci firmowej, możliwe, że wiele osób korzysta z tego samego adresu IP. Nie traktuj jednak zmiany IP jako sposobu na obchodzenie celowo nałożonych limitów usługi.

Tryb prywatny może pomóc ustalić, czy problem zależy od sesji lub dodatków, ale nie usuwa limitu przypisanego do publicznego IP. Podobnie czyszczenie plików cookie nie jest uniwersalnym rozwiązaniem.

Jeśli błąd powraca mimo niewielkiej liczby prób, zgłoś go administratorowi. Podaj dokładny adres URL, godzinę wystąpienia, wykonywaną czynność i zrzut komunikatu. Nie przesyłaj haseł, tokenów API ani pełnych nagłówków autoryzacji.

Jak sprawdzić kod 429 w narzędziach przeglądarki?

W Chrome, Edge lub Firefox otwórz narzędzia deweloperskie (F12), przejdź do zakładki Network / Sieć i odtwórz problem tylko raz, bez wykonywania serii szybkich prób. Następnie znajdź żądanie oznaczone kodem 429.

Sprawdź:

1. Request URL — który dokładnie adres zwraca błąd? Może to być /api/search, a nie strona główna.
2. Request Method — czy problem dotyczy GET, POST, czy innej metody?
3. Response Headers — czy jest nagłówek Retry-After lub nagłówki informujące o limicie?
4. Response / Preview — czy odpowiedź zawiera opis limitu albo identyfikator błędu?
5. Timing — czy żądanie zostało odrzucone od razu, czy po dłuższym oczekiwaniu?

Zwróć uwagę na powtarzające się identyczne żądania. Jeśli aplikacja wysyła kilkadziesiąt zapytań po jednym kliknięciu, problem może tkwić w jej kodzie. Pamiętaj też, że dane z zakładki Network mogą zawierać ciasteczka i tokeny — przed udostępnieniem pliku HAR usuń informacje wrażliwe.

Jak odczytać 429 i Retry-After za pomocą curl?

W terminalu możesz wykonać pojedyncze żądanie diagnostyczne:

curl -sS -D - -o /dev/null https://example.com/api/status

Parametr -D - wypisuje nagłówki odpowiedzi, a -o /dev/null pomija treść. Dzięki temu łatwo zobaczyć kod HTTP i dodatkowe informacje. Używaj własnego adresu testowego lub zasobu, do którego masz prawo dostępu. Nie uruchamiaj pętli wysyłających setki zapytań do obcej witryny.

Przykładowa odpowiedź:

HTTP/2 429
content-type: application/json
retry-after: 120

W tym przykładzie serwer sugeruje, aby odczekać 120 sekund przed kolejną próbą. Retry-After może mieć też postać daty HTTP, np. Wed, 04 Nov 2026 10:00:00 GMT. Wtedy ponowienie żądania powinno nastąpić nie wcześniej niż we wskazanym momencie.

Nagłówek jest opcjonalny. Jego brak nie oznacza, że można od razu próbować ponownie. Niektóre API zwracają własne pola dotyczące liczby pozostałych żądań i chwili resetu limitu. Ich nazwy i znaczenie trzeba sprawdzić w dokumentacji konkretnej usługi. Więcej informacji zawiera dokumentacja kodu 429 w MDN.

Co zrobić, gdy błąd 429 występuje w aplikacji korzystającej z API?

Najważniejsza zasada brzmi: nie ponawiaj każdego nieudanego żądania natychmiast. Klient powinien rozróżniać chwilowe ograniczenie tempa od błędu, którego kolejne próby nie naprawią, np. wyczerpania dziennego limitu lub środków na koncie API.

Praktyczna strategia wygląda następująco:

1. Odczytaj kod odpowiedzi i Retry-After, jeśli został wysłany.
2. Jeżeli serwer wskazuje czas oczekiwania, zaplanuj kolejną próbę nie wcześniej niż po tym czasie.
3. Gdy wskazówki brak, stosuj exponential backoff: np. około 1, 2, 4 i 8 sekund między kolejnymi próbami, z niewielką losową zmianą (jitter).
4. Ogranicz maksymalną liczbę prób. Jeśli problem trwa, zgłoś go i odłóż zadanie do kolejki zamiast blokować aplikację bez końca.
5. Zmniejsz równoległość, łącz zapytania tam, gdzie API to umożliwia, i buforuj dane, których nie trzeba pobierać za każdym razem.
6. Osobno traktuj operacje zmieniające dane. Nie ponawiaj bezmyślnie żądań POST wykonujących płatność czy tworzących zamówienie — najpierw sprawdź zasady idempotencji danego API.

Przykład: integracja synchronizuje 300 produktów i wysyła jednocześnie 300 zapytań. Zamiast zwiększać limit za wszelką cenę, może lepiej przetwarzać je w małych partiach i zapamiętywać, które rekordy już zsynchronizowano. Taka zmiana często zmniejsza zarówno liczbę błędów, jak i obciążenie systemu.

Wskazówki dotyczące zachowania klientów API opisuje także dokumentacja Microsoft Learn.

Jak administrator powinien diagnozować 429?

Jeśli odpowiadasz za serwis, zacznij od ustalenia, która warstwa zwraca ten kod. Przejrzyj logi aplikacji, serwera WWW, reverse proxy oraz ewentualnego CDN lub WAF. Zapisz godzinę, ścieżkę żądania, kod, identyfikator reguły i — tam, gdzie jest to uzasadnione — identyfikator użytkownika lub klucza API. Dane osobowe i adresy IP przetwarzaj zgodnie z zasadami prywatności.

Szukaj powtarzalnych wzorców. Czy 429 dotyczy tylko /login? Czy występuje po wdrożeniu nowego frontendu? Czy wiele żądań pochodzi z jednego biurowego IP? Czy skrypt uruchamiany przez cron nie zaczął działać częściej? Czy odrzucone żądania rzeczywiście przekraczają ustalony próg?

Dobrą praktyką jest porównanie liczby poprawnych odpowiedzi i błędów w czasie. Sam wzrost 429 nie zawsze jest zły — może oznaczać skuteczną ochronę przed automatem. Problem pojawia się wtedy, gdy blokowane są zwykłe sesje użytkowników, płatności, logowanie albo legalne integracje.

Sprawdź prawdziwy adres IP za CDN lub proxy

Jeśli aplikacja działa za Cloudflare, load balancerem albo innym reverse proxy, serwer źródłowy może widzieć adres pośrednika zamiast użytkownika. Wtedy limit oparty o IP może niesłusznie traktować wielu odwiedzających jak jednego klienta.

Poprawna konfiguracja wymaga jawnego zaufania do adresów własnych, znanych serwerów proxy i odpowiedniego nagłówka przekazującego IP. Nie należy bezwarunkowo ufać dowolnemu X-Forwarded-For od klienta, ponieważ można go sfałszować. Zanim zmienisz reguły, sprawdź łańcuch proxy oraz sposób identyfikacji klienta w całej infrastrukturze.

Jak skonfigurować ograniczanie żądań w Nginx?

Nginx udostępnia moduł ngx_http_limit_req_module, który pozwala ograniczać tempo żądań według wybranego klucza. Poniższy przykład dotyczy testowej konfiguracji API i zakłada, że $binary_remote_addr rzeczywiście odpowiada adresowi klienta:

http {
    limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=5r/s;

    server {
        listen 443 ssl;
        server_name example.com;

        # Fragment istniejącej konfiguracji; pominięto TLS i obsługę aplikacji.
        location /api/ {
            limit_req zone=api_per_ip burst=10 nodelay;
            limit_req_status 429;
            proxy_pass http://backend;
        }
    }
}

rate=5r/s określa średnie tempo pięciu żądań na sekundę dla jednego klucza, a burst=10 pozwala obsłużyć krótkie wzrosty ruchu zgodnie z algorytmem modułu. nodelay oznacza, że żądania mieszczące się w dopuszczalnym krótkim wzroście nie będą sztucznie opóźniane. Przekroczenie dopuszczalnego zakresu prowadzi do odrzucenia żądania.

Ważne: standardowy limit_req zwraca przy odrzuceniu kod 503, dopóki nie ustawisz limit_req_status 429. Ta różnica jest opisana w oficjalnej dokumentacji Nginx.

Nie kopiuj tych wartości wprost do produkcji. API obsługujące interaktywne wyszukiwanie, logowanie i import danych ma różne profile ruchu. Zbyt niski próg może sprawić, że normalne działanie aplikacji zostanie uznane za nadużycie. Jeśli konfiguracja zawiera już dyrektywy limit_req, uwzględnij też zasady ich dziedziczenia i zakres poszczególnych bloków.

Najpierw testuj, później blokuj

W obsługiwanych wersjach Nginx możesz użyć limit_req_dry_run on;, aby rejestrować przekroczenia limitu bez odrzucania żądań. To dobry sposób na ocenę, czy próg nie jest zbyt restrykcyjny. Następnie sprawdź konfigurację poleceniem nginx -t, a po pozytywnym wyniku zastosuj kontrolowane przeładowanie usługi.

Przed wdrożeniem zaplanuj też sposób wycofania zmiany. Przetestuj logowanie, wyszukiwarkę, formularze, operacje API oraz ruch z sieci współdzielących jeden adres IP. Warto obserwować nie tylko liczbę odrzuceń, ale również czasy odpowiedzi i obciążenie aplikacji.

Jak sprawdzić reguły rate limitingu w Cloudflare?

Jeśli strona korzysta z Cloudflare, sprawdź zdarzenia bezpieczeństwa oraz reguły ograniczania ruchu dla danej domeny. Ustal, czy blokada została wywołana przez regułę WAF, mechanizm rate limitingu czy sam serwer źródłowy. Nie każdy kod 429 widoczny za Cloudflare musi pochodzić od Cloudflare.

Zwróć uwagę na ścieżkę URL, okres liczenia żądań, sposób grupowania klientów i czas obowiązywania blokady. Szczególnie ostrożnie traktuj reguły obejmujące wszystkie adresy strony. Jeśli blokujesz ruch na poziomie całej domeny, możesz niechcący objąć limitem również obrazy, pliki CSS i żądania API wykonywane przez jedną odsłonę.

W miarę możliwości zacznij od obserwowania dopasowań reguły, a nie od natychmiastowego blokowania. Następnie porównaj ruch prawidłowy z podejrzanym i stopniowo dopasuj próg. Dostępne opcje zależą od planu i konfiguracji usługi. Pomocne są dokumentacja reguł Cloudflare oraz opis błędu 429.

Co sprawdzić w WordPressie?

W WordPressie przyczyną 429 mogą być zabezpieczenia logowania, wtyczki antyspamowe, limity hostingu, zapora przed stroną albo zewnętrzna integracja. Najpierw ustal, kto rzeczywiście wysłał odpowiedź. Jeżeli błąd występuje tylko przy logowaniu, sprawdź wtyczki bezpieczeństwa i ich dzienniki. Jeżeli problem dotyczy całej witryny, zweryfikuj również reguły hostingu, CDN i serwera WWW.

Nie wyłączaj wszystkich zabezpieczeń na działającej stronie tylko po to, żeby komunikat zniknął. Najpierw zapisz konfigurację, sprawdź ostatnie zmiany i wykonaj test na środowisku stagingowym. Jeśli problem pojawił się po aktualizacji, możesz porównać zachowanie strony przed zmianą i po niej. Pomocny będzie też poradnik Jak naprawić stronę na WordPressie – sprawdzone sposoby.

Zwróć uwagę na zadania cykliczne, importy i wtyczki pobierające dane z zewnętrznych API. To one mogą otrzymywać 429 od dostawcy usługi, nawet jeśli sama strona internetowa nadal działa poprawnie.

Czy błąd 429 może zaszkodzić SEO i dostępności strony?

Jeśli 429 występuje tylko sporadycznie przy wyraźnie nadużywającym ruchu, jest normalnym elementem ochrony. Problem zaczyna się, gdy ograniczenie obejmuje prawdziwych odwiedzających, roboty wyszukiwarek lub kluczowe zasoby strony. Użytkownicy nie mogą wtedy wykonać ważnych czynności, a automatyczne systemy mogą mieć trudności z pobieraniem treści.

Nie istnieje prosta zasada, że pojedynczy 429 automatycznie obniża pozycję strony w wyszukiwarce. Długotrwałe lub masowe blokowanie legalnego ruchu może jednak pogarszać dostępność i utrudniać indeksowanie. Dlatego przed zaostrzeniem limitów przeanalizuj logi i sprawdź, które ścieżki faktycznie wymagają ochrony.

Z punktu widzenia HTTP odpowiedzi 429 nie powinny być zapisywane przez cache — tak stanowi RFC 6585. Jeśli widzisz długo utrzymującą się stronę błędu mimo ustania ograniczenia, sprawdź również zachowanie pośredników, niestandardowych mechanizmów cache i aplikacji.

Jak monitorować problem, żeby zauważyć go wcześniej?

Sam test dostępności strony głównej może nie wykryć błędu 429 na formularzu, wyszukiwarce lub API. Warto monitorować konkretne funkcje i rozdzielać sygnały: niedostępność całej witryny, wzrost błędów 4xx, problemy z logowaniem oraz niepowodzenia integracji.

Dla serwisów produkcyjnych przydatne są wykresy liczby odpowiedzi 429 według adresu URL i źródła blokady, a także alerty o nagłym wzroście błędów w stosunku do zwykłego ruchu. Monitoruj również liczbę żądań przychodzących i odrzucanych, aby odróżnić atak od zbyt restrykcyjnej konfiguracji.

Automatyczny monitoring, np. Ping.pl, może pomóc wykrywać niedostępność ważnych adresów i problemy z działaniem procesów. Testy należy jednak ustawić z rozsądną częstotliwością: sam monitor nie powinien generować ruchu, który przekracza limit chronionego endpointu. Więcej na ten temat opisujemy w artykule Monitoring dostępności strony – jak szybko wykrywać awarie?.

Lista kontrolna po naprawie błędu 429

Po zmianie konfiguracji upewnij się, że:

• zwykły użytkownik może otworzyć stronę, zalogować się i wykonać najważniejsze czynności;
• API respektuje limity, a klient nie tworzy pętli natychmiastowych ponowień;
• żądania z sieci firmowej i komórkowej nie są niepotrzebnie blokowane;
• adres IP klienta jest prawidłowo identyfikowany za zaufanym proxy;
• logi pokazują, która reguła odrzuca ruch i z jakiego powodu;
• mechanizmy ochrony przed nadużyciami nadal działają;
• testy nie ograniczają się do strony głównej, ale obejmują również formularze i API;
• masz możliwość szybkiego wycofania zmiany, jeśli pojawią się fałszywe blokady.

Podsumowanie

429 Too Many Requests nie oznacza automatycznie, że serwer jest zepsuty. Najczęściej informuje, że określony klient przekroczył limit ruchu. Dla użytkownika pierwszym krokiem powinno być odczekanie i zaprzestanie wielokrotnych prób. Dla programisty — poprawna obsługa Retry-After, ograniczenie liczby zapytań i bezpieczne ponawianie operacji. Dla administratora — analiza logów, reguł CDN i WAF oraz konfiguracji serwera.

Najlepsze ograniczenia nie są ani skrajnie surowe, ani całkowicie wyłączone. Powinny zatrzymywać nadużycia, a jednocześnie pozwalać prawdziwym użytkownikom bez przeszkód korzystać z witryny. Dlatego każdą zmianę limitów warto najpierw zmierzyć, przetestować i monitorować po wdrożeniu.