Proxy a rotazione: come funziona la rotazione IP e quando interrompe il lavoro

Uno script di monitoraggio prezzi controllava ogni notte centinaia di pagine senza problemi da mesi. Poi aumentò la frequenza e fu aggiunto un secondo negozio e i log si riempirono di risposte 429 e CAPTCHA. Nei forum consigliano un proxy a rotazione. L’idea che più IP significhino meno blocchi è vera solo a metà.

Il proxy invia le richieste tramite IP variabili dietro un gateway fisso, distribuendo il traffico sotto un limite per IP. L’indirizzo può però cambiare durante l’accesso e spesso la sessione autenticata non sopravvive. Si risolve un problema creandone un altro.

La versione breve

• Un proxy a rotazione espone un gateway, con host e porta, e inoltra le richieste tramite IP scelti da un pool. Una regola decide quando cambiano.
• La rotazione per richiesta serve per attività senza stato, come scaricare pagine pubbliche. Per accessi e carrelli preferisci sessioni persistenti o proxy statici, soprattutto se il sito controlla la continuità dell’IP.
• Un pool può ruotare correttamente e fallire: gli altri clienti consumano la reputazione degli IP condivisi. Contano più indirizzi freschi e poco condivisi che la dimensione del pool.
• La rotazione non aggira limiti associati ad account, token o cookie. Per piccoli volumi, rallenta e rispetta Retry-After, che indica quanto aspettare.

Cos’è un proxy a rotazione?

Il gateway inoltra ogni richiesta tramite un IP del pool. La regola ne determina il cambio: per richiesta, a tempo o per sessione. Host e porta restano uguali; il gateway sceglie l’indirizzo visto dal destinatario.

Segui una richiesta attraverso il gateway:

1. Il client invia sempre la richiesta allo stesso host e porta del gateway.
2. Il gateway applica la regola e sceglie un IP dal pool.
3. La richiesta parte da quell’IP e raggiunge il sito.
4. Il destinatario vede l’IP di uscita. Il tuo resta nascosto salvo inoltro tramite intestazioni come X-Forwarded-For.

Pool, controlli di disponibilità e failover sono gestiti dal fornitore; lo script conosce solo host e porta. Questa comodità spiega il servizio. Un proxy autogestito non offre rotazione gratuita: normalmente fornisce un IP di uscita stabile; pagheresti un terzo proprio per mantenere il pool.

I fornitori chiamano gateway e pool proxy backconnect. La guida MDN ai server proxy indica «gateway» come altro nome, più semplice, del forward proxy. Il tipo di IP, residenziale, datacenter o mobile, è distinto dalla frequenza di rotazione.

Cosa decide quando cambia il tuo IP?

Dipende dalla regola e dal fornitore: nuova IP per richiesta o connessione, finestra temporale o comando esplicito. Client e gestori possono ruotare prima di riprovare richieste fallite o bloccate. Verifica «per richiesta»: più richieste HTTPS possono condividere tunnel e IP. Un gateway che inoltra HTTPS cifrato normalmente non legge lo stato del destinatario per avviare autonomamente la rotazione.

È una scelta di allocazione: distribuire tiene ogni IP sotto la soglia, mentre la continuità permette di riconoscere il visitatore. La rotazione per richiesta privilegia tutta la distribuzione. Quella su errore sembra un compromesso, ma nasconde i costi: i log mostrano tentativi riusciti finché non funziona più nulla. La sessione persistente inverte lo scambio mantenendo un IP per un periodo.

Come differisce una sessione persistente dalla rotazione o da un proxy statico?

La sessione persistente riserva temporaneamente un IP del pool per far apparire le richieste dello stesso visitatore, poi lo libera. Il proxy statico mantiene un IP finché lo conservi. La rotazione per richiesta non riserva nulla. Scegli in base al bisogno del sito di riconoscerti.

Per richieste senza stato si usa normalmente la rotazione; con accesso servono le due opzioni che mantengono l’IP, scelte secondo durata. La sessione prende in prestito un indirizzo dal pool e lo restituisce; lo statico resta assegnato e un accesso quotidiano dalla stessa IP sembra un visitatore abituale. Ogni fornitore definisce la finestra: confrontala col flusso più lungo. Controlla anche i guasti: alcuni cambiano IP prima della scadenza, mentre le modalità rigorose a IP unico fanno fallire la richiesta. Una finestra sufficiente da sola non garantisce continuità.

