HTTP 429 Too Many Requests: odczekaj i ponów poprawnie
HTTP 429 Too Many Requests
HTTP 429 Too Many Requests: Retry-After i backoff | We.Inc
Co oznacza status 429, jak odczytać Retry-After oraz kod ponawiania z wykładniczym backoffem i jitterem. Zaplanuj własny harmonogram ponowień w kalkulatorze.
Odpowiedź 429 oznacza, że serwer ogranicza Twoje żądania: ten klient wysłał w danym oknie czasowym więcej żądań, niż serwer pozwala. Przestań wysyłać na jakiś czas. Jeśli odpowiedź zawiera nagłówek Retry-After, odczekaj tyle, ile podaje; jeśli nie, ponawiaj z wykładniczym backoffem i losowym jitterem, aby wielu klientów nie ponawiało żądań jednocześnie.
Jak odczytać odpowiedź 429
Element
Co oznacza
Co powinien zrobić Twój klient
Status 429
Zbyt wiele żądań w określonym czasie
Wstrzymaj tego klienta, nie zasypuj serwera
Retry-After: 120
Odczekaj 120 sekund (forma opóźnienia w sekundach)
Odczekaj co najmniej tyle
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
Odczekaj do tej chwili (forma HTTP-date)
Odejmij bieżący czas, a potem odczekaj
Brak Retry-After
Serwer nie dał żadnej wskazówki
Wycofuj się wykładniczo z jitterem
Cache
Odpowiedź 429 nie może być zapisana w cache
Nigdy nie serwuj później zapisanej odpowiedzi 429
Ustaw pierwsze opóźnienie, górny limit i liczbę dozwolonych ponowień, a następnie wybierz rodzaj jittera. Kalkulator pokazuje zakres oczekiwania dla każdej próby i łączny czas w najgorszym przypadku, więc widzisz, czy Twój klient nie podda się, zanim okno serwera się zresetuje.
Wpisz opóźnienie bazowe w milisekundach, czyli opóźnienie przed pierwszym ponowieniem.
Wpisz limit, czyli najdłuższy możliwy pojedynczy czas oczekiwania.
Wybierz liczbę dozwolonych ponowień i rodzaj jittera.
Przeczytaj zakresy dla każdej próby i sumę, a potem skopiuj pasujący kod poniżej.
Zawsze, gdy serwer wysyła Retry-After, stosuj go zamiast własnego harmonogramu. Serwer wie, kiedy resetuje się jego okno, a Ty nie.
Ponawiaj tylko żądania, które można bezpiecznie powtórzyć. Ponowiony POST płatności bez klucza idempotencji może obciążyć kartę dwa razy.
Ograniczaj zarówno liczbę ponowień, jak i opóźnienie, a gdy się wyczerpią, pokaż czytelny błąd.
Gdy kontrolujesz serwer, zwracaj 429 z Retry-After zamiast po cichu odrzucać lub spowalniać żądania, aby dobrze napisani klienci mogli się dostosować.
Najczęściej zadawane pytania
Czy 429 to błąd klienta czy serwera?
Należy do klasy 4xx, więc opisuje zachowanie klienta: zbyt wiele żądań. Na serwerze nic nie jest zepsute. Rozwiązaniem jest wysyłanie mniejszej liczby żądań lub rozłożenie ich w czasie.
Co zawiera Retry-After?
Albo liczbę sekund oczekiwania, na przykład 120, albo datę HTTP, po której możesz spróbować ponownie. Twój klient powinien obsługiwać obie formy.
Po co dodawać jitter do wykładniczego backoffu?
Bez jittera każdy klient, któremu żądanie nie powiodło się w tej samej chwili, ponawia je znowu w tej samej chwili, co odtwarza szczyt obciążenia. Losowe oczekiwanie w obrębie każdego okna rozkłada ponowienia w czasie.
Dlaczego mój limit w nginx zwraca 503 zamiast 429?
Moduł limit_req odrzuca żądania z kodem 503, dopóki tego nie zmienisz. Dodaj limit_req_status 429; obok linii limit_req, aby klienci widzieli dokładniejszy kod.
Czy CDN może zapisać odpowiedź 429 w cache?
Nie może. RFC 6585 mówi, że odpowiedzi z kodem statusu 429 nie mogą być przechowywane przez cache, więc każdy klient dostaje świeżą odpowiedź po zniesieniu limitu.
Kto wysyła 429 i dlaczego
API, formularze logowania i endpointy wyszukiwania liczą żądania na użytkownika, na klucz lub na adres IP i odrzucają nadmiarowe. Specyfikacja zostawia sposób liczenia serwerowi, więc jedno API może limitować na minutę, a inne na dzień.
Odpowiedź powinna wyjaśniać limit w treści i może dodać Retry-After, aby powiedzieć, jak długo czekać.
Trzy rodzaje backoffu w kalkulatorze
Zwykły wykładniczy backoff podwaja oczekiwanie za każdym razem aż do limitu: min(cap, base * 2^attempt). Full jitter wybiera losowe oczekiwanie między zerem a tą liczbą. Equal jitter zachowuje połowę tej wartości, a drugą połowę losuje, co gwarantuje pewną minimalną przerwę.
Full jitter najlepiej rozkłada obciążenie, dlatego jest rozsądnym wyborem domyślnym. Equal jitter pasuje do klientów, którzy nigdy nie mogą ponawiać natychmiast.
Kod klienta, który respektuje 429
fetch z Retry-After i full jitter
Odczytuje obie formy Retry-After, w razie ich braku przechodzi na full jitter i zatrzymuje się po ustalonej liczbie ponowień.
Wysyłanie 429 z własnego serwera
nginx: limit na IP i odpowiedź 429
limit_req domyślnie odrzuca z kodem 503; limit_req_status zmienia go na 429.
Jak wygląda odpowiedź
Krótka treść wyjaśniająca limit i Retry-After w sekundach.
Kalkulator harmonogramu ponowień
Opóźnienie bazowe (ms)
Limit pojedynczego oczekiwania (ms)
Ponowienia
Rodzaj jittera
Full jitter
Equal jitter
Bez jittera
Oczekiwanie przed każdym ponowieniem
Ponowienie
Najkrótsze oczekiwanie
Najdłuższe oczekiwanie
Najgorszy przypadek przed rezygnacją: {v}
Użyj liczb całkowitych większych od zera, przy czym limit musi być co najmniej równy wartości bazowej.