La rotazione è la caratteristica più potente del residential proxy — e anche quella configurata più spesso in modo sbagliato. Il valore predefinito "cambia IP a ogni richiesta" nella maggior parte degli scenari calail tasso di successo, perché non è così che appare il comportamento naturale di un utente.
In questo articolo affrontiamo i trigger di rotazione, la scelta della strategia per destinazione e il motivo per cui una rotazione eccessiva è dannosa.
Tre modelli di rotazione
Il terzo modello è la combinazione dei due: funziona sostanzialmente in base al risultato, ma impone un limite massimo (per esempio 50 richieste al massimo) per evitare di sovraccaricare l'IP.
Quando bisogna ruotare?
Cambiare IP dopo una richiesta andata a buon fine significa sprecare una risorsa funzionante che hai in mano. Usa la rotazione come strumento di correzione , non come comportamento predefinito.
Perché una rotazione eccessiva è dannosa?
Un utente reale non cambia IP mentre naviga su un sito. Un "utente" che a ogni richiesta arriva da un Paese diverso è un segnale estremamente evidente per i sistemi di analisi comportamentale. Inoltre:
- Cookie e session si rompono: Carrello, filtri e preferenze di lingua vanno persi.
- Si perde il riuso della session TLS: Ogni nuovo IP significa un nuovo handshake — lento e costoso.
- La paginazione diventa incoerente: Uscite diverse possono vedere varianti A/B diverse o prezzi diversi.
- La quota si esaurisce in fretta: Ogni handshake significa qualche KB di traffico aggiuntivo.
Riutilizzare la connessione sullo stesso IP è tre-quattro volte più veloce rispetto alla rotazione a ogni richiesta. La rotazione è uno strumento che ha un costo in termini di velocità.
Strategia per destinazione
Un'unica impostazione di rotazione non può essere corretta per tutte le destinazioni. Definisci profili diversi in base al livello di protezione della destinazione:
| Tipo di destinazione | Durata sticky | Richieste per IP | Trigger di rotazione |
|---|---|---|---|
| Contenuto non protetto | Superfluo | 100+ | Solo in caso di errore |
| Marketplace a protezione media | 3–5 min | 20–40 | Errore + limite massimo |
| Grande marketplace | 1–2 min | 5–10 | Errore + breve durata |
| Operazione che richiede il login | 15–30 min | Per tutta la session | Solo a fine session |
Prendi questa tabella come punto di partenza, poi misura. Se il tasso di successo è superiore al 95%, puoi aumentare gradualmente il numero di richieste per IP e ridurre i costi. Se scende sotto l'85%, torna indietro.
Implementazione: logica di rotazione adattiva
Questa struttura combina due trigger: rotazione immediata in caso di errore, altrimenti al raggiungimento del limite massimo. Le richieste andate a buon fine non sprecano IP.
Il rapporto tra rotazione e concorrenza
La rotazione da sola non basta. Se invii 50 richieste contemporaneamente e tutte usano IP diversi, la destinazione noterà comunque in breve tempo il traffico intenso. La rotazione distribuisce l'identità , non la velocità .
Definisci per ogni destinazione un profilo separato di velocità e concorrenza. Un'unica impostazione globale brucia la destinazione più sensibile oppure rallenta quella più tollerante.
Per il calcolo della concorrenza vedi il nostro articolo sul limite di connessioni simultanee consultalo.
Misurare l'impostazione di rotazione
L'unico modo per trovare l'impostazione giusta è misurare. Le tre metriche da monitorare:
Leggi le tre metriche insieme. Se riesci a ridurre il rapporto IP/richiesta mantenendo costante il tasso di successo, hai ridotto direttamente i tuoi costi.
Riepilogo
La rotazione non è un comportamento predefinito, ma uno strumento correttivo. Cambiare IP dopo richieste andate a buon fine spreca sia velocità sia budget e non appare naturale. La configurazione corretta combina un trigger basato sul risultato con un limite massimo ragionevole; definisce profili per destinazione e affronta la rotazione insieme alla gestione della velocità. Per testare la tua implementazione controllo proxy, per le opzioni di prodotto rotating proxy del nostro sito.