Il rate limiting limita il numero di richieste che un client può fare in una finestra temporale. Lo applichi a più livelli perché ciascuno vede qualcosa di diverso, e lo identifichi in base a quello che identifica chi abusa.
Il rate limiting limita il numero di richieste che un client può fare in una finestra temporale. Lo applichi a più livelli perché ciascuno vede qualcosa di diverso, e lo identifichi in base a quello che identifica chi abusa.
429 Too Many Requests con Retry-After così i client si arrestano educatamente invece di continuare a martellare.# 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;
}
}
Qui ogni IP si ricostituisce a 10 richieste/secondo, può fare burst fino a 20, e tutto il resto ottiene un 429.
Il rate limiting è la tua difesa più economica e sempre attiva contro flood di Layer 7, credential stuffing e scraper in fuga. Stratificarlo (edge per il volume, proxy per l'origin, app per la logica di business) e identificarlo correttamente arresta chi abusa mentre gli utenti reali — e i burst legittimi — passano indisturbati. Impostare i limiti da baseline reali è quello che impedisce che diventi un'interruzione di tua stessa creazione.