Hastighetsbegränsning i NGINX är en avgörande funktion för att kontrollera mängden trafik som din server hanterar. Det hjälper till att skydda din server från att överväldigas av för många förfrågningar under en kort period, vilket skadliga attacker som DDoS eller höga trafikspikar kan orsaka. Genom att implementera hastighetsbegränsning säkerställer du att dina resurser används effektivt och legitima användare kan komma åt dina tjänster utan avbrott.
Den här guiden visar hur du konfigurerar hastighetsbegränsning i NGINX, och ger tydliga instruktioner som hjälper dig att hantera och kontrollera inkommande trafik effektivt.
Förstå räntegränsdirektiven i NGINX
Viktiga NGINX satsbegränsande direktiv
NGINX konfigurerar hastighetsbegränsning med hjälp av specifika direktiv, som var och en har en unik funktion:
- limit_req_zone: Limit_req_zone-direktivet i NGINX sätter upp en delad minneszon för lagring av hastighetsbegränsande information. Placerad i http-sammanhanget bestämmer den den tillåtna frekvensen av förfrågningar, vilket effektivt sätter baslinjen för hastighetsgränser.
- limit_req: Limit_req-direktivet, som används i platssammanhang, upprätthåller den hastighetsgräns som satts av limit_req_zone. Den tillämpar dessa begränsningar på specifika platser eller webbadresser och kontrollerar på så sätt frekvensen för åtkomst till dessa slutpunkter.
- limit_req_status: Placerat i platssammanhanget specificerar direktivet limit_req_status HTTP-statuskoden som returneras när förfrågningshastigheten överskrider gränsen. Denna feedbackmekanism är avgörande för att informera användare eller automatiserade system när de överskrider den tillåtna förfrågningsfrekvensen.
Skapa en hastighetsbegränsande konfiguration
För att implementera hastighetsbegränsning i NGINX, infoga lämpliga direktiv i NGINX-konfigurationsfilen. Tänk på det här grundläggande exemplet:
http {
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
server {
...
location / {
limit_req zone=mylimit burst=10;
...
}
}
}I den här konfigurationen upprättar direktivet limit_req_zone en minneszon med namnet 'mylimit', som tillåter 5 förfrågningar per sekund (5r/s) från varje klients IP-adress ($binary_remote_addr). Limit_req-direktivet tillämpar sedan denna hastighetsgräns på rotplatsen (/), med en burstkapacitet på 10 förfrågningar, vilket erbjuder en balans mellan strikt hastighetsbegränsning och flexibilitet för legitima trafiktoppar.
Rate Limit i NGINX: Praktiska exempel
Grundläggande hastighetsbegränsande konfiguration
Det här avsnittet kommer att utforska en grundläggande hastighetsbegränsande konfiguration som tillämpas över hela servern i NGINX. Syftet är att begränsa användarförfrågningar till servern, säkerställa stabil prestanda och minska risken för överbelastning.
Exempel: Server-Wide Rate Limit
Tänk på följande NGINX-konfiguration:
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;
}
}
}
Denna konfiguration anger en gräns på 2 förfrågningar per sekund för varje klient, enligt definitionen av deras IP-adress ($binary_remote_addr). Låt oss bryta ner nyckelkomponenterna:
- limit_req_zone: Definierar en minneszon (mylimit) för lagring av hastighetsgränstillstånden med en storlek på 10 megabyte. Den ställer in hastighetsgränsen till 2 förfrågningar per sekund (2r/s).
- server block: Lyssnar på port 80 efter inkommande trafik till example.com.
- platsblock: Tillämpar hastighetsgränsen på rotwebbadressen (/). Burst-parametern tillåter en skur på upp till 5 förfrågningar, vilket ger flexibilitet för korta toppar i trafiken. Direktivet proxy_pass vidarebefordrar begäran till den angivna backend-servern.
- Burst-parameter: Burst=5-inställningen i limit_req-direktivet tillåter en kortvarig ökning av förfrågningar, upp till 5 ytterligare förfrågningar över den inställda hastigheten. Den här funktionen är avgörande för att hantera plötsliga, legitima ökningar av trafik utan att påverka användarupplevelsen.
- Proxy Pass: Proxy_pass http://backend; direktiv vidarebefordrar trafiken till en backend-server. Detta används vanligtvis i lastbalanserande scenarier eller när NGINX fungerar som en omvänd proxy.
Avancerade räntebegränsande exempel
Olika prisgränser för olika platser
Du kan behöva tillämpa olika hastighetsgränser för olika applikationsdelar i mer komplexa scenarier. Detta är särskilt användbart när specifika slutpunkter är mer resurskrävande eller benägna att missbrukas.
Tänk på följande konfiguration:
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;
}
}
}
Den här konfigurationen tillämpar en lägre hastighetsgräns (1 begäran per sekund) på /api/low-platsen och en högre hastighetsgräns (10 förfrågningar per sekund) på /api/high-platsen.
Ytterligare Nginx-hastighetsbegränsande exempel
Prisbegränsning baserat på förfrågningstyper
Du kan konfigurera hastighetsbegränsning baserat på specifika förfrågningar, såsom GET-, POST- eller PUT-förfrågningar. Detta är särskilt användbart när du vill skydda specifika slutpunkter som är mer sårbara för missbruk eller har en större inverkan på dina serverresurser.
Du kan använda if-direktivet och variabeln $request_method för att tillämpa hastighetsbegränsning på specifika förfrågningstyper. Här är ett exempel:
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;
}
}
}
I den här konfigurationen har vi satt upp två separata hastighetsgränser: en för GET-förfrågningar (5 förfrågningar per sekund) och en för POST-förfrågningar (2 förfrågningar per sekund).
Prisbegränsning baserat på användaragent
En annan användbar teknik är att tillämpa hastighetsbegränsning baserat på User-Agent-huvudet som skickas av klienter. Detta kan hjälpa till att skydda dina tjänster från specifika botar eller sökrobotar som orsakar problem.
För att implementera hastighetsbegränsning baserad på User-Agent kan du använda kartdirektivet och variabeln $http_user_agent.
Här är ett exempel:
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;
}
}
}
I det här exemplet har vi definierat ett kartdirektiv som sätter variabeln $limit_bots till 1 om User-Agent-huvudet matchar "Googlebot" eller "Bingbot". Vi tillämpar sedan en hastighetsgräns på 1 begäran per sekund för förfrågningar från dessa bots.
Vitlista IP-adresser från Rate Limiting
Ibland kanske du vill undanta specifika IP-adresser, till exempel betrodda partners eller interna tjänster, från skattebegränsning. För att uppnå detta kan du använda geodirektivet, tillsammans med if direktiv.
Här är ett exempel:
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;
}
}
}
Skalningshastighetsbegränsning i en distribuerad miljö
När flera Nginx-instanser körs i en distribuerad miljö kanske du vill se till att hastighetsbegränsningen är konsekvent i alla instanser. Du kan använda ett centraliserat datalager som Redis för att hantera hastighetsgränser för att uppnå detta. Genom att göra det kan du behålla en global hastighetsgräns som delas mellan alla Nginx-instanser.
För att ställa in hastighetsbegränsning med Redis måste du installera och konfigurera modulen nginx-module-redis. När du har installerat modulen kan du uppdatera din Nginx-konfiguration för att använda Redis för hastighetsbegränsning.
Här är ett exempel:
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;
}
}
}
I det här exemplet har vi definierat ett uppströmsblock för Redis-servern och uppdaterat platsblocket för att använda limit_req_redis-direktivet istället för standarddirektivet limit_req. Denna konfiguration säkerställer att hastighetsbegränsningar upprätthålls med hjälp av det delade Redis-datalagret, vilket ger konsekvent hastighetsbegränsning över flera Nginx-instanser.
Dynamisk hastighetsbegränsning
I vissa situationer kanske du vill justera hastighetsgränserna dynamiskt baserat på vissa förhållanden eller den aktuella belastningen på din server. Till exempel kanske du vill tillämpa strängare hastighetsgränser under högtrafik för att hantera serverresurser bättre.
För att implementera dynamisk hastighetsbegränsning kan du använda map direktiv för att definiera räntegränser baserat på specifika villkor.
Här är ett exempel:
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;
}
}
}
I den här konfigurationen använder vi variabeln $http_x_traffic härledd från en anpassad rubrik X-Traffic. Baserat på denna rubriks värde ställer vi dynamiskt in hastighetsgränsen. När rubrikvärdet är "högt" tillämpar vi en strängare hastighetsgräns på 2 förfrågningar per sekund. Annars använder vi standardfrekvensen på 5 förfrågningar per sekund.
Observera att det här exemplet förutsätter att din backend-server eller en annan komponent i din infrastruktur ställer in X-Traffic-huvudet baserat på dina önskade förhållanden.
Testa din hastighetsgräns i NGINX-konfiguration
Verifierar hastighetsbegränsande med curl
Använda curl för Simple Request Testing
För att validera effektiviteten av din hastighetsbegränsande inställning i NGINX, visar sig curl, ett kommandoradsverktyg för att skicka HTTP-förfrågningar, mycket användbart. Det kan snabbt skicka flera förfrågningar till din server, vilket hjälper dig att bedöma om hastighetsgränserna är aktiva.
for i in {1..10}; do curl -I http://example.com; done- Detta kommando skickar 10 HEAD-förfrågningar till din server, inriktade på http://example.com.
- Analysera HTTP-svarsrubriker från dessa förfrågningar för att verifiera hastighetsbegränsande funktionalitet.
- NGINX bör returnera en 429 Too Many Requests-statuskod när antalet förfrågningar överskrider din angivna gräns.
Testa med Apache Bench (ab)
Benchmarking serversvar med Apache Bench
Apache Bench (ab) är ett effektivt benchmarking-verktyg som är idealiskt för att testa hastighetsgränser genom att simulera förhållanden med hög trafik. Det hjälper till att förstå hur din NGINX-server beter sig under en våg av förfrågningar.
ab -n 100 -c 10 http://example.com/- Detta kommando instruerar ab att skicka 100 förfrågningar till http://example.com med en samtidighetsnivå 10.
- Utdata från ab ger insikter om den hastighetsbegränsande effektiviteten.
- Fokusera på antalet misslyckade förfrågningar i utgången, vilket bör vara i linje med inställningarna för din NGINX-hastighetsbegränsande konfiguration.
Genom att använda de bästa metoderna för att testa din NGINX-konfiguration säkerställer du att dina hastighetsbegränsande regler fungerar som avsett.
Slutsats
Genom att konfigurera hastighetsbegränsning i NGINX kan du skydda din server från överdriven trafik och potentiellt missbruk. Detta hjälper till att upprätthålla prestanda och tillgänglighet för dina tjänster, vilket säkerställer en bättre upplevelse för legitima användare. Övervaka och justera dina hastighetsbegränsande inställningar regelbundet för att balansera säkerhet och tillgänglighet. Att implementera dessa kontroller är avgörande för att effektivt hantera din servers resurser.
