Czym jest rate limiting, czym różnią się fixed window, sliding window, token bucket i leaky bucket, z symulatorem na żywo, statusem 429, Retry-After i przykładem Nginx.
Rate limiting ogranicza, ile żądań jeden odwiedzający, klucz lub adres IP może wysłać w danym czasie. Żądania ponad limit są odrzucane, zwykle ze statusem HTTP 429 Too Many Requests i nagłówkiem Retry-After, który mówi, kiedy spróbować ponownie. Chroni formularze logowania, formularze kontaktowe i API przed zalewem żądań i niekontrolowanymi rachunkami.
Cztery popularne algorytmy rate limitingu
Jeśli Twoja strona ma stronę logowania, formularz kontaktowy, koszyk lub API wywoływane przez inne aplikacje, ktoś w końcu zacznie je zasypywać żądaniami, przypadkiem lub celowo. Rate limiting to zasada, która określa, ile to za dużo. Poniżej możesz klikać przyciski, aby wysyłać żądania, i obserwować, jak każdy algorytm je przyjmuje lub odrzuca, a potem skopiować działającą konfigurację Nginx.
RFC 6585 definiuje 429 Too Many Requests jako status dla klienta, który wysłał zbyt wiele żądań w określonym czasie. Odpowiedź może zawierać nagłówek Retry-After, który mówi klientowi, jak długo czekać.
Domyślnie moduł limit_req odpowiada na odrzucone żądania kodem 503. Możesz zmienić go na 429 dyrektywą limit_req_status, co preferuje większość API, bo mówi wywołującemu dokładnie, co się stało.
Jeszcze nie. Pola RateLimit i RateLimit-Policy pochodzą z Internet-Draft grupy roboczej IETF, który według stanu na październik 2026 był wciąż w toku, więc niektóre usługi wysyłają zamiast nich starsze nagłówki X-RateLimit. Traktuj je jako pomocne wskazówki.
Token bucket pozwala wywołującemu wydać zaoszczędzone tokeny w serii, a potem ustala się na tempie uzupełniania. Leaky bucket wygładza ruch do stałego odpływu. Nginx opisuje swój moduł limit_req jako wykorzystujący metodę leaky bucket.
Nie. Dobrze radzi sobie z nadużyciami z kilku źródeł, ale ruch rozłożony na tysiące adresów wymaga też ochrony u Twojego hostingu lub w CDN. Rate limiting to jedna warstwa, a nie cała obrona.
Ta konfiguracja pozwala każdemu adresowi IP na 5 żądań na sekundę na ścieżce logowania, z serią 10 obsłużonych naraz, i odpowiada na nadmiarowe żądania kodem 429 zamiast domyślnego 503.
Strefa 10m przechowuje liczniki. Dokumentacja mówi, że jeden megabajt mieści około 16 tysięcy stanów po 64 bajty.
Dla jednego serwera token bucket mieści się w kilku liniach. Jeśli masz więcej niż jeden serwer, trzymaj liczniki we wspólnym magazynie.
Każdy klucz dostaje 10 tokenów, które uzupełniają się w tempie 1 na sekundę. Odrzucone wywołanie dostaje 429 i Retry-After w pełnych sekundach.
Status 429 z Retry-After wynoszącym 30 sekund.
Każdy algorytm pozwala na około 5 żądań na 5 sekund (lub kubełek 5 przesuwający się w tempie 1 na sekundę). Wysyłaj żądania, pozwól mijać czasowi i obserwuj, co przechodzi.
Algorytm
Fixed window
Sliding window
Token bucket
Leaky bucket
Wyślij 1 żądanie
Wyślij serię {n}
Czekaj 1 sekundę
Resetuj
Czas: {v} s
Przyjęte: {n}
Odrzucone z 429: {n}
Dziennik żądań
t={v}s przyjęte
t={v}s odrzucone (429)
Brak żądań. Kliknij przycisk powyżej.
Model edukacyjny z krokami co pełną sekundę. Prawdziwe limitery mierzą w milisekundach.
Zacznij za darmo · Bez karty kredytowej