← Torna al blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Errore "Too Many Requests" 429: come superare i limiti tramite proxy e rotazione IP

Analizziamo le cause dell'errore 429 Too Many Requests e mostriamo 5 modi per aggirare i limiti tramite proxy: dalla rotazione degli IP alla configurazione dell'User-Agent e ai ritardi tra le richieste.

📅31 dicembre 2025
```html

Se ti occupi di parsing di marketplace, monitoraggio dei prezzi dei concorrenti o automazione del lavoro con i social media, sicuramente ti sei imbattuto nell'errore 429 Too Many Requests. Il sito blocca le tue richieste, considerandole sospette, e tutta l'automazione si ferma. In questo articolo analizzeremo perché si verifica questo problema e come risolverlo tramite la corretta configurazione dei proxy, rotazione degli IP e distribuzione intelligente del carico.

Mostreremo soluzioni specifiche per diverse attività: parsing di Wildberries e Ozon, monitoraggio dei concorrenti, lavoro con API dei social media, raccolta di dati in massa. Tutte le raccomandazioni si basano su esperienze pratiche e funzionano in progetti reali.

Che cos'è l'errore 429 Too Many Requests e perché si verifica

L'errore 429 Too Many Requests è un codice di risposta HTTP che il server restituisce quando superi il numero consentito di richieste in un determinato periodo di tempo. Questo è un meccanismo di protezione dei siti contro il sovraccarico e la raccolta automatizzata di dati.

Situazioni tipiche in cui si verifica il 429:

  • Parsing di marketplace — stai raccogliendo prezzi da Wildberries, Ozon o Avito, facendo centinaia di richieste al minuto. Il sito vede un'attività anomala da un IP e lo blocca.
  • Monitoraggio dei concorrenti — raccolta automatica di dati su prodotti, prezzi, disponibilità. Con controlli frequenti scatta il limite.
  • Lavoro con API — molte API hanno restrizioni rigide: ad esempio, l'API di Instagram consente 200 richieste all'ora, Twitter — 300 richieste ogni 15 minuti.
  • Registrazione o azioni di massa — creazione di account, invio di messaggi, like. Le piattaforme identificano rapidamente l'automazione e bloccano l'IP.

È importante capire: l'errore 429 non è solo una limitazione tecnica. È un segnale che il sito ha riconosciuto la tua attività come sospetta. Se continui ad attaccare dallo stesso IP, potresti ricevere un ban permanente.

Importante: Alcuni siti invece di 429 restituiscono 403 Forbidden o mostrano semplicemente un captcha. La sostanza è la stessa: hai superato i limiti e sei stato bloccato.

Come i siti identificano l'attività sospetta

Per aggirare efficacemente i blocchi, è necessario capire come i siti ti identificano. I moderni sistemi di protezione analizzano molti parametri:

1. Indirizzo IP e frequenza delle richieste

Il parametro più ovvio. Se da un IP arrivano 100 richieste al minuto, mentre un utente normale ne fa 5-10 — questa è un'evidente automazione. I siti stabiliscono limiti:

  • Wildberries: circa 60 richieste al minuto da un IP
  • Ozon: circa 30-40 richieste al minuto
  • Avito: limiti rigidi, soprattutto per le richieste di ricerca
  • API di Instagram: 200 richieste all'ora per applicazione

2. User-Agent e intestazioni del browser

Se invii richieste tramite uno script senza un corretto User-Agent, il sito capisce subito che non si tratta di un browser reale. Vengono anche analizzate le intestazioni: Accept, Accept-Language, Referer. L'assenza di queste intestazioni o valori atipici è un segnale di allerta.

3. Modelli comportamentali

Un utente reale non fa richieste con una periodicità perfetta ogni 2 secondi. Scorre, clicca, fa pause. Se il tuo parser funziona come un metronomo — è sospetto.

4. Tipo di indirizzo IP

Molte piattaforme mantengono liste nere di IP dei data center. Se utilizzi proxy economici da AWS o Google Cloud, la probabilità di blocco è più alta. Gli IP residenziali di fornitori reali suscitano meno sospetti.

Rotazione dei proxy: il principale modo per aggirare i limiti

La principale soluzione al problema 429 è la rotazione degli indirizzi IP. Invece di fare tutte le richieste da un solo IP, distribuisci il carico tra molti indirizzi. Ogni IP fa un numero ridotto di richieste e non supera i limiti.

Tipi di rotazione dei proxy

Tipo di rotazione Come funziona Quando utilizzare
Rotazione su richiesta Ogni richiesta proviene da un nuovo IP. Il provider di proxy cambia automaticamente l'indirizzo. Parsing di massa, quando è necessario raccogliere molti dati rapidamente
Rotazione a timer L'IP cambia ogni 5-30 minuti. Utilizzi un indirizzo per una serie di richieste. Lavoro con siti che richiedono sessioni (carrello, autorizzazione)
Pool di proxy statici Hai un elenco di 100-1000 IP. Lo script sceglie casualmente un indirizzo per ogni richiesta. Quando è necessario un controllo completo sulla rotazione e distribuzione del carico

Esempio pratico: parsing di Wildberries

Supponiamo che tu debba fare il parsing dei prezzi di 10.000 prodotti. Wildberries blocca dopo 60 richieste al minuto da un IP. Come risolvere:

  1. Utilizza la rotazione su richiesta — ogni richiesta proviene da un nuovo IP. Ti servono circa 167 IP diversi (10.000 richieste / 60 al minuto = 167 minuti con un IP, ma con la rotazione lo fai in 10-15 minuti).
  2. Imposta i ritardi — anche con la rotazione non dovresti fare 1000 richieste al secondo. Ottimale: 5-10 richieste al secondo con IP diversi.
  3. Aggiungi randomizzazione — i ritardi devono essere casuali: da 0,5 a 2 secondi tra le richieste.

Per tali compiti sono ideali i proxy residenziali con rotazione automatica — hanno pool di milioni di IP e cambiano indirizzi per ogni richiesta senza il tuo intervento.

Impostazione dei ritardi tra le richieste

Anche con la rotazione dei proxy non puoi bombardare il sito con richieste alla massima velocità. I moderni sistemi di protezione analizzano il carico totale sul server e possono bloccare l'intero range di IP se vedono un'attività simile a un DDoS.

Regole per l'impostazione dei ritardi

Regola base: imita un utente reale

  • Ritardo minimo: 0,5-1 secondo tra le richieste
  • Raccomandato: 1-3 secondi con dispersione casuale
  • Per siti complessi (marketplace, social media): 2-5 secondi
  • Utilizza ritardi esponenziali in caso di errori

Ritardo esponenziale (exponential backoff)

Se hai comunque ricevuto l'errore 429, non continuare ad attaccare il sito. Utilizza la strategia del ritardo esponenziale:

  • Primo tentativo non riuscito → aspetta 1 secondo
  • Secondo tentativo non riuscito → aspetta 2 secondi
  • Terzo tentativo non riuscito → aspetta 4 secondi
  • Quarto tentativo non riuscito → aspetta 8 secondi
  • E così via, fino a un massimo (ad esempio, 60 secondi)

Questa strategia dà al server il tempo di "raffreddarsi" e riduce la probabilità di un ban permanente. Molte API (Google, Twitter) raccomandano proprio questo approccio nella loro documentazione.

Esempio di impostazione per diverse attività

Attività Ritardo tra le richieste Commento
Parsing di Wildberries 1-3 secondi Con la rotazione dei proxy si può accelerare fino a 0,5-1 sec
Parsing di Ozon 2-4 secondi Ozon è più sensibile all'automazione
API di Instagram 18 secondi Limite 200 richieste/ora = 1 richiesta ogni 18 sec
Parsing di Google Search 5-10 secondi Google banna rapidamente, servono pause lunghe
Monitoraggio di Avito 3-6 secondi Protezione rigida, soprattutto per la ricerca

User-Agent e intestazioni: imitazione di un browser reale

La rotazione dei proxy e i ritardi risolvono il problema della frequenza delle richieste, ma non è sufficiente. I siti analizzano come invii le richieste. Se le intestazioni sembrano sospette — il blocco è inevitabile.

Intestazioni obbligatorie per imitare un browser

Il set minimo di intestazioni che deve essere presente in ogni richiesta: 

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0

Rotazione dell'User-Agent

Non utilizzare lo stesso User-Agent per tutte le richieste. Crea un elenco di 10-20 versioni attuali dei browser e cambiale casualmente:

  • Chrome (Windows, macOS, Linux)
  • Firefox (diverse versioni)
  • Safari (macOS, iOS)
  • Edge (Windows)

Errore comune: Utilizzare User-Agent obsoleti (ad esempio, Chrome 90 nel 2024) o User-Agent mobili per siti desktop. Questo rivela immediatamente l'automazione.

Referer e Origin

Molti siti controllano da dove proviene la richiesta. Se stai facendo il parsing di una pagina prodotto, nell'intestazione Referer deve esserci un link al catalogo o alla ricerca. Se fai il parsing di un'API — deve esserci il corretto Origin.

Esempio per il parsing di Wildberries: 

Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=notebook
Origin: https://www.wildberries.ru

Quali proxy scegliere per aggirare il 429

La scelta del tipo di proxy è critica. I proxy economici dei data center sono spesso già nelle liste nere, e riceverai 429 anche con una bassa frequenza di richieste.

Confronto dei tipi di proxy per aggirare i limiti

Tipo di proxy Vantaggi Svantaggi Per quali attività
Data center Alta velocità, basso costo Spesso bannati, facilmente identificabili Siti semplici senza protezione
Residenziali IP reali dei fornitori, difficile da identificare, grande pool di indirizzi Più costosi, a volte più lenti Marketplace, social media, siti complessi
Mobili IP degli operatori mobili, massimo affidamento Costosi, pool limitato Instagram, TikTok, Facebook Ads

Raccomandazioni per la scelta

Per il parsing di marketplace (Wildberries, Ozon, Avito): Utilizza proxy residenziali con rotazione su richiesta. Il pool deve essere grande — almeno 10.000 IP. Questo garantisce che ogni IP faccia poche richieste e non rientri nei limiti.

Per lavorare con API dei social media: I proxy mobili sono la scelta ottimale. Instagram e TikTok si fidano di più degli IP degli operatori mobili rispetto a quelli residenziali. Un IP mobile può gestire 5-10 account senza problemi.

Per monitorare i prezzi dei concorrenti: Proxy residenziali con rotazione a timer (ogni 10-15 minuti). Questo consente di fare una serie di richieste da un IP, mantenendo la sessione, ma senza superare i limiti.

Per attività semplici (parsing di notizie, blog): I proxy dei data center possono andare bene se il sito non ha una protezione seria. Ma preparati a blocchi periodici.

Casi reali: parsing di marketplace e API

Caso 1: Monitoraggio dei prezzi su Wildberries (10.000 prodotti al giorno)

Attività: Un venditore di marketplace monitora i prezzi dei concorrenti su 10.000 articoli. È necessario raccogliere dati 2 volte al giorno.

Problema: Utilizzando un solo IP riceveva un ban dopo 50-60 richieste. Il parsing di 10.000 articoli richiedeva diverse ore con continui blocchi.

Soluzione:

  1. Collegato proxy residenziali con un pool di 50.000 IP e rotazione su richiesta
  2. Impostato ritardi casuali da 0,5 a 2 secondi tra le richieste
  3. Aggiunto rotazione dell'User-Agent (20 varianti di Chrome e Firefox)
  4. Impostate correttamente le intestazioni Referer e Accept

Risultato: Il parsing di 10.000 articoli richiede 15-20 minuti senza un singolo blocco. Ogni IP fa al massimo 1-2 richieste, il che è impossibile da identificare come automazione.

Caso 2: Automazione di Instagram (50 account clienti)

Attività: Un'agenzia SMM gestisce 50 account clienti su Instagram. È necessario pubblicare contenuti, rispondere ai commenti, raccogliere statistiche.

Problema: L'API di Instagram ha un limite di 200 richieste all'ora per applicazione. Lavorando con 50 account, i limiti si esaurivano in 10 minuti.

Soluzione:

  1. Creato 10 diverse applicazioni API di Instagram (5 account per applicazione)
  2. Ogni applicazione utilizza un proxy mobile separato
  3. Impostato un ritardo di 18 secondi tra le richieste (200 richieste/ora = 1 richiesta ogni 18 sec)
  4. Aggiunta di ritardi esponenziali in caso di ricezione del 429

Risultato: Tutti i 50 account funzionano stabilmente. Gli errori 429 si verificano molto raramente (1-2 volte a settimana) e vengono gestiti automaticamente tramite tentativi ripetuti.

Caso 3: Parsing di Avito (annunci in tutta la Russia)

Attività: Un aggregatore immobiliare raccoglie annunci da Avito in tutte le città della Russia per il proprio database.

Problema: Avito ha una delle protezioni più rigide tra i siti russi. I blocchi iniziavano dopo 10-15 richieste anche da diversi IP dei data center.

Soluzione:

  1. Passaggio a proxy residenziali con geolocalizzazione (IP dalla stessa città in cui si fa il parsing)
  2. Aumento dei ritardi a 3-5 secondi tra le richieste
  3. Utilizzo di un browser headless (Puppeteer) invece di semplici richieste HTTP
  4. Imitazione delle azioni dell'utente: scrolling, clic, movimenti del mouse

Risultato: Parsing di oltre 50.000 annunci al giorno. I blocchi sono diminuiti del 95%. I restanti 5% vengono gestiti tramite tentativi ripetuti con un nuovo IP.

Caso 4: Monitoraggio delle API dei concorrenti (e-commerce)

Attività: Un negozio online monitora la disponibilità dei prodotti e i prezzi di 20 concorrenti tramite le loro API.

Problema: La maggior parte delle API dei concorrenti ha limiti pubblici (100-500 richieste all'ora). Quando si supera il limite, restituisce 429.

Soluzione:

  1. Creazione di una coda di richieste con priorità (i prodotti più importanti vengono controllati più frequentemente)
  2. Monitoraggio dei limiti tramite le intestazioni di risposta (X-RateLimit-Remaining)
  3. Pausa automatica al raggiungimento dell'80% del limite
  4. Utilizzo di più chiavi API per ogni concorrente (dove possibile)

Risultato: Il sistema distribuisce automaticamente le richieste in modo da non superare mai i limiti. I dati vengono aggiornati con la massima frequenza possibile senza blocchi.

Lezione generale da tutti i casi:

L'errore 429 si risolve in modo complesso: rotazione dei proxy + ritardi corretti + imitazione del comportamento reale. Non puoi fare affidamento solo su un metodo. Anche con un milione di IP verrai bloccato se fai 1000 richieste al secondo con intestazioni sospette.

Conclusione

L'errore 429 Too Many Requests è un meccanismo di protezione dei siti che può essere aggirato con il giusto approccio. I principali principi per risolvere il problema:

  • Rotazione degli indirizzi IP — distribuisci il carico tra molti proxy, affinché ogni indirizzo faccia il minimo di richieste
  • Ritardi corretti — imita un utente reale con pause casuali da 1 a 5 secondi
  • Intestazioni corrette — utilizza User-Agent attuali e un set completo di intestazioni del browser
  • Scelta del tipo di proxy — per siti complessi (marketplace, social media) utilizza proxy residenziali o mobili
  • Gestione degli errori — applica ritardi esponenziali in caso di ricezione del 429, non attaccare nuovamente il sito

Ricorda: l'obiettivo non è ingannare la protezione a tutti i costi, ma far sembrare la tua automazione il più naturale possibile. I moderni sistemi di protezione stanno diventando sempre più intelligenti, e la forza bruta smette di funzionare.

Se intendi lavorare con il parsing di marketplace, monitoraggio dei concorrenti o automazione sui social media, ti consigliamo di provare i proxy residenziali — offrono un ampio pool di indirizzi IP, rotazione automatica e rischio minimo di blocchi. Per lavorare con Instagram, TikTok e altre piattaforme mobili, i proxy mobili con IP di veri operatori di telecomunicazioni sono la scelta migliore.

```