Proxy sticky e a rotazione: come funziona il controllo di sessione
Proxy sticky e a rotazione: come funzionano la rotazione a ogni richiesta e quella a timer, quando una sessione sticky batte un IP nuovo, come i cookie interagiscono con il cambio di IP e come testare un ID di sessione da sé.
Gli IP a rotazione spargono le richieste su un pool. Le sessioni sticky cercano di tenere un indirizzo per una finestra. Questa guida è per chi compra accesso proxy per scraping, lavoro sugli account o QA e deve scegliere una modalità di sessione. Top Proxy è un catalogo di confronto: non vendiamo IP e non diamo chiavi gratis. Spieghiamo la meccanica e la indirizziamo verso fornitori che lei può verificare.
Il controllo di sessione è distinto da dove arriva l'IP. Un pool residenziale può ruotare o tenere. Un pool mobile può fare lo stesso. Un piano datacenter si vende spesso come indirizzo statico per il periodo di noleggio, anche se i termini precisi dipendono dal prodotto. Chi compra mescola queste parole e poi si chiede perché un checkout muore a metà.
01A rotazione, sticky e statico: tre comportamenti diversi
Questi termini si usano come se fossero sinonimi. Descrivono cose diverse.
| Modalità | Che cosa fa il gateway | Chi controlla il cambio | Uso tipico |
|---|---|---|---|
| A rotazione per richiesta | Sceglie un'uscita dal pool per ogni connessione o richiesta; può anche restituire lo stesso indirizzo | Il gateway | Fetch di pagine indipendenti, liste di URL ampie |
| A rotazione a timer | Sceglie una nuova uscita dal pool quando scade un intervallo; la scelta può ripetersi | Impostazione del fornitore o un parametro suo | Flussi brevi che tollerano un cambio a metà corsa |
| Sessione sticky | Cerca di tenere la stessa uscita finché lei invia lo stesso ID di sessione | Lei, tramite l'ID di sessione | Login, carrelli, moduli in più passaggi, risultati paginati legati ai cookie |
| Statico | Mira a tenere lo stesso indirizzo tra una sessione e l'altra per il periodo di noleggio | I termini del prodotto | Account di lunga durata, allowlist |
| Dedicato | Riserva un indirizzo (statico o no) al solo suo uso | I termini del prodotto | Casi in cui il problema è l'uso condiviso dell'IP |
La colonna importante è la terza. Con la rotazione per richiesta lei non fa nulla e il gateway sceglie di nuovo, il che di solito ma non sempre significa un IP diverso. Con una sessione sticky invia un segnale a ogni richiesta e il fornitore cerca di rispettarlo. Statico descrive la continuità dell'indirizzo; dedicato descrive l'esclusività. Nessuno dei due è una promessa contro interruzioni o riassegnazioni, che restano soggette al prodotto e al contratto.
Esempio schematico di come un gateway tratta le richieste con e senza ID di sessione. È un diagramma editoriale, non dati di rete misurati; durate reali e failover dipendono dal fornitore.
02Come funziona la rotazione: per richiesta o a timer
Un gateway a rotazione è un hostname e una porta davanti a un pool grande. Ogni volta che parte una nuova sessione, il gateway sceglie un'uscita da quel pool. Senza una chiave di sessione, molti gateway residenziali trattano ogni connessione come nuova, quindi richieste consecutive possono uscire da indirizzi diversi, anche se il pool può restituirle un indirizzo appena usato. Il default esatto cambia da fornitore a fornitore: legga la pagina del prodotto invece di dare per scontato.
La rotazione per richiesta va bene per i lavori in cui ogni fetch sta in piedi da solo: pagine prodotto, documentazione pubblica, risultati di ricerca, snapshot di prezzo. Il sito non dovrebbe aver bisogno che la richiesta successiva parta dalla stessa casa. È questo che la maggior parte delle persone intende per rotazione dei proxy nello scraping.
La rotazione a timer sta in mezzo. L'uscita dovrebbe tenersi per un numero fisso di minuti, poi il gateway sceglie di nuovo. Alcuni fornitori lo espongono come un intervallo di porte, altri come un parametro nel nome utente. Riduce quante volte la destinazione vede un indirizzo nuovo, ma lei non controlla l'istante del cambio, quindi un flusso che attraversa il confine può comunque rompersi.
La rotazione non nasconde un client rumoroso. Se il crawler spara una raffica di richieste, la destinazione vede comunque una raffica, solo sparsa su più indirizzi. Limiti di frequenza, concorrenza ragionevole e una logica di retry educata restano nel suo codice.
03Sessioni sticky e IP statico
Una sessione sticky la fissa a un'uscita per una finestra, o finché lei non cambia l'ID di sessione. I fornitori di solito la codificano nel nome utente del proxy. Due esempi documentati mostrano quanto variano i dettagli:
- I proxy residenziali Oxylabs accettano un valore
sessidnel nome utente, con unsesstimeopzionale in minuti. La loro documentazione sul controllo di sessione dice che una sessione di default dura 10 minuti o termina dopo 60 secondi senza richieste, esesstimepuò estenderla fino a 1440 minuti. Se l'IP va offline, una sessione normale passa a un altro IP e continua; una modalità separatasessid_oneipnon ruota e risponde invece con HTTP 502. - Bright Data aggiunge
-session-<id>al nome utente. Le loro opzioni di configurazione del proxy dicono che ogni ID di sessione univoco ottiene un IP univoco, e un flag-consttiene lo stesso peer, rispondendo 502 con «no peer available» se quel peer cade. La pagina non indica una durata di sessione.
Una sessione sticky è best effort. Il peer può andare offline, un operatore mobile può riassegnare l'indirizzo, e il fornitore decide se cambiare l'uscita o fallire in modo esplicito. Tratti qualsiasi tempo di tenuta come un obiettivo, non come un affitto, e non lo legga come una promessa che un login o un account restino al sicuro.
Sticky non è neanche la stessa cosa di statico o dedicato. Altri clienti possono condividere lo stesso range, e l'indirizzo può tornare nel pool dopo la sua sessione. Se le serve continuità dell'indirizzo, guardi i prodotti statici o ISP; se le serve esclusività, cerchi un'opzione dedicata. Controlli i termini in ogni caso, perché interruzioni e riassegnazioni si gestiscono per prodotto. La guida ISP e residenziali copre quel compromesso.
04Cookie, login e che cosa succede quando cambia l'IP
La maggior parte dei siti segue un visitatore con i cookie, non solo con un IP. Per questo un cambio di IP a metà flusso è rischioso: il cookie dice «stesso utente», la rete dice «posizione diversa». Alcuni siti lo accettano. Altri lo trattano come una sessione rubata, forzano un nuovo login o azzerano un carrello.
Il client HTTP controlla la metà cookie. In Python, un oggetto requests.Session persiste i cookie tra le richieste e riusa le connessioni, secondo la documentazione sull'uso avanzato di Requests. L'ID di sessione del proxy controlla la metà IP. Sono indipendenti. Può tenere i cookie mentre l'IP ruota, o tenere l'IP partendo da un contenitore di cookie vuoto. Scelga la combinazione di proposito:
- Nuovo contenitore di cookie + IP a rotazione: toglie i legami di cookie e di IP tra le richieste. Va bene per un crawl senza stato. È una configurazione, non invisibilità: fingerprint del browser o del client, header e identificatori di account possono comunque correlare le richieste.
- Un contenitore di cookie + IP sticky: sembra un visitatore unico che resta fermo. Va bene per login, carrelli e moduli su più pagine.
- Un contenitore di cookie + IP a rotazione: il mix rischioso. Un sito che lega i cookie a un IP può sollevare una sfida o disconnetterla.
- Nuovo contenitore di cookie + IP sticky: va bene per testare come un sito tratta un indirizzo prima del login.
La rotazione ha anche un costo oltre i cookie: perde qualsiasi reputazione che un indirizzo aveva costruito con il sito, il che su alcune destinazioni significa una nuova sfida a ogni pagina.
Il lavoro sugli account di solito vuole sticky o statico, e spesso un'origine residenziale o mobile. Un IP datacenter a rotazione è la combinazione che molti muri di login si aspettano già dall'automazione.
05Rotazione dei proxy per il web scraping: scegliere la modalità per lavoro
La maggior parte dei crawler reali usa entrambe le modalità. Ruoti sulle pagine di elenco che non hanno bisogno di stato. Passi a una sessione sticky per le pagine di dettaglio, i login o qualsiasi cosa dietro un cookie. Quella suddivisione è un'impostazione del crawler, non una funzione del venditore; il fornitore deve solo esporre entrambe. La guida ai proxy per il web scraping copre il resto della decisione d'acquisto.
| Lavoro | Modalità suggerita | Perché |
|---|---|---|
| Pagine prodotto o di ricerca pubbliche | A rotazione per richiesta | Nessuno stato da tenere, il carico si sparge sulle uscite |
| Monitoraggio prezzi per regione | A rotazione con filtro paese | La posizione conta, la continuità no |
| Login, poi poche pagine | Sticky, tenuta un po' più lunga del flusso | Cookie e IP restano coerenti |
| Checkout o modulo in più passaggi | Sticky, nuovo ID di sessione per ogni esecuzione | Un cambio a metà flusso può azzerare il modulo |
| Profilo browser di lunga durata | Statico o sticky lungo | Servono ore di continuità |
| Allowlist su un'API partner | Statico (dedicato se l'esclusività conta) | L'allowlist ha bisogno di un indirizzo stabile |
Una regola pratica: misuri quanto dura il suo flusso, imposti la finestra sticky un po' più lunga e generi un nuovo ID di sessione quando il flusso finisce. Tenere una sessione più a lungo del necessario la lascia su un indirizzo che può essere già segnalato.
Esempio svolto (numeri ipotetici). Dica che un login più sei pagine di dettaglio richiede circa 4 minuti nei suoi log, e un passaggio aspetta circa 90 secondi perché si costruisca un report. Rispetto al default documentato di Oxylabs (10 minuti, oppure 60 secondi senza richieste), il totale ci sta, ma il vuoto di 90 secondi supererebbe il limite di inattività, quindi la sessione potrebbe chiudersi a metà flusso. Le correzioni sono impostare un sesstime più lungo e controllare come quel fornitore tratta i vuoti di inattività, oppure tenere le richieste in movimento durante l'attesa. Altri fornitori usano limiti diversi, quindi rifaccia questo calcolo con i valori che documentano.
Se ha dubbi, esegua un controllo: stesso set di URL, stessa origine IP, due modalità di sessione. Prima di partire, decida che cosa registrare per ogni esecuzione:
Registri questo → Perché conta
- 01ID di sessione e timestamp per richiestaPermette di legare i cambi di IP ai vuoti di inattività o alla scadenza
- 02IP di uscita e paeseMostra rotazione, sticky e deriva del pool
- 03Protocollo (HTTP o SOCKS5)Tiene il protocollo distinto dall'origine IP
- 04Stato HTTP e pagine di sfidaSepara gli errori del proxy dalle difese del sito
- 05Stato dei cookie o del login dopo ogni passoMostra se un flusso è sopravvissuto a un cambio di IP
Tenga la modalità che completa il lavoro.
I filtri paese restano validi anche in rotazione. Un pool USA a rotazione dovrebbe restare negli Stati Uniti, ma i pool misti possono derivare, quindi controlli a campione il paese su alcune richieste.
06Come testare una sessione sticky con una serie di richieste
Non si fidi della sola pagina prodotto. Invii lo stesso ID di sessione più volte, poi invii richieste senza, e registri l'IP di uscita ogni volta. Lo schizzo sotto usa Python Requests. Host del proxy, formato del nome utente e URL echo dell'IP sono segnaposto; li sostituisca con i valori della documentazione del fornitore, perché la sintassi di sessione cambia da un venditore all'altro.
import time
from urllib.parse import quote
import requests
PROXY_HOST = "gw.example-provider.com:7777" # placeholder
USER = "USERNAME" # placeholder
PASSWORD = "PASSWORD" # placeholder, load from your secret store
IP_ECHO_URL = "https://ip-echo.example/plain" # placeholder endpoint that returns your IP
def proxies_for(session_id=None):
# Session syntax is provider-specific; this mirrors a "-session-<id>" style username.
user = f"{USER}-session-{session_id}" if session_id else USER
# Percent-encode credentials so characters like @ or : do not break the URL.
url = f"http://{quote(user, safe='')}:{quote(PASSWORD, safe='')}@{PROXY_HOST}"
return {"http": url, "https": url}
def exit_ip(session_id=None):
# Pass proxies per request: session-level proxies can be overridden by env proxy variables.
r = requests.get(IP_ECHO_URL, proxies=proxies_for(session_id), timeout=(5, 20))
r.raise_for_status()
return r.text.strip()
for i in range(5): # bounded series, no retry loop
print("sticky", i, exit_ip("test001"))
time.sleep(10)
for i in range(5):
print("no session", i, exit_ip())
La verifica TLS resta accesa, che è il default di Requests. L'argomento proxies per richiesta conta: la documentazione di Requests avverte che i valori impostati su session.proxies possono essere sovrascritti dalle variabili d'ambiente del proxy.
Legga i risultati con attenzione:
- Lo stesso IP sulla serie sticky e IP diversi senza ID di sessione è ciò a cui mirano la maggior parte dei gateway residenziali.
- Un cambio nella serie sticky prima della finestra dichiarata è un segnale da sollevare con il fornitore, ma una sola esecuzione non è una prova. I peer cadono, e alcuni fornitori cambiano uscita in silenzio per progetto.
- Un nuovo ID di sessione non garantisce un indirizzo diverso. I pool possono restituire un IP che ha già visto.
- Una sola pausa di inattività che chiude una sessione non le dice il timeout esatto. Ripeta con pause diverse prima di trarre una conclusione.
- Un IP di uscita invariato nella serie senza sessione non dimostra da solo che l'instradamento è fallito. Alcuni gateway tengono un'uscita per connessione.
Provi con lo stesso protocollo che userà in produzione, perché gli endpoint HTTP e SOCKS5 possono comportarsi in modo diverso. La guida SOCKS5 e HTTP spiega la differenza. Per un controllo manuale rapido, apra Il mio IP attraverso il proxy; mostra l'indirizzo per quella sola richiesta, quindi la aggiorni per confrontare. Il controllo proxy testa un endpoint dal nostro lato, utile per confermare che il proxy risponde, ma il risultato riflette da dove si collega il controllo e non isola i problemi nel suo browser o nel suo client.
07Candidati del catalogo da controllare per il controllo di sessione
I servizi sotto sono fornitori residenziali o a pool misto del nostro catalogo. Il controllo di sessione è documentato per alcuni di essi, e i dettagli differiscono. Per ogni scheda, controlli la documentazione attuale del fornitore per le modalità di sessione in offerta, la sintassi di sessione, il tempo massimo di tenuta e che cosa succede in failover. Essere elencati qui non significa che abbiamo testato la sua configurazione.
SOAX vende proxy residenziali e mobile a rotazione su un pool di crediti condiviso, con datacenter e ISP negli stessi piani. Il Builder parte da $200/mese + IVA (200 crediti); il traffico Tier 1 è $3/GB sul Builder.
Decodo (ex Smartproxy) vende proxy residenziali e datacenter. Residenziali: $4/GB senza piano mensile, o pacchetti mensili da $3.75/GB per 3 GB. Pagamenti: carte, PayPal, Alipay, Google/Apple Pay, crypto (con limiti).
Froxy offre proxy residenziali, mobile, residenziali veloci e datacenter fatturati a traffico, con pacchetti mensili e una prova a pagamento $1.99 / 3 giorni / 100 MB.
Oxylabs vende proxy residenziali, mobile, ISP e datacenter sotto un unico abbonamento mensile da $30. Pagamenti: carte, bonifico, AliPay, PayPal.
Bright Data è una grande rete proxy per la raccolta dati: IP residenziali, mobile, ISP e datacenter in circa 195 paesi. Il traffico residenziale si può pagare a consumo senza abbonamento, e gli indirizzi datacenter e ISP arrivano in pacchetti da 10 IP. L'accesso residenziale e mobile richiede la verifica dell'identità.
Scelga la rotazione quando ogni richiesta può stare in piedi da sola. Scelga sticky quando la richiesta successiva deve sembrare lo stesso visitatore. Scelga statico o dedicato quando la continuità o l'esclusività dell'indirizzo è ciò che sta noleggiando. Prima l'origine, poi la modalità di sessione, poi il venditore.
Qual è la differenza tra proxy sticky e a rotazione?
Quanto dura una sessione proxy sticky?
Un nuovo ID di sessione mi dà sempre un IP nuovo?
Dovrei usare proxy a rotazione per il web scraping?
Una sessione sticky è la stessa cosa di un IP statico?
Perché la mia sessione sticky ha cambiato IP in anticipo?
Articoli correlati
Che cosa sono i proxy residenziali e come funzionano
I proxy residenziali escono da indirizzi ISP consumer. Qui si spiegano pool, sessioni sticky, che cosa vedono i siti e che cosa chiedere a un fornitore prima di comprare.
4 minI migliori proxy per il web scraping nel 2026: una lista di controllo per chi compra
Un acquisto scraping nel 2026 parte dalla destinazione, non dal fornitore. Usi questa lista per origine, sessione, geo, fatturazione e un test live prima di salire di scala.
5 minProxy SOCKS5 e HTTP: protocolli, DNS e compatibilità
SOCKS5 e proxy HTTP spiegati: come differiscono i tunnel HTTP CONNECT e SOCKS5, dove viene risolto il DNS, quali client supportano quale autenticazione e come testare il protocollo che ha comprato.
