L’errore 429 Too Many Requests indica che un client, un indirizzo IP o un’applicazione ha superato il numero di richieste consentito in un determinato intervallo. Il limite può essere applicato da WordPress, da un plugin, dal web server, dalla CDN o da un servizio API.
Questa guida approfondisce errore 429 Too Many Requests con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.
Che cosa significa
Il codice 429 è normalmente temporaneo. La risposta può includere l’intestazione Retry-After, che indica quando il client dovrebbe riprovare.
Ripetere immediatamente le richieste aumenta il problema. Occorre identificare chi genera il traffico e quale livello applica la limitazione.
Come riconoscere il problema
- Login o API restituiscono 429.
- Solo un IP o una rete è coinvolta.
- Il problema compare dopo scansioni, crawler o importazioni.
- Un plugin effettua molte richieste AJAX o REST.
- La risposta contiene Retry-After.
Cause più frequenti
1. Bot o crawler aggressivo
Un sistema automatico visita troppe URL o non rispetta intervalli ragionevoli. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
2. Tentativi di accesso ripetuti
Login falliti o protezioni brute force possono limitare l’IP. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
3. Plugin in loop
Cron, AJAX, webhook o chiamate REST possono ripetersi senza controllo. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
4. API con quota
Servizi esterni applicano limiti per chiave, utente o intervallo. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
5. Cache assente
Ogni richiesta raggiunge PHP e aumenta rapidamente il carico. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
6. Regola CDN o WAF
Rate limiting e protezioni possono essere più restrittivi del previsto. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
Diagnosi passo per passo
- Leggi intestazioni e corpo. Individua Retry-After, server, ray id o identificativi della regola. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla access log. Cerca IP, user agent, URL e frequenza delle richieste. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Verifica attività WordPress. Controlla cron, Heartbeat, admin-ajax, REST API e plugin recenti. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Confronta reti differenti. Determina se il limite è per IP o globale. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla CDN e firewall. Esamina regole rate limiting, bot protection e log degli eventi. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Verifica la quota API. Consulta il pannello del servizio esterno e i relativi contatori. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Riduci il test. Ferma crawler o automazioni e attendi il tempo indicato. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
Metodo sicuro di intervento
Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.
Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.
Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.
Procedura di risoluzione
- Rispetta Retry-After. Il client deve attendere e applicare backoff progressivo. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Correggi il loop. Riduci chiamate AJAX, webhook o cron che si ripetono. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Limita i bot in modo selettivo. Usa robots, regole CDN o firewall senza bloccare motori legittimi. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Aggiungi cache. Riduci le richieste che arrivano a PHP quando il contenuto è cacheabile. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Ottimizza login e API. Applica limiti coerenti e autenticazione corretta. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Rivedi la regola. Modifica soglia, finestra o percorso soltanto dopo aver analizzato i log. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Monitora dopo la correzione. Verifica che il traffico diminuisca e che non compaiano 429 legittimi. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
Controlli finali
- Le richieste legittime non ricevono 429.
- I bot anomali sono ridotti.
- Nessun plugin genera loop.
- Retry-After viene rispettato.
- Le regole di sicurezza restano attive.
Prevenzione
- Usa backoff nelle integrazioni.
- Monitora access log.
- Configura cache e CDN.
- Limita login e API.
- Aggiorna plugin che generano traffico anomalo.
Errori da evitare
- Non disattivare tutte le protezioni.
- Non ricaricare continuamente.
- Non aumentare la soglia senza log.
- Non bloccare indiscriminatamente interi paesi o reti.
- Non ignorare automazioni compromesse.
Come documentare la verifica
Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.
Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.
Controllo incrociato
Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.
Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- URL
- IP pubblico
- orario
- intestazioni della risposta
- user agent o applicazione coinvolta
Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.
Fonti tecniche ufficiali
Domande frequenti su errore 429 Too Many Requests
Quanto dura un errore 429?
Dipende dalla finestra del limite; controlla l’intestazione Retry-After quando presente.
Svuotare la cache del browser risolve?
No, se il limite è applicato all’IP, all’account o al server.
Un plugin WordPress può causarlo?
Sì, soprattutto con loop AJAX, REST, cron o chiamate esterne.
Devo disattivare il firewall?
No. Bisogna identificare e correggere la regola o il traffico responsabile.
Perché funziona da rete mobile?
Il limite può essere associato all’indirizzo IP della rete originale.