SOCKS5 vs SOCKS5h: correggere la perdita di DNS in Python, curl, Selenium

Hai configurato un proxy SOCKS5, il traffico sembra passare attraverso di esso, l'IP nel browser è quello giusto — ma i siti vedono comunque la tua reale regione o il provider inizia a sospettare qualcosa. La ragione è quasi sempre la stessa: le richieste DNS vengono inviate direttamente dal tuo computer, bypassando il proxy. In questo articolo analizzeremo perché ciò accade, cosa distingue SOCKS5 da SOCKS5h e come chiudere questa perdita nel codice e negli strumenti pronti all'uso.

Che cos'è SOCKS5 e cosa lo distingue da SOCKS5h

SOCKS5 è un protocollo proxy che opera a livello di connessioni TCP/UDP e non analizza il contenuto dei pacchetti, a differenza dei proxy HTTP(S). Questo lo rende versatile: attraverso SOCKS5 è possibile proxy praticamente qualsiasi traffico — browser, Telegram, client torrent, script in Python. Ma la realizzazione classica di SOCKS5 ha una caratteristica importante: la risoluzione dei nomi di dominio (DNS) viene eseguita di default dal lato client, cioè dal tuo computer, e non dal lato del server proxy.

SOCKS5h è lo stesso protocollo, ma con il modificatore "h" (hostname), che indica all'applicazione client di non risolvere il dominio autonomamente, ma di inviarlo così com'è al server proxy, e sarà il proxy a eseguire la richiesta DNS a nome suo. La differenza è una sola lettera, ma le conseguenze per l'anonimato e la stabilità operativa sono fondamentali.

È importante capire: SOCKS5h non è un protocollo separato, ma un accordo a livello di specifica libreria o applicazione su come formare la richiesta al proxy. Il server proxy stesso funziona allo stesso modo in entrambi i casi, la differenza è solo chi avvia la risoluzione DNS — il client o il server.

Perché le richieste DNS bypassano il proxy

Quando accedi a un indirizzo del tipo https://example.com, prima di stabilire la connessione l'applicazione deve conoscere l'indirizzo IP di quel dominio. Questo processo si chiama risoluzione DNS. Quando si utilizza un normale SOCKS5, molte librerie e impostazioni di sistema eseguono la risoluzione tramite il server DNS di sistema — quello che è impostato nelle impostazioni di rete del tuo provider o router.

Di conseguenza, si crea una situazione paradossale: il traffico HTTP/TCP stesso passa attraverso il proxy e sembra che la richiesta provenga dall'IP del server proxy, mentre la richiesta DNS "Qual è l'IP di example.com?" vola direttamente dal tuo reale IP al server DNS del provider. Questa è la perdita di DNS (DNS leak). Un sito o un servizio che analizza l'attività di rete a un livello più profondo (e tali metodi di rilevamento sono attivamente utilizzati dai sistemi antifrode di Facebook, Google, TikTok) può vedere una discrepanza tra l'IP della connessione e la fonte della richiesta DNS.

La ragione è che il protocollo SOCKS5 è stato originariamente sviluppato come livello di trasporto per connessioni IP già pronte, e non per la risoluzione dei nomi. Gli sviluppatori di librerie e utilità hanno dovuto implementare separatamente la funzione di invio della richiesta DNS attraverso il tunnel — da qui è nato SOCKS5h come chiara indicazione "risolvi il dominio da solo, non io".

Quali sono i rischi di una perdita di DNS nella pratica

Per uno sviluppatore di parser o script di automazione, la perdita di DNS non è una teoria astratta, ma una causa concreta di blocchi e ban degli account. Analizziamo alcuni scenari.

Parsing di marketplace e siti. Se stai estraendo dati da Wildberries, Ozon o un'altra risorsa tramite un proxy della regione desiderata, ma le richieste DNS passano attraverso il provider, il sistema anti-bot può rilevare una discrepanza nella geolocalizzazione e aumentare il livello di sospetto della sessione — fino a captcha o blocco temporaneo dell'IP del proxy.

Multi-accounting e arbitraggio del traffico. Quando si lavora con Facebook Ads, TikTok Ads o Google Ads tramite più account, i sistemi antifrode analizzano decine di parametri, incluso l'impronta DNS. Se le richieste DNS di più "diversi" account improvvisamente passano attraverso lo stesso server DNS del provider, questo è un segnale per unire gli account in un unico cluster — e come conseguenza, una catena di ban (chain-ban).

