Rate limiting ஒரு கால இடைவெளியில் ஒரு client செய்யக்கூடிய கோரிக்கைகளின் எண்ணிக்கையை வரம்பிடுகிறது. நீங்கள் இதை பல்வேறு அடுக்குகளில் பயன்படுத்துகிறீர்கள் ஏனெனில் ஒவ்வொன்றும் வெவ்வேறு விஷயத்தைப் பார்க்கிறது, மேலும் நீங்கள் இதை எதுவாக இருந்தாலும் தவறுசெய்வோனை அடையாளப்படுத்துகிறது என்பதன் அடிப்படையில் கீலியம் செய்கிறீர்கள்.
429 Too Many Requests with Retry-After எனவே clients தட்டி அடிப்பதற்கு பதிலாக கூசிக்கொண்டு கோபம் கொள்கிறார்கள்.# Define a shared-memory zone keyed by client IP.
# rate=10r/s = the steady refill rate (token bucket).
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
# burst=20: allow a short spike of 20 queued requests
# nodelay: serve the burst immediately instead of spacing it out
limit_req zone=api burst=20 nodelay;
# Return 429 (not the default 503) so clients see a rate-limit signal
limit_req_status 429;
proxy_pass http://backend;
}
}
இங்கே ஒவ்வொரு IP 10 requests/second இல் refills, 20 வரை burst செய்யக்கூடும், மற்றும் அதற்கு அப்பால் ஏதேனும் ஒரு 429 கிடைக்கிறது.
Rate limiting Layer 7 floods, credential stuffing, மற்றும் runaway scrapers எதிராக உங்கள் மலிவு, எப்போதும்-on defense. அதை layering (volume க்கான edge, origin க்கான proxy, business logic க்கான app) மற்றும் சரியாக keying தவறுசெய்வோனை நிறுத்துகிறது உண்மையான பயனர்கள் — மற்றும் legitimate bursts — untouched போல்.