Introducing ZYNOO General Purpose & CPU Optimized Servers   Learn More >

Come configurare la limitazione della frequenza delle richieste in Nginx su Ubuntu

La limitazione della frequenza delle richieste in Nginx è una funzionalità integrata che controlla quante richieste HTTP un client può effettuare in un determinato periodo. Può ridurre il traffico abusivo diretto ad API, pagine di accesso e applicazioni che richiedono molte risorse, senza bisogno di software aggiuntivo.

In questa guida configurerai i limiti delle richieste in Nginx, li testerai in sicurezza e attiverai la protezione su un server Ubuntu.

Come funziona la limitazione della frequenza delle richieste in Nginx?

Nginx utilizza il modulo limit_req per tenere traccia delle richieste in arrivo, generalmente in base all’indirizzo IP del client.

Ad esempio, puoi configurare un limite medio di cinque richieste al secondo, consentendo al contempo brevi picchi di traffico. Le richieste che superano il picco consentito possono quindi essere rifiutate.

Questo aiuta a evitare che un numero eccessivo di richieste sovraccarichi l’applicazione.

Nota: La limitazione della frequenza delle richieste aiuta a mitigare alcuni attacchi HTTP flood di livello 7. Non può fermare attacchi DDoS di grandi dimensioni a livello di rete che saturano la connessione.

come configurare la limitazione della frequenza delle richieste in Nginx

Prerequisiti

Ti serviranno un server Ubuntu con Nginx installato, l’accesso SSH con privilegi sudo e un sito web o un’applicazione già esistente.

Prima di apportare modifiche, esegui un backup della configurazione esistente del sito web.

Passaggio 1: definire una zona per la limitazione della frequenza delle richieste

Connettiti al server tramite SSH.

In un’installazione standard di Nginx su Ubuntu, crea un nuovo file di configurazione:

sudo nano /etc/nginx/conf.d/rate-limit.conf

Aggiungi:

limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;

Questa configurazione utilizza l’indirizzo IP del client per tenere traccia delle richieste, alloca 10 MB per i dati di tracciamento e imposta un limite medio di cinque richieste al secondo per IP.

La direttiva limit_req_zone deve trovarsi nel contesto http di Nginx. La configurazione standard di Ubuntu include lì i file conf.d.

Salva il file.

Passaggio 2: attivare la limitazione della frequenza delle richieste per il sito web

Apri il file di configurazione Nginx del sito web:

sudo nano /etc/nginx/sites-available/app.example.com

Sostituisci il nome del file con quello della tua configurazione.

Per un’applicazione HTTP in esecuzione sulla porta 3000, un endpoint API protetto potrebbe avere questa struttura:

location /api/ {
    limit_req zone=perip burst=10 nodelay;
    limit_req_status 429;
    limit_req_dry_run on;

    proxy_pass http://127.0.0.1:3000;
}

Ecco cosa fanno le direttive principali:

  • limit_req: applica il limite definito in precedenza.
  • burst=10: consente un breve picco di richieste oltre il limite.
  • nodelay: elabora immediatamente le richieste consentite durante il picco.
  • limit_req_status 429: restituisce HTTP 429 quando le richieste vengono rifiutate.
  • limit_req_dry_run on: registra le richieste eccessive senza bloccarle.

Importante: Aggiungi queste direttive di limitazione della frequenza delle richieste al blocco location esistente corrispondente. Non creare blocchi location duplicati e non sostituire la configurazione esistente del backend.

I valori riportati sono esempi. Scegli i limiti in base ai normali schemi di richieste della tua applicazione.

Passaggio 3: verificare la configurazione di Nginx

Verifica la configurazione:

sudo nginx -t

Se il test va a buon fine, ricarica Nginx:

sudo systemctl reload nginx

Se compare un errore, correggilo prima di ricaricare Nginx.

Passaggio 4: testare il limite delle richieste

Poiché la modalità dry-run è attiva, le richieste non verranno ancora rifiutate.

Monitora il registro degli errori di Nginx:

sudo tail -f /var/log/nginx/error.log

Da un altro terminale, invia un piccolo picco di richieste di prova a un endpoint sotto il tuo controllo:

for i in $(seq 1 15); do
  curl -s -o /dev/null -w "%{http_code}\n" \
  https://app.example.com/api/health
done

Sostituisci l’URL con quello di un endpoint funzionante della tua applicazione di test o staging.

Se le richieste superano il limite, Nginx dovrebbe registrare nel log degli errori messaggi contenenti limiting requests, dry run.

L’applicazione dovrebbe continuare a restituire le risposte abituali perché il blocco non è attivo.

Passaggio 5: attivare la limitazione della frequenza delle richieste

Dopo aver esaminato i risultati e verificato che i limiti siano appropriati, rimuovi questa direttiva dal blocco location protetto:

limit_req_dry_run on;

Verifica nuovamente la configurazione e ricarica Nginx:

sudo nginx -t
sudo systemctl reload nginx

Le richieste eccessive possono ora ricevere la risposta HTTP 429 Too Many Requests.

Ripeti un test controllato e verifica i codici di risposta. I risultati esatti dipendono dalla frequenza con cui vengono inviate le richieste e dai limiti configurati.

Come annullare le modifiche

Se gli utenti legittimi riscontrano problemi, ripristina:

limit_req_dry_run on;

Verifica la configurazione e ricarica Nginx. In questo modo torni alla modalità di monitoraggio senza rifiutare le richieste.

Potrai quindi adeguare i limiti in base al traffico reale.

Importante: Nginx dietro Cloudflare o un’altra CDN

Quando Nginx si trova dietro un reverse proxy, l’indirizzo IP del client visibile a Nginx potrebbe appartenere al proxy anziché al visitatore originale.

Applicare limiti per IP senza correggere questa situazione può far sì che utenti diversi vengano raggruppati insieme.

Prima di applicare limiti per client, configura la gestione degli IP dei client attendibili utilizzando il modulo Real IP di Nginx e gli intervalli di indirizzi IP documentati dal provider del proxy.

Non considerare mai attendibili le intestazioni IP fornite arbitrariamente dai visitatori.

La limitazione della frequenza delle richieste in Nginx sostituisce la protezione DDoS?

No. Nginx può limitare le richieste HTTP eccessive che raggiungono l’applicazione, ma non può filtrare il traffico che ha già saturato la connessione di rete a monte del server.

Per una protezione più ampia, combina i controlli a livello applicativo con le misure di mitigazione offerte dall’infrastruttura di hosting.

Domande frequenti

La limitazione della frequenza delle richieste in Nginx è gratuita?

Sì. Nginx Open Source include il modulo limit_req.

La limitazione della frequenza delle richieste in Nginx può bloccare visitatori legittimi?

Sì. Impostazioni troppo restrittive possono rifiutare richieste legittime, soprattutto quando più utenti condividono lo stesso indirizzo IP. Esegui un test in modalità dry-run prima di attivare il blocco.

La limitazione della frequenza delle richieste in Nginx funziona per le API?

Sì. È particolarmente utile per controllare le richieste eccessive agli endpoint API e ad altri percorsi applicativi che richiedono molte risorse.

Conclusione

Nginx offre una funzionalità integrata di limitazione della frequenza delle richieste che può contribuire a ridurre il traffico HTTP abusivo senza richiedere software aggiuntivo.

Configura il limite delle richieste, testalo in modalità dry-run e attiva il blocco solo dopo aver esaminato i risultati.

Per una protezione completa del server, affianca alla limitazione della frequenza delle richieste adeguate misure di mitigazione DDoS a monte.

Table of Content

Un reverse proxy Nginx riceve le richieste dei visitatori di un sito web e le

Un errore 502 Bad Gateway in Nginx di solito significa che Nginx non è riuscito

Un errore 504 Gateway Timeout si verifica quando un server che funge da gateway o

Build your next project with ZYNOO

From your first website to demanding applications, choose the resources and control you need.

Shared Hosting

Start your blog or business website with cPanel, LiteSpeed and CloudLinux.

VPS Hosting

Grow your websites and applications with NVMe storage, KVM virtualization and full root access.

Dedicated Servers

Power demanding projects with your own physical server, dedicated resources and control over your environment.

Torna in alto