Automazione in Selenium/Playwright. Gli script che emulano le azioni dell'utente nel browser sono particolarmente vulnerabili: il browser stesso può risolvere DNS tramite le impostazioni di sistema, ignorando il proxy impostato solo per il traffico HTTP. Di conseguenza, tutto il resto dell'impronta di rete rivela la posizione reale.

Per la maggior parte di queste attività, è fondamentale utilizzare proxy residenziali con una corretta configurazione della risoluzione DNS dal lato del server — questo riduce significativamente il rischio di rilevamento per segni di rete.

Come controllare se c'è una perdita di DNS

Prima di risolvere il problema, è opportuno assicurarsi che esista davvero. Ecco alcuni modi rapidi per verificarlo.

Apri il sito dnsleaktest.com o ipleak.net tramite la tua connessione proxy e avvia il test avanzato (Extended test).
Confronta l'elenco dei server DNS nei risultati con quello che è realmente il tuo provider Internet. Se vedi il provider invece del data center del proxy — la perdita è confermata.
Per la riga di comando, utilizza il comando tcpdump o Wireshark, filtrando il traffico sulla porta 53 (DNS) — se i pacchetti vanno direttamente al server del provider, e non attraverso il tunnel del proxy, il problema è dalla tua parte.
In Python, puoi controllare rapidamente la risoluzione manualmente tramite socket.getaddrinfo() prima e dopo aver attivato il proxy — se l'IP corrisponde al risultato senza proxy, la risoluzione avviene localmente.

Correzione in Python (requests, PySocks, urllib3)

L'errore più comune negli script Python è l'uso della libreria requests insieme a PySocks senza specificare esplicitamente lo schema socks5h. La differenza è di un simbolo, ma è proprio questo che decide chi risolve il dominio.

import requests

# CATTIVO: DNS risolto localmente, bypassando il proxy
proxies_leak = {
    "http": "socks5://user:pass@proxy_host:1080",
    "https": "socks5://user:pass@proxy_host:1080",
}

# BUONO: DNS risolto dal server proxy
proxies_safe = {
    "http": "socks5h://user:pass@proxy_host:1080",
    "https": "socks5h://user:pass@proxy_host:1080",
}

response = requests.get("https://example.com", proxies=proxies_safe, timeout=10)
print(response.status_code)
print(response.text[:200])

Per il corretto funzionamento dello schema socks5h tramite requests sarà necessario installare la dipendenza:

pip install "requests[socks]" PySocks

Se utilizzi urllib3 a basso livello direttamente, l'esempio sarà simile a questo:

from urllib3.contrib.socks import SOCKSProxyManager

proxy = SOCKSProxyManager(
    "socks5h://user:pass@proxy_host:1080",
    num_pools=10
)

response = proxy.request("GET", "https://example.com")
print(response.status)

Per script asincroni su aiohttp si utilizza la libreria aiohttp-socks, dove lo schema è specificato esattamente allo stesso modo:

import aiohttp
from aiohttp_socks import ProxyConnector

connector = ProxyConnector.from_url("socks5h://user:pass@proxy_host:1080")

async def fetch():
    async with aiohttp.ClientSession(connector=connector) as session:
        async with session.get("https://example.com") as resp:
            print(await resp.text())

Correzione in curl

In curl ci sono anche due flag diversi per i proxy SOCKS5, e la confusione tra di essi è una causa classica di perdita di DNS negli script bash.

# CATTIVO: risoluzione sulla macchina locale
curl --socks5 proxy_host:1080 https://example.com

# BUONO: risoluzione dal server proxy
curl --socks5-hostname proxy_host:1080 https://example.com

# Con autorizzazione
curl --socks5-hostname user:pass@proxy_host:1080 https://example.com

Il flag --socks5-hostname è l'equivalente diretto di socks5h in altri strumenti. Indica a curl: "non toccare il DNS, semplicemente passa il dominio al server proxy così com'è".

Correzione in Selenium e Playwright

Con l'automazione del browser la situazione è più complessa: Chrome o Firefox di default possono risolvere DNS tramite le impostazioni di sistema, ignorando il proxy impostato solo a livello di richiesta di rete. Per Selenium con Chrome è necessario abilitare esplicitamente la risoluzione tramite proxy utilizzando un flag di avvio del browser.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("--proxy-server=socks5://proxy_host:1080")
# Flag critico: risolvere DNS tramite proxy
options.add_argument("--host-resolver-rules=MAP * ~NOTFOUND , EXCLUDE proxy_host")

