Proxy 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.

Questa guida è per chi sceglie tra un endpoint HTTP e uno SOCKS5 su un piano proxy, o sta cercando di capire perché un client rifiuta uno dei due. Non diamo proxy gratis e non vendiamo IP. Quello che segue copre i protocolli in sé, dove finiscono le query DNS e come testare ciò che ha davvero ottenuto.

01HTTP CONNECT e SOCKS5: come funziona ciascun tunnel#

Prima dei dettagli, un punto conta più del resto: il protocollo non è l'origine. Un pool residenziale può essere venduto come HTTP, come SOCKS5 o come entrambi. Anche gli IP datacenter arrivano in entrambe le forme. SOCKS5 non è un grado di qualità. È un modo di trasportare byte. Se un sito di destinazione si fida del suo traffico dipende dalla rete e dalla storia dell'IP, non da quale handshake il client ha usato per raggiungere il gateway.

Un proxy HTTP parla HTTP con il client. Gestisce due tipi di traffico in modo diverso.

Con URL http:// in chiaro, il client invia la richiesta intera al proxy, che la legge, la inoltra e può aggiungere, togliere o mettere in cache gli header lungo il percorso. Pochi siti pubblici servono ancora HTTP in chiaro, quindi in pratica questo percorso è raro.

Con URL https://, e con qualsiasi altra cosa che non sia HTTP in chiaro, il client usa il metodo CONNECT. Secondo RFC 9110, sezione 9.3.6, CONNECT chiede al proxy di aprire un tunnel verso la destinazione indicata e, una volta riuscito, di smettere di interpretare il traffico e di limitarsi a ritrasmettere byte in entrambe le direzioni finché una delle due parti chiude. Il target della richiesta è solo host e porta, per esempio CONNECT example.com:443. Quando il proxy risponde con uno stato 2xx, TLS gira da capo a capo tra il suo client e il sito. Il proxy può vedere quale host e quale porta ha chiesto, ma non può leggere la pagina decifrata.

Un proxy SOCKS5 lavora uno strato più in basso. RFC 1928 definisce un handshake binario breve: il client offre i metodi di autenticazione, il server ne sceglie uno, poi il client invia una richiesta con un comando e una destinazione. Ci sono tre comandi: CONNECT per un flusso TCP ordinario, BIND per le connessioni in ingresso e UDP ASSOCIATE per il relay UDP. A SOCKS5 non importa se il payload è HTTP, TLS, SMTP o un protocollo di gioco. Sposta solo byte.

Quindi «SOCKS5 contro HTTP CONNECT» non è davvero una scelta tra un proxy intelligente e uno stupido. Per il traffico HTTPS entrambi finiscono come un tunnel TCP opaco. Le differenze vere sono che cosa ciascuno può trasportare oltre HTTPS, come viene passato il nome di destinazione e quali client sanno parlarci.

RFC 9110 dice anche che i proxy «SHOULD restrict» CONNECT a porte note o a un elenco configurato di destinazioni, perché un CONNECT aperto sulla porta 25 potrebbe essere abusato per ritrasmettere spam. Quindi un endpoint HTTP può rifiutare un tunnel verso un database, un server di posta o una porta TCP personalizzata anche con credenziali valide. Se le servono quelle porte, controlli nella documentazione del fornitore le porte CONNECT consentite, oppure usi un endpoint SOCKS5 che le permette.

02DNS: risolto sul dispositivo o attraverso il proxy#

Il DNS è la parte che cambia davvero che cosa un sito, o il suo ISP, può imparare su di lei, ed è dove la configurazione SOCKS5 sbaglia più spesso.

Con un proxy HTTP, il client consegna l'hostname nel target della richiesta (CONNECT example.com:443) e il proxy fa la risoluzione per quella connessione. Questo toglie la lookup locale per le richieste che passano davvero dal proxy. Non garantisce che il dispositivo non faccia nessuna query DNS: i browser possono fare prefetch DNS, le liste di bypass e le regole «direct» mandano alcuni host intorno al proxy, WebRTC può aprire connessioni proprie e altre app sul dispositivo continuano a usare il resolver di sistema.

