Cos'è il rate limiting, in cosa differiscono fixed window, sliding window, token bucket e leaky bucket, con un simulatore live, lo status 429, Retry-After e un esempio Nginx.
Il rate limiting limita quante richieste un visitatore, una chiave o un indirizzo IP può inviare in un certo periodo di tempo. Le richieste oltre il limite vengono rifiutate, di solito con lo status HTTP 429 Too Many Requests e un header Retry-After che indica quando riprovare. Protegge moduli di login, moduli di contatto e API da raffiche di richieste e da costi fuori controllo.
I quattro algoritmi di rate limiting più comuni
Se il tuo sito ha una pagina di accesso, un modulo di contatto, un checkout o un'API chiamata da altre app, prima o poi qualcuno la bombarderà di richieste, per errore o di proposito. Il rate limiting è la regola che stabilisce quanto è troppo. Qui sotto puoi premere dei pulsanti per inviare richieste e vedere ogni algoritmo accettarle o rifiutarle, poi copiare una configurazione Nginx funzionante.
La RFC 6585 definisce 429 Too Many Requests come lo status per un client che ha inviato troppe richieste in un certo intervallo di tempo. La risposta può includere un header Retry-After che dice al client quanto aspettare.
Di default il modulo limit_req risponde alle richieste rifiutate con 503. Puoi cambiarlo in 429 con la direttiva limit_req_status, che la maggior parte delle API preferisce perché dice al chiamante esattamente cosa è successo.
Non ancora. I campi RateLimit e RateLimit-Policy provengono da un Internet-Draft di un gruppo di lavoro IETF ancora in corso a ottobre 2026, quindi alcuni servizi inviano invece i vecchi header X-RateLimit. Considerali indicazioni utili.
Un token bucket permette a un chiamante di spendere in una raffica i token accumulati per poi assestarsi sul ritmo di ricarica. Un leaky bucket livella il traffico in un deflusso fisso. Nginx documenta che il suo modulo limit_req usa il metodo leaky bucket.
No. Gestisce bene gli abusi da poche sorgenti, ma il traffico distribuito su migliaia di indirizzi richiede anche una protezione dal tuo hosting o dalla CDN. Il rate limiting è un livello, non l'intera difesa.
Questa configurazione consente a ogni indirizzo IP 5 richieste al secondo sul percorso di login, con una raffica di 10 servite subito, e risponde alle richieste in eccesso con 429 invece del 503 predefinito.
La zona da 10m memorizza i contatori; la documentazione dice che un megabyte contiene circa 16 mila stati da 64 byte.
Per un singolo server, un token bucket sta in poche righe. Tieni i conteggi in uno store condiviso se usi più di un server.
Ogni chiave riceve 10 token che si ricaricano a 1 al secondo. Una chiamata rifiutata riceve 429 e un Retry-After in secondi interi.
Status 429 con un Retry-After di 30 secondi.
Ogni algoritmo consente circa 5 richieste ogni 5 secondi (o un bucket da 5 che scorre a 1 al secondo). Invia richieste, lascia passare il tempo e guarda cosa passa.
Algoritmo
Fixed window
Sliding window
Token bucket
Leaky bucket
Invia 1 richiesta
Invia una raffica di {n}
Aspetta 1 secondo
Azzera
Tempo: {v} s
Consentite: {n}
Rifiutate con 429: {n}
Log delle richieste
t={v}s consentita
t={v}s rifiutata (429)
Ancora nessuna richiesta. Premi un pulsante qui sopra.
Un modello didattico a passi di un secondo intero. I limitatori reali misurano in millisecondi.
Inizia gratis · Nessuna carta di credito richiesta