Quando la rotazione interrompe un’attività?

Cambiare IP durante accessi, 2FA, carrelli, pagamenti e moduli multipasso può interromperli. Il cookie non diventa automaticamente invalido, ma i siti che vincolano la sessione all’IP o rilevano frodi nei cambi di rete possono disconnettere, chiedere verifiche o segnalare la sessione.

Non considero questo un attacco ai proxy, ma il sito che fa il suo lavoro. Il cookie dichiara che è lo stesso browser entrato un minuto prima; l’IP è una prova verificabile. Cambiare rete a sessione autenticata somiglia al riuso di un cookie rubato altrove, proprio ciò che rilevano i sistemi antifrode. Disconnessione e 2FA sono risposte proporzionate.

Le indicazioni OWASP sulla gestione delle sessioni descrivono il controllo di cambiamenti di IP e User-Agent. Secondo le protezioni, un cambio inatteso può generare allarmi o terminare la sessione.

La domanda decisiva: il sito deve ricordarti fra due richieste? Se sì, mantieni un IP per il flusso; altrimenti ruota. Controllare prezzi pubblici di notte non lo richiede. Accedere a un pannello per esportare report richiede una sola IP dall’inizio alla fine.

Consiglio: Separa i carichi misti: pool a rotazione per dati senza stato, IP persistente o statico per accesso e attività autenticate. Le esigenze opposte richiedono regole diverse.

Perché un pool smette di funzionare dopo pochi giorni?

Può fallire con rotazione corretta: cambia l’IP, non la reputazione. Gli indirizzi condivisi ereditano l’attività precedente e l’uso intenso sugli stessi siti può farli segnalare e ridurre i successi.

È una risorsa comune limitata: ogni cliente consuma la reputazione del pool presso i siti. Se altri usano gli stessi indirizzi sui tuoi obiettivi, paghi in CAPTCHA e blocchi. Nel supporto ho visto la reputazione comportarsi come un ecosistema di siti e liste di blocco che reagiscono all’attività osservata.

La dimensione del pool, facile da pubblicizzare, predice meno del previsto. Il risultato dipende da:

• Ultimo uso sullo stesso sito: un IP usato da un altro cliente un’ora fa arriva già conteggiato.
• Quanti clienti lo condividono: più attività, maggiore usura.
• Diversità delle reti: IP concentrati in pochi intervalli possono essere bloccati insieme.
• Segnalazioni esistenti: un pool che conserva IP giudicati abusivi continua ad assegnarli.

Un grande pool molto riutilizzato può rendere peggio di uno piccolo con indirizzi nuovi per i tuoi obiettivi. Confronta i successi nel tempo sui tuoi siti; un primo test riuscito non dimostra prestazioni durature.

Ti serve davvero un proxy a rotazione?

Può distribuire richieste sotto limiti per IP, senza sostituire il rispetto di limiti e istruzioni. Secondo il riferimento MDN sul 429, i limiti sono spesso per IP, ma con autenticazione o cookie possono seguire utenti o applicazioni. Un limite per account ignora nuove IP; per piccoli volumi rispetta prima Retry-After.

La norma è RFC 6585, che definì il codice 429. Consente l’intestazione Retry-After per indicare l’attesa, lasciando aperti identificazione e conteggio. Come esempio cita credenziali di autenticazione o cookie con stato.

Tre acquisti sbagliati: limiti per account, token API o cookie, dove tutte le IP consumano la stessa quota e restano i 429; piccoli lavori che possono distanziare centinaia di pagine notturne, attendere Retry-After e riprovare con backoff esponenziale senza costi; attività autenticate che richiedono identità stabile e IP fisso.

La rotazione serve con limiti per IP, valore legato al volume e richieste indipendenti entro l’uso consentito. Restano valide le condizioni del sito. Inoltre contano identificazione del client a livello di connessione e ritmo delle richieste: ruotare non garantisce accesso.

Prima di pagare, leggi documentazione e intestazioni. Se richieste autenticate comparabili ricevono 429 mentre quelle anonime dallo stesso IP riescono, ciò suggerisce ma non prova un limite legato all’account o all’autenticazione. Se falliscono entrambe, può essere per IP, risorsa o intero server. Mantieni endpoint e frequenza comparabili e rispetta Retry-After prima di riprovare.

Domande frequenti