driver = webdriver.Chrome(options=options)
driver.get("https://example.com")

In Playwright la situazione è più semplice: la libreria risolve di default DNS tramite proxy, se specificato nella configurazione del contesto del browser.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={"server": "socks5://proxy_host:1080"}
    )
    page = browser.new_page()
    page.goto("https://example.com")
    print(page.title())
    browser.close()

Tuttavia, è sempre consigliabile controllare il comportamento reale tramite dnsleaktest.com dopo la configurazione — il comportamento può variare tra le versioni di Chromium.

Configurazione nei browser anti-detect

Se non stai scrivendo codice, ma stai lavorando tramite browser anti-detect come Dolphin Anty, AdsPower, Multilogin o GoLogin — la buona notizia è che la maggior parte di essi risolve già DNS tramite il server proxy automaticamente quando si seleziona il protocollo SOCKS5, senza la necessità di specificare "h" manualmente. Questo è uno dei loro principali vantaggi rispetto agli script scritti a mano.

Tuttavia, è opportuno verificarlo nella pratica: apri un profilo nel browser anti-detect, vai su dnsleaktest.com e avvia un test avanzato direttamente all'interno del profilo. Se vedi i server DNS corrispondenti alla regione del tuo proxy, e non al tuo reale provider — la configurazione è corretta. Se no, contatta il supporto del browser anti-detect specifico o cambia il tipo di proxy in HTTP(S), dove il problema della risoluzione DNS non si presenta così frequentemente, poiché i proxy HTTP lavorano sempre con URL completi.

Per il farming di account su Instagram, TikTok e la gestione di campagne pubblicitarie su Facebook Ads, i proxy mobili si comportano bene — grazie alla rotazione dinamica degli IP degli operatori di telefonia mobile, sono meno sospettati dai sistemi antifrode, anche se in qualche punto della catena si è verificata una piccola perdita di DNS.

Tabella di confronto dei protocolli di proxy

Protocollo	Chi risolve DNS	Rischio di perdita	Dove applicare
SOCKS5	Client (il tuo computer)	Alto	Solo se DNS non è critico (test locali)
SOCKS5h	Server proxy	Basso	Parsing, multi-accounting, automazione
Proxy HTTP/HTTPS	Server proxy (di default)	Basso	Traffico web, browser, richieste API

Se il tuo obiettivo è la raccolta dati ad alta velocità senza legami a una specifica regione dell'utente, dai un'occhiata ai proxy dei data center — sono più economici in base al volume di traffico e funzionano ottimamente in combinazione con SOCKS5h per il parsing, dove la velocità è importante, non la mascheratura come utente residenziale.

Checklist prima di avviare il progetto

Utilizzi lo schema socks5h://, e non socks5:// in tutte le librerie e configurazioni.
Per curl utilizzi il flag --socks5-hostname, e non --socks5.
In Selenium è stato aggiunto il flag --host-resolver-rules o si utilizza Playwright con la risoluzione proxy integrata.
Hai controllato il risultato su dnsleaktest.com o ipleak.net dopo la configurazione, e non prima.
Nel browser anti-detect hai testato l'impronta DNS all'interno del profilo stesso, e non solo l'IP esterno.
Per attività con elevate esigenze di anonimato consideri proxy residenziali o mobili invece di quelli dei data center.

Conclusione

La differenza tra SOCKS5 e SOCKS5h è letteralmente una sola lettera, ma essa determina chi risolve la richiesta DNS: il tuo computer o il server proxy. La perdita di DNS è una delle cause più invisibili, ma frequenti di rilevamento durante il parsing, il multi-accounting e l'automazione delle campagne pubblicitarie. Il controllo tramite dnsleaktest.com e l'esplicita indicazione dello schema socks5h nel codice, nei comandi curl o nelle impostazioni di automazione del browser chiude questa falla in pochi minuti.

Se stai solo scegliendo l'infrastruttura per il tuo compito — per il parsing e il lavoro con le API, i proxy dei data center sono più adatti, per il multi-accounting e i social media — i proxy residenziali, e per un'impronta di rete il più naturale possibile durante il lavoro con applicazioni mobili — i proxy mobili. In ciascuno di questi casi, una corretta configurazione della risoluzione DNS tramite SOCKS5h rimane un passaggio obbligatorio prima di avviare il progetto in produzione.