Ograniczanie szybkości w NGINX jest kluczową funkcją kontrolowania ilości ruchu obsługiwanego przez Twój serwer. Pomaga chronić Twój serwer przed przeciążeniem zbyt dużą liczbą żądań w krótkim czasie, które mogą powodować złośliwe ataki, takie jak DDoS lub duże skoki ruchu. Wdrożenie ograniczania szybkości gwarantuje, że Twoje zasoby będą wykorzystywane efektywnie, a prawowici użytkownicy będą mogli uzyskać dostęp do Twoich usług bez zakłóceń.
Ten przewodnik pokaże, jak skonfigurować ograniczanie szybkości w NGINX, dostarczając jasnych instrukcji, które pomogą Ci skutecznie zarządzać i kontrolować ruch przychodzący.
Zrozumienie dyrektyw dotyczących limitów stawek w NGINX
Kluczowe dyrektywy NGINX dotyczące ograniczeń stawek
NGINX konfiguruje ograniczanie szybkości za pomocą określonych dyrektyw, z których każda pełni unikalną funkcję:
- limit_req_zone: Dyrektywa limit_req_zone w NGINX konfiguruje strefę pamięci współdzielonej do przechowywania informacji ograniczających szybkość. Umieszczony w kontekście http określa dopuszczalną liczbę żądań, skutecznie wyznaczając punkt odniesienia dla limitów szybkości.
- limit_req: Dyrektywa limit_req, wykorzystywana w kontekście lokalizacji, wymusza limit szybkości ustawiony przez limit_req_zone. Stosuje te ograniczenia do określonych lokalizacji lub adresów URL, kontrolując w ten sposób częstotliwość dostępu do tych punktów końcowych.
- limit_req_status: Umieszczona w kontekście lokalizacji dyrektywa limit_req_status określa kod stanu HTTP zwracany, gdy liczba żądań przekracza limit. Ten mechanizm informacji zwrotnej ma kluczowe znaczenie dla informowania użytkowników lub zautomatyzowanych systemów, gdy przekraczają dozwoloną częstotliwość żądań.
Tworzenie konfiguracji ograniczającej szybkość
Aby zaimplementować ograniczanie szybkości w NGINX, wstaw odpowiednie dyrektywy do pliku konfiguracyjnego NGINX. Rozważmy ten podstawowy przykład:
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
server {
...
location / {
limit_req zone=mylimit burst=10;
...
}
}
}W tej konfiguracji dyrektywa limit_req_zone ustanawia strefę pamięci o nazwie „mylimit”, zezwalającą na 5 żądań na sekundę (5r/s) z każdego adresu IP klienta ($binary_remote_addr). Dyrektywa limit_req następnie stosuje ten limit szybkości do lokalizacji głównej (/), z przepustowością 10 żądań, oferując równowagę pomiędzy ścisłym ograniczaniem szybkości i elastycznością w przypadku uzasadnionych skoków ruchu.
Limit szybkości w NGINX: praktyczne przykłady
Podstawowa konfiguracja ograniczania szybkości
W tej sekcji omówiona zostanie podstawowa konfiguracja ograniczająca szybkość zastosowana na całym serwerze w NGINX. Celem jest ograniczenie żądań użytkowników do serwera, zapewnienie stabilnej wydajności i ograniczenie ryzyka przeciążenia.
Przykład: Limit szybkości obowiązujący na całym serwerze
Rozważ następującą konfigurację NGINX:
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
server {
listen 80;
server_name example.com;
location / {
limit_req zone=mylimit burst=5;
proxy_pass http://backend;
}
}
}
Ta konfiguracja ustawia limit 2 żądań na sekundę dla każdego klienta, zgodnie z jego adresem IP ($binary_remote_addr). Rozłóżmy kluczowe elementy:
- limit_req_zone: Definiuje strefę pamięci (mylimit) do przechowywania stanów limitów szybkości o rozmiarze 10 megabajtów. Ustawia limit szybkości na 2 żądania na sekundę (2r/s).
- blok serwera: Nasłuchuje na porcie 80 ruchu przychodzącego do example.com.
- blok lokalizacyjny: stosuje limit szybkości do głównego adresu URL (/). Parametr serii umożliwia serię maksymalnie 5 żądań, zapewniając elastyczność w przypadku krótkich skoków ruchu. Dyrektywa proxy_pass przekazuje żądanie do określonego serwera zaplecza.
- Parametr wybuchu: Ustawienie Burst=5 w dyrektywie limit_req pozwala na krótkotrwały wzrost liczby żądań, do 5 dodatkowych żądań powyżej ustawionej szybkości. Ta funkcja ma kluczowe znaczenie w obsłudze nagłego, uzasadnionego wzrostu ruchu bez wpływu na wygodę użytkownika.
- Przepustka proxy: Przepustka_proxy http://backend; dyrektywa przekazuje ruch do serwera zaplecza. Jest to powszechnie stosowane w scenariuszach równoważenia obciążenia lub gdy NGINX działa jako odwrotne proxy.
Zaawansowane przykłady ograniczania szybkości
Różne limity stawek dla różnych lokalizacji
W bardziej złożonych scenariuszach może być konieczne zastosowanie różnych limitów szybkości dla różnych części aplikacji. Jest to szczególnie przydatne, gdy określone punkty końcowe wymagają większych zasobów lub są podatne na nadużycia.
Rozważ następującą konfigurację:
http {
limit_req_zone $binary_remote_addr zone=low:10m rate=1r/s;
limit_req_zone $binary_remote_addr zone=high:10m rate=10r/s;
server {
listen 80;
server_name example.com;
location /api/low {
limit_req zone=low burst=3;
proxy_pass http://backend;
}
location /api/high {
limit_req zone=high burst=20;
proxy_pass http://backend;
}
}
}
Ta konfiguracja stosuje dolny limit szybkości (1 żądanie na sekundę) do lokalizacji /api/low i wyższy limit szybkości (10 żądań na sekundę) do lokalizacji /api/high.
Dodatkowe przykłady ograniczania szybkości Nginx
Ograniczanie szybkości w oparciu o typy żądań
Możesz skonfigurować ograniczanie szybkości w oparciu o określone żądania, takie jak żądania GET, POST lub PUT. Jest to szczególnie przydatne, gdy chcesz chronić określone punkty końcowe, które są bardziej podatne na nadużycia lub mają większy wpływ na zasoby Twojego serwera.
Możesz użyć dyrektywy if i zmiennej $request_method, aby zastosować ograniczenie szybkości do określonych typów żądań. Oto przykład:
http {
limit_req_zone $binary_remote_addr zone=get_limit:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=post_limit:10m rate=2r/s;
server {
listen 80;
server_name example.com;
location / {
if ($request_method = GET) {
limit_req zone=get_limit burst=10;
}
if ($request_method = POST) {
limit_req zone=post_limit burst=5;
}
proxy_pass http://backend;
}
}
}
W tej konfiguracji ustawiliśmy dwa oddzielne limity szybkości: jeden dla żądań GET (5 żądań na sekundę) i jeden dla żądań POST (2 żądania na sekundę).
Ograniczanie szybkości na podstawie agenta użytkownika
Inną przydatną techniką jest zastosowanie ograniczania szybkości w oparciu o nagłówek User-Agent wysyłany przez klientów. Może to pomóc chronić Twoje usługi przed określonymi botami lub robotami indeksującymi, które powodują problemy.
Aby zaimplementować ograniczenie szybkości w oparciu o User-Agent, możesz użyć dyrektywy map i zmiennej $http_user_agent.
Oto przykład:
http {
map $http_user_agent $limit_bots {
default 0;
~*(Googlebot|Bingbot) 1;
}
limit_req_zone $binary_remote_addr zone=bot_limit:10m rate=1r/s;
server {
listen 80;
server_name example.com;
location / {
if ($limit_bots) {
limit_req zone=bot_limit burst=2;
}
proxy_pass http://backend;
}
}
}
W tym przykładzie zdefiniowaliśmy dyrektywę map, która ustawia zmienną $limit_bots na 1, jeśli nagłówek User-Agent pasuje do „Googlebot” lub „Bingbot”. Następnie do żądań tych botów stosujemy limit szybkości wynoszący 1 żądanie na sekundę.
Dodawanie adresów IP do białej listy w ramach ograniczania szybkości
Czasami możesz chcieć wyłączyć określone adresy IP, takie jak zaufani partnerzy lub usługi wewnętrzne, z ograniczania szybkości. Aby to osiągnąć, możesz użyć dyrektywy geograficznej wraz z if dyrektywa.
Oto przykład:
http {
geo $rate_limit {
default 1;
192.168.0.0/24 0;
10.0.0.0/8 0;
}
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
server {
listen 80;
server_name example.com;
location / {
if ($rate_limit) {
limit_req zone=mylimit burst=10;
}
proxy_pass http://backend;
}
}
}
Ograniczanie szybkości skalowania w środowisku rozproszonym
Gdy w środowisku rozproszonym działa wiele instancji Nginx, warto upewnić się, że ograniczanie szybkości jest spójne we wszystkich instancjach. Aby to osiągnąć, możesz użyć scentralizowanego magazynu danych, takiego jak Redis, do zarządzania limitami szybkości. Dzięki temu możesz zachować globalny limit szybkości dzielony między wszystkie instancje Nginx.
Aby skonfigurować ograniczanie szybkości za pomocą Redis, musisz zainstalować i skonfigurować moduł nginx-module-redis. Po zainstalowaniu modułu możesz zaktualizować konfigurację Nginx, aby używać Redis do ograniczania szybkości.
Oto przykład:
load_module modules/ngx_http_redis_module.so;
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
upstream redis_server {
server 127.0.0.1:6379;
keepalive 32;
}
server {
listen 80;
server_name example.com;
location / {
limit_req_redis zone=mylimit burst=10 redis_server=redis_server;
proxy_pass http://backend;
}
}
}
W tym przykładzie zdefiniowaliśmy blok nadrzędny dla serwera Redis i zaktualizowaliśmy blok lokalizacji, aby korzystał z dyrektywy limit_req_redis zamiast standardowej dyrektywy limit_req. Ta konfiguracja zapewnia egzekwowanie limitów szybkości przy użyciu udostępnionego magazynu danych Redis, zapewniając spójne ograniczanie szybkości w wielu instancjach Nginx.
Dynamiczne ograniczanie szybkości
W niektórych sytuacjach możesz chcieć dynamicznie dostosowywać limity szybkości w oparciu o pewne warunki lub bieżące obciążenie serwera. Na przykład możesz chcieć zastosować bardziej rygorystyczne limity szybkości w godzinach szczytu, aby lepiej zarządzać zasobami serwera.
Aby zaimplementować dynamiczne ograniczanie szybkości, możesz użyć metody map dyrektywę określającą limity stawek na podstawie określonych warunków.
Oto przykład:
http {
map $http_x_traffic $dynamic_rate {
default "5r/s";
high "2r/s";
}
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=$dynamic_rate;
server {
listen 80;
server_name example.com;
location / {
limit_req zone=mylimit burst=10;
proxy_pass http://backend;
}
}
}
W tej konfiguracji używamy zmiennej $http_x_traffic pochodzącej z niestandardowego nagłówka X-Traffic. Na podstawie wartości tego nagłówka dynamicznie ustalamy limit szybkości. Gdy wartość nagłówka jest „wysoka”, stosujemy bardziej rygorystyczny limit szybkości wynoszący 2 żądania na sekundę. W przeciwnym razie używamy domyślnej szybkości 5 żądań na sekundę.
Należy pamiętać, że w tym przykładzie założono, że serwer zaplecza lub inny komponent infrastruktury ustawia nagłówek X-Traffic w oparciu o żądane warunki.
Testowanie limitu szybkości w konfiguracji NGINX
Weryfikacja ograniczenia szybkości za pomocą zwijania
Używanie curl do prostego testowania żądań
Aby sprawdzić skuteczność konfiguracji ograniczającej szybkość transmisji w NGINX, bardzo przydatne okazuje się curl, narzędzie wiersza poleceń do wysyłania żądań HTTP. Może szybko wysłać wiele żądań do Twojego serwera, pomagając Ci ocenić, czy limity szybkości są aktywne.
for i in {1..10}; do curl -I http://example.com; done- To polecenie wysyła 10 żądań HEAD do Twojego serwera, kierowanych na http://example.com.
- Przeanalizuj nagłówki odpowiedzi HTTP z tych żądań, aby zweryfikować funkcjonalność ograniczającą szybkość.
- NGINX powinien zwrócić kod stanu 429 Too Many Requests, gdy liczba żądań przekracza określony limit.
Testowanie za pomocą Apache Bench (ab)
Testowanie odpowiedzi serwerów za pomocą Apache Bench
Apache Bench (ab) to skuteczne narzędzie do testów porównawczych, idealne do testowania limitów szybkości poprzez symulację warunków o dużym natężeniu ruchu. Pomaga zrozumieć, jak zachowuje się Twój serwer NGINX w przypadku napływu żądań.
ab -n 100 -c 10 http://example.com/- To polecenie instruuje ab, aby wysłał 100 żądań do http://example.com z poziomem współbieżności 10.
- Dane wyjściowe ab zapewniają wgląd w skuteczność ograniczającą szybkość.
- Skoncentruj się na liczbie nieudanych żądań w danych wyjściowych, która powinna być zgodna z ustawieniami konfiguracji ograniczającej szybkość NGINX.
Stosowanie najlepszych metod testowania konfiguracji NGINX gwarantuje, że reguły ograniczające szybkość będą działać zgodnie z zamierzeniami.
Wniosek
Konfigurując ograniczenie szybkości w NGINX, możesz chronić swój serwer przed nadmiernym ruchem i potencjalnymi nadużyciami. Pomaga to w utrzymaniu wydajności i dostępności usług, zapewniając lepsze doświadczenia legalnym użytkownikom. Regularnie monitoruj i dostosowuj ustawienia ograniczające szybkość, aby zrównoważyć bezpieczeństwo i dostępność. Wdrożenie tych kontroli jest niezbędne do efektywnego zarządzania zasobami serwera.
