Come risolvere l’errore 429 “Too Many Requests”

L’errore HTTP 429 “Too Many Requests”  è un codice di risposta con limitazione di velocità inviato da un server quando un utente (o un client) supera il numero di richieste consentite in un determinato lasso di tempo. Questo stato è tipicamente parte di meccanismi di sicurezza, protezione API o anti-DDoS.

Negli ambienti di produzione, può interrompere i servizi, interrompere le integrazioni API o influire sulla SEO. Questa guida avanzata spiega come diagnosticare, prevenire e risolvere l’errore 429 sia dal lato client che dal lato server.

Cosa causa l’errore 429?

Scenari comuni:

  • Un utente/robot sta inviando troppe richieste HTTP (chiamate API, caricamento di pagine, ecc.)

  • L’applicazione esegue lo scraping o il polling di un servizio di terze parti in modo troppo aggressivo

  • I firewall delle applicazioni web (WAF) o i reverse proxy (ad esempio, Cloudflare, Nginx) impongono limiti di velocità

  • Le API del server o del backend utilizzano librerie di limitazione della velocità (ad esempio, express-rate-limit, mod_evasive, ecc.)

  • I bot o i crawler invadono il sito web o l’endpoint

Passo 1: identificare la fonte

✅ 1. Controllare le intestazioni delle risposte

I server spesso inviano un’intestazione Retry-After con una risposta 429:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Indica al client quanto tempo attendere (in secondi) prima di riprovare.

✅ 2. Controllare i registri di accesso

Per Apache:

cat /var/log/apache2/access.log | grep "429"

Per Nginx:

cat /var/log/nginx/access.log | grep "429"

Questo aiuta a identificare quali IP o endpoint stanno attivando il limite.

✅ 3. Utilizzare gli strumenti di monitoraggio

  • Registri di Fail2Ban

  • Eventi del firewall Cloudflare

  • Log a livello di applicazione (Laravel, Express, Django, ecc.)

  • Analisi dei limiti di velocità (se si utilizza un gateway API)

Passo 2: Correzioni lato server

A. Limitazione della velocità di Nginx (se abilitata)

Nginx può essere configurato in questo modo:

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

location /api/ {
limit_req zone=api_limit burst=10 nodelay;
}

Soluzione:

  • Aumentare la velocità o il burst

  • Applicare a percorsi specifici (ad esempio, /api/) invece che a livello globale

  • Inserire nella whitelist gli IP interni conosciuti

B. Apache (mod_evasive o mod_security)

Se mod_evasive è attivo:

sudo nano /etc/apache2/mods-enabled/evasive.conf

Regolare:

DOSPageCount 10
DOSSiteCount 100
DOSBlockingPeriod 10

➡️ Aumentare le soglie o disabilitare per specifici IP affidabili.

C. Regole Cloudflare / CDN

Se siete dietro Cloudflare, controllate:

  • Regole di limitazione della velocità in Sicurezza > WAF

  • Modalità di lotta ai bot

  • Regole del firewall che bloccano in base a User-Agent o IP

Soluzione:

  • Ridurre la sensibilità

  • Inserire in whitelist gli IP dei server o determinati user agent

  • Creare regole personalizzate per crawler e partner sicuri

D. Limitazione della velocità a livello di applicazione

Verificate se la vostra applicazione impone dei limiti utilizzando librerie come:

  • Node.js: express-rate-limit

  • Laravel: ThrottleRequests

  • Django: drf-extensions o middleware

Aggiornare la configurazione, come ad esempio:

rateLimit({
finestraMs: 1 * 60 * 1000, // 1 minuto
max: 100, // limita ogni IP a 100 richieste al minuto
})

➡️ Regolare i limiti, aggiungere una whitelist di utenti/IP o aumentare la quota in base ai token di autenticazione.

Passo 3: Correzioni lato client (quando si utilizzano le API)

Se l’applicazione è il client e riceve 429:

implementare il backoff esponenziale

Riprova automaticamente le richieste con ritardi crescenti:

const retryAfter = (attempt) => Math.pow(2, attempt) * 1000;

rispettare le intestazioni Retry-After

if (response.status === 429) {
const wait = response.headers['retry-after'] * 1000;
setTimeout(() => retryRequest(), wait);
}

✅ Aggiungere la limitazione della velocità al client

Limitare le proprie richieste se si effettua il polling:

// Usare lodash o un throttling personalizzato
_.throttle(() => fetchData(), 1000);

Passo 4: Considerazioni SEO

Uno stato 429 servito ai crawler dei motori di ricerca può danneggiare le classifiche.

soluzione:

  • Servire un 503 (servizio non disponibile) con Retry-After

  • Utilizzare il file robots.txt per limitare la velocità di crawling:

    User-agent: *
    Crawl-delay: 10

  • In Cloudflare: Andare su Bot > Gestione crawl

Passo 5: proteggere senza bloccare gli utenti legittimi

Invece di limiti severi a 429:

  • Utilizzate i CAPTCHA per le attività sospette

  • Implementare ritardi progressivi piuttosto che blocchi rigidi

  • Utilizzare una limitazione della velocità basata sull’utente piuttosto che sull’IP per gli utenti connessi

  • Fornire un accesso autenticato con limiti di velocità più elevati (ad esempio, tramite chiavi API o token)

Conclusione

L’errore 429 Too Many Requests è uno strumento utile ma talvolta dannoso. Capire da dove proviene – server, CDN o applicazione – è fondamentale per risolverlo. Con una configurazione adeguata, la registrazione e il rispetto dei limiti da parte del client, è possibile bilanciare la protezione con l’usabilità.