L'accesso a un servizio proxy a pagamento si apre in uno di due modi: o invii a ogni richiesta nome utente e password , oppure registri il tuo indirizzo IP pubblico nel pannello del provider creando una whitelist (elenco autorizzato). Entrambi risolvono lo stesso problema — "questa connessione è davvero dell'abbonato?" — ma nell'uso quotidiano producono risultati molto diversi.
In questo articolo vediamo come funzionano i due metodi a livello di protocollo, quale sia corretto in ciascuno scenario e quali codici di errore incontrerai.
Metodo 1: nome utente e password
In questo metodo le credenziali vengono inviate al proxy a ogni connessione. Il formato cambia a seconda del protocollo:
- Proxy HTTP:
Proxy-Authorization: Basic <base64(kullanici:sifre)>viene aggiunto l'header. - SOCKS5: viene eseguita la sotto-negoziazione username/password definita nella RFC 1929; nome utente e password vengono inviati in formato binario.
Sul lato HTTP il flusso è il seguente: il client invia la richiesta senza credenziali, il proxy 407 Proxy Authentication Required risponde con, il client aggiunge le credenziali e ripete la richiesta.
La maggior parte dei client esegue automaticamente questi due round. curl e i browser, quando vedono un 407, aggiungono le credenziali e ripetono la richiesta; le librerie HTTP più semplici, invece, a volte non riprovano e restituiscono direttamente un errore.
Basic il metodo non cifrale credenziali, le codifica soltanto in Base64. Il Base64 è una codifica reversibile. Per questo la riservatezza delle credenziali dipende dalla sicurezza della connessione stessa verso il proxy.
Metodo 2: IP whitelist
Nel modello whitelist non c'è password. Aggiungi il tuo indirizzo IP pubblico nel pannello del provider; il proxy accetta connessioni solo da quell'indirizzo. Poiché non vengono trasportate credenziali, il lato client si semplifica moltissimo: curl -x http://proxy.example.com:8080 https://example.com del nostro sito.
La domanda cruciale di questo modello è: il tuo indirizzo IP pubblico è statico? Nella maggior parte delle connessioni domestiche l'IP è dinamico e cambia quando il modem si riavvia. Quando cambia, la whitelist diventa non valida e tutte le connessioni vengono rifiutate.
La scelta si riduce in larga misura alla domanda "hai un IP statico?". Per le automazioni in esecuzione su server è più adatta la whitelist, per l'uso in mobilità utente/password.
Quale metodo in quale scenario?
Scraper o bot in esecuzione su server
L'IP del tuo VPS è statico; scegli la whitelist. Le credenziali non vengono incorporate nel codice o nelle variabili d'ambiente e la superficie di leak si riduce. Scenari di automazione questa è l'impostazione predefinita che consigliamo.
Uso manuale da laptop
Se ti sposti tra ufficio, casa e bar l'IP cambia continuamente. Usa utente/password: funziona senza problemi da qualsiasi rete.
Uso condiviso all'interno di un team
Se ti serve rispondere alla domanda "chi ha consumato quanto traffico", crea un utente separato per ogni persona. Con la whitelist tutto il team appare sotto un'unica identità.
Profili multipli con browser antidetect
Se a ogni profilo deve essere assegnato un IP di uscita diverso, utente/password è obbligatorio; la selezione della sessione infatti viene quasi sempre codificata all'interno del nome utente (ad esempio user-session-a1).
Incorporare le informazioni di sessione nel nome utente
Nei pool residential esiste uno schema diffuso: il nome utente non è solo un'identità, ma porta con sé anche un comando . Ad esempio:
Il carattere separatore e i nomi dei parametri cambiano da provider a provider. Fai riferimento alla documentazione del tuo pannello; il formato qui riportato serve solo a mostrare la struttura.
Il vantaggio di questo design è che non serve alcuna chiamata API lato client: cambi paese o sessione semplicemente modificando il nome utente. Lo svantaggio è che le credenziali si allungano e gli errori di battitura portano a cambiamenti di comportamento silenziosi. La logica dei rotating proxy nell'articolo in cui la spieghiamo trattiamo in dettaglio l'impatto di questo modello sulla gestione delle sessioni.
Errori più frequenti
La differenza tra 407 e 403 è cruciale: 407 dice "mostra la tua identità", mentre 403 significa "ho visto la tua identità, non hai i permessi".
La trappola dei caratteri speciali
Quando scrivi le credenziali in formato URL, alcuni caratteri della password si confondono con il separatore. Nell'espressione http://user:p@ss@ip:8080 il secondo @ viene interpretato come separatore e la connessione non si stabilisce. La soluzione è la codifica percentuale:
| Carattere | Forma codificata | Carattere | Forma codificata |
|---|---|---|---|
@ | %40 | / | %2F |
: | %3A | # | %23 |
? | %3F | % | %25 |
Un approccio più robusto consiste nel passare le credenziali ai campi dedicati del client invece di incorporarle nell'URL. Python requests, Node undici e l'opzione di curl --proxy-user lo supportano.
Leggere le credenziali da una variabile d'ambiente invece di incorporarle nel codice evita che finiscano nel controllo di versione e ne semplifica la rotazione.
Cosa cambia dal punto di vista della sicurezza?
I due metodi comportano rischi diversi. Nel modello utente/password il segreto può essere rubato: basta una riga di comando finita in un file di log, un file di configurazione sfuggito al controllo di versione o uno screenshot. Nel modello whitelist non c'è un segreto, ma esiste il rischio di condivisione dell'IP : chiunque si trovi sulla stessa rete aziendale può usare il tuo proxy senza accorgersene.
La configurazione più solida è combinare i due: restringi la sorgente con la whitelist e aggiungi sopra utente/password. La maggior parte dei provider business supporta questo modello ibrido. Se sul fronte privacy ti chiedi cosa veda il proxy il proxy è sicuro il nostro articolo offre un quadro completo; per i test di leak DNS leak e WebRTC leak i nostri strumenti.
Regole pratiche per la gestione delle credenziali
- Usa variabili d'ambiente, non scriverle dentro il codice.
- Crea credenziali separate per ogni ambiente : sviluppo, test e produzione non devono condividere la stessa password.
- Definisci quote e limiti; una credenziale trapelata non deve consumare traffico illimitato.
- Ruotale regolarmente; cambiale sempre dopo l'uscita di qualcuno dal team.
- Mascherale nei log; l'output di debug non deve scrivere la password in chiaro.
Riepilogo
La IP whitelist è la soluzione più pulita e con il minor rischio di leak sui server con IP statico. Nome utente e password sono invece indispensabili nell'uso in mobilità e negli scenari che richiedono sessioni multiple. Per decidere basta rispondere alle domande "il mio IP è statico", "quante persone lo useranno" e "devo inviare parametri di sessione". Per testare la tua configurazione puoi Se un datacenter proxy sia sufficiente dipende dal livello di protezione del target, ed è una cosa misurabile. Prendi come riferimento la connessione diretta ed esegui un test comparativo alla stessa velocità; scegli il livello in base al tasso di successo. Costruire una logica di escalation a livelli e accumulare statistiche per target riduce al minimo sia i costi sia la perdita di velocità. Per iniziare usare e il tuo IP di uscita Il mio indirizzo IP puoi verificarlo con.