HTTP o SOCKS5: quale IP proxy scegliere?
Scegli il tipo di proxy in base all’applicazione, al traffico supportato e alla necessità di DNS risolto dal proxy.
Apri prima le impostazioni proxy dell’applicazione. I protocolli supportati determinano quali voci puoi usare; un’etichetta appariscente o una porta familiare non aggiunge supporto al client.
| Applicazione o attività | Cosa scegliere e verificare |
|---|---|
| Offre soltanto un campo proxy HTTP | Un endpoint adatto dall’elenco dei proxy HTTP. Prova anche HTTPS CONNECT se servono destinazioni HTTPS. |
| Supporta SOCKS5 e richiede opzioni di connessione o DNS | Un endpoint SOCKS5 con le opzioni necessarie supportate da entrambi i lati. |
| Richiede UDP | Verifica UDP nel client e nell’endpoint; la sola etichetta SOCKS5 non basta. |
| Richiede SOCKS4 | Un endpoint SOCKS4 compatibile e la modalità client corrispondente. |
| Non supporta proxy | Un IP preso da una lista non configura da solo l’applicazione. |
Per richieste web e API spesso basta un proxy HTTP. Inoltra HTTP e, quando consentito, trasporta HTTPS tramite CONNECT. Il successo di una pagina HTTP semplice non prova il supporto dei tunnel: il servizio può richiedere autenticazione del tunnel o limitare destinazioni e porte.
SOCKS opera sotto il livello delle richieste HTTP. Un’applicazione compatibile gli chiede di stabilire una connessione senza interpretare una richiesta HTTP, rendendolo utile anche per altro traffico supportato. SOCKS5 definisce indirizzi IPv4, IPv6 e nomi di dominio, autenticazione e associazione UDP. Una specifica applicazione o un endpoint gratuito può implementarne solo una parte. La rotta TCP SOCKS del browser non copre automaticamente un’altra app o un servizio UDP.
Dove viene risolto il nome di destinazione?
In curl, la forma dell’URL SOCKS5 determina dove avviene il DNS di destinazione: socks5:// risolve localmente; socks5h:// chiede al proxy di risolvere. Viste DNS diverse possono far funzionare una scelta e fallire l’altra. Altri client possono usare una casella o un’opzione separata. Selezionare SOCKS5 non dimostra che ogni ricerca DNS lo attraversi.
SOCKS4 ha meno capacità; SOCKS4a aggiunge la gestione dei nomi host. Se client e servizio supportano SOCKS5 e non serve il vecchio protocollo, una voce SOCKS5 adeguata è una prima scelta ragionevole. Inserire un endpoint SOCKS4 lasciando il client in modalità SOCKS5 è un’incompatibilità di protocollo.
Quando il protocollo è adatto, prova la destinazione reale e individua il primo errore. Né HTTP né SOCKS5 misura l’anonimato: fiducia nell’operatore, TLS della destinazione e percorso effettivo dell’applicazione determinano ancora la protezione ottenuta.