Con SOCKS5, decide il client. RFC 1928 consente al campo destinazione di contenere un indirizzo IPv4 grezzo, un indirizzo IPv6 grezzo o un nome di dominio pienamente qualificato. Se il client risolve il nome in locale e invia solo l'IP, il resolver del suo ISP (o qualunque resolver usi il sistema operativo) vede comunque ogni dominio che visita, anche se il traffico stesso passa dal proxy. Se il client invia il nome di dominio, il proxy lo risolve dalla sua parte.

curl rende visibile questa scelta. Il suo manuale descrive --socks5 come «use the specified SOCKS5 proxy - but resolve the hostname locally», mentre --socks5-hostname, o lo schema socks5h://, è descritto come «let the proxy resolve the hostname». Per le richieste con proxy, quella sola lettera h decide se il resolver locale vede il nome di destinazione. Altri client nascondono lo stesso interruttore sotto nomi come «Proxy DNS when using SOCKS v5» o «remote DNS». Vale la stessa avvertenza che per HTTP: il DNS remoto copre il traffico che passa dal tunnel SOCKS, non il prefetch, gli host in bypass, WebRTC o altre app, quindi confermi con un test di perdita invece di dare per scontato.

La risoluzione remota conta anche per i risultati, non solo per la privacy. Una CDN che risponde in base alla posizione del resolver può mandare un nome risolto in locale verso un edge vicino a lei invece che vicino all'uscita del proxy. La pagina allora si carica dalla regione sbagliata anche se l'IP sembra giusto.

Esempio schematico, non una misura di rete: dove viene risolto il nome di destinazione per le richieste con proxy in ciascuna configurazione. Non copre prefetch del browser, regole di bypass, WebRTC o altre app, che possono comunque fare lookup locali.

03Compatibilità dei client e autenticazione#

Scelga il protocollo che il suo client parla già bene. Aggiungere il supporto con pacchetti extra o wrapper è una fonte comune di segnalazioni «il proxy è rotto».

Browser. Firefox ha campi HTTP e SOCKS nelle proprie impostazioni proxy. I browser basati su Chromium seguono le impostazioni di sistema o un flag --proxy-server. Entrambi gestiscono CONNECT senza problemi. SOCKS5 con nome utente e password è il punto debole: le impostazioni SOCKS integrate del browser possono non avere dove inserire le credenziali, ed è uno dei motivi per cui si usano estensioni proxy o browser anti-detect. Usi un protocollo per profilo. Mescolare un proxy HTTP di sistema con un'estensione SOCKS5 nello stesso profilo è un modo facile per finire con alcune richieste su un percorso e altre sull'altro.

Scraper e librerie HTTP. Client HTTP comuni come curl accettano di serie un proxy http://user:pass@host:port e usano CONNECT per HTTPS da sé. In alcune librerie SOCKS5 richiede un pacchetto extra o un'opzione di build. Se il suo stack scarica solo pagine web, l'endpoint HTTP è il percorso con meno sorprese. La nostra guida allo scraping copre il lato origine di quella scelta.

App non HTTP. App di messaggistica, launcher di giochi, client di posta, SSH e strumenti per database non sono client HTTP. Quando supportano un proxy, spesso è un campo SOCKS piuttosto che uno HTTP. È lì che SOCKS5 è la scelta migliore, e anche per il traffico UDP come la voce quando il gateway implementa davvero UDP ASSOCIATE. Il supporto SOCKS5 su un piano non significa da solo che UDP sia supportato, quindi lo confermi prima di comprare per UDP.

Autenticazione. I proxy HTTP inviano le credenziali in un header Proxy-Authorization e rispondono 407 Proxy Authentication Required quando mancano o sono sbagliate. SOCKS5 negozia prima un metodo. RFC 1928 elenca GSSAPI e USERNAME/PASSWORD come metodi; un piano che le dà un login e una password usa il secondo, specificato in RFC 1929.

SOCKS4 e SOCKS4a sono protocolli diversi, senza supporto per la password, e un client solo SOCKS4 non può completare un handshake con un endpoint che parla solo SOCKS5. Un'allowlist di IP toglie il bisogno di una password, ma non cambia il protocollo. Serve un endpoint che il fornitore documenti esplicitamente come SOCKS4/SOCKS4a, di solito abbinato a un'allowlist di IP, oppure un client che supporta SOCKS5 o HTTP.

Su una connessione in chiaro, non cifrata, tra il suo client e il proxy, il login non è protetto: le credenziali HTTP Basic sono solo codificate in Base64, e nome utente/password SOCKS5 viaggiano in chiaro. Chiunque su quel percorso di rete può leggerli. Un endpoint proxy HTTPS, cioè uno in cui la connessione client-proxy è essa stessa avvolta in TLS, protegge quel salto, credenziali comprese. In ogni caso, non riusi le credenziali del proxy su nulla di importante.

Velocità. Si chiede spesso della «velocità SOCKS5 contro proxy HTTP». La differenza è piccola. Entrambi aggiungono un handshake all'apertura della connessione, e dopo inoltrano byte. In pratica decidono la velocità la distanza dal gateway, il carico del fornitore e l'IP di uscita, non il protocollo. I proxy HTTP in chiaro possono sembrare più veloci quando mettono in cache, ma questo raramente vale per HTTPS.

SOCKS5 e HTTPS. «Proxy HTTPS» significa due cose diverse. Di solito significa un proxy HTTP che tunnelizza i siti HTTPS con CONNECT, cioè tutto quanto descritto sopra. A volte significa che il collegamento tra lei e il proxy è esso stesso avvolto in TLS, il che nasconde le credenziali del proxy e gli hostname di destinazione alla rete locale. Le connessioni proxy HTTP in chiaro e SOCKS5 non cifrano quel primo salto, quindi se nasconderlo conta usi un endpoint proxy avvolto in TLS se fornitore e client ne supportano uno, oppure una VPN per quel segmento.

04Quale scegliere#

L'ultima riga è l'errore che chi compra fa più spesso. Passare un IP datacenter da HTTP a SOCKS5 non lo fa sembrare una connessione di casa. Se un sito dà un punteggio alla sua rete, cambi il tipo di uscita. Confronti proxy residenziali, proxy mobili e proxy datacenter, oppure legga prima residenziali e datacenter.

05Come controllare quale protocollo ha comprato#

Non si fidi del numero di porta. 8080, 3128, 1080 e porte alte come 60000 si usano per entrambi i protocolli, e alcuni gateway rispondono a entrambi sulla stessa porta.

1. Conosca prima il suo IP. Apra Il mio IP senza il proxy, così ha una baseline con cui confrontare.

2. Controlli che l'endpoint risponda. Incolli l'endpoint del fornitore nel controllo proxy come HOST:PORT o HOST:PORT:USER:PASS. Il controllo gira sul nostro server, prova i protocolli supportati e riporta il primo che riesce. Un prefisso di protocollo cambia quale protocollo prova per primo, ma non disattiva il fallback. Un solo risultato positivo quindi non dimostra che l'endpoint accetti sia HTTP sia SOCKS5. Per confrontarli a parte, usi i due comandi curl sotto o un client che le permette di forzare ciascun protocollo. Se un controllo fallisce, ispezioni l'errore e verifichi credenziali, allowlist di IP e restrizioni del piano prima di concludere che il protocollo non è supportato.

3. Controlli la stessa cosa dalla riga di comando. Usi un URL di test neutro per entrambe le esecuzioni, così i risultati sono confrontabili:

   # HTTP proxy: curl sends CONNECT for an https:// URL
   curl -v -x http://USER:PASS@HOST:PORT https://example.com/ -o /dev/null
   
   # SOCKS5 with proxy-side DNS (no local lookup)
   curl -v -x socks5h://USER:PASS@HOST:PORT https://example.com/ -o /dev/null
   

   Nell'output verbose del primo comando, una riga CONNECT example.com:443 seguita da una risposta 200 conferma un tunnel HTTP. Un 407 significa che il proxy parla HTTP ma ha rifiutato le credenziali, che è un problema di autenticazione, non di protocollo. Se il tentativo HTTP fallisce subito con una risposta malformata mentre socks5h:// si collega, l'endpoint molto probabilmente parla SOCKS su quella porta; confermi sulla documentazione del fornitore.

4. Confronti gli IP di uscita, non solo passa/fallisce. Controlli che ciascun protocollo esca nel paese e nel tipo di rete per cui ha pagato. Su un pool a rotazione, due test possono mostrare IP diversi o persino reti diverse a prescindere dal protocollo, quindi un disallineamento da solo non dimostra pool separati. Una sessione sticky rende più probabile un confronto omogeneo, ma non garantisce che lo stesso IP sia tenuto tra i test o dopo una riconnessione.

5. Osservi il DNS durante la stessa sessione. Usi DNS remoto (socks5h://, o «Proxy DNS» nel client) ed esegua un test di perdita. La guida come controllare se un proxy funziona spiega i controlli DNS e WebRTC.

6. Provi IPv6 a parte. SOCKS5 può trasportare una destinazione IPv6, ma solo se il gateway ha un'uscita IPv6. Un listing dual-stack ha bisogno di un test dual-stack.

Ecco un esempio svolto ipotetico di come leggere i risultati. Dica che un piano elenca un host gateway con due porte, e lei esegue entrambi i comandi curl sopra contro lo stesso URL di test. Questi pattern sono illustrazioni, non risultati di un fornitore reale:

Una checklist breve prima di fermarsi su un protocollo:

• Il suo client ha un'impostazione nativa per questo protocollo, compreso un campo nome utente e password se il piano li usa.
• Il DNS delle richieste con proxy è risolto dal proxy (socks5h:// o «Proxy DNS» per SOCKS5), e un test di perdita è stato eseguito con il browser o l'app reali.
• Le porte che le servono sono consentite: destinazioni CONNECT su un endpoint HTTP, UDP su un endpoint SOCKS5 se ne ha bisogno.
• Paese di uscita e tipo di rete coincidono con il piano, giudicati a parte dal protocollo.
• Il collegamento dal dispositivo al proxy è protetto (endpoint proxy TLS o VPN) se le credenziali che attraversano quella rete sono un problema.

Il protocollo è una scelta di compatibilità, l'origine è una scelta di accesso e la modalità di sessione (sticky o a rotazione) è una scelta di flusso. Le decida in quest'ordine e non pagherà di più per SOCKS5 pensando che sia un IP più pulito.

06Fornitori che offrono sia HTTP sia SOCKS5#

Prima di comprare, controlli nella documentazione di ciascun fornitore quali protocolli include il piano, le porte o gli hostname per ciascuno, il supporto UDP e se è disponibile un'allowlist di IP se il suo client ne ha bisogno.

SOAX — proxy residenziali e mobile3.8218

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.

85 paesi

3,00 USD

per 1 GB

Bright Data — proxy residenziali e datacenter4.41442

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à.

10 paesi

5,00 USD

per 1 GB

Oxylabs — proxy residenziali e datacenter4.0771

Oxylabs vende proxy residenziali, mobile, ISP e datacenter sotto un unico abbonamento mensile da $30. Pagamenti: carte, bonifico, AliPay, PayPal.

10 paesi

0,45 USD

per 1 GB

Decodo (Smartproxy) — proxy residenziali e datacenter4.22118

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).

83 paesi

0,38 USD

per 1 GB