SOCKS5 vs SOCKS5h : corriger la fuite DNS dans Python, curl, Selenium

Vous avez configuré un proxy SOCKS5, le trafic semble passer par celui-ci, l'IP affichée dans le navigateur est correcte — mais les sites voient toujours votre région réelle ou le fournisseur commence à suspecter quelque chose. La raison est presque toujours la même : les requêtes DNS partent directement de votre ordinateur, contournant le proxy. Dans cet article, nous allons examiner pourquoi cela se produit, en quoi SOCKS5 diffère de SOCKS5h et comment corriger cette fuite dans le code et dans les outils prêts à l'emploi.

Qu'est-ce que SOCKS5 et en quoi est-il différent de SOCKS5h

SOCKS5 est un protocole de proxy qui fonctionne au niveau des connexions TCP/UDP et ne déchiffre pas le contenu des paquets, contrairement aux proxies HTTP(S). Cela le rend polyvalent : avec SOCKS5, vous pouvez proxy presque n'importe quel trafic — navigateur, Telegram, client torrent, script en Python. Mais la mise en œuvre classique de SOCKS5 a une caractéristique importante : la résolution des noms de domaine (DNS) est effectuée par défaut du côté du client, c'est-à-dire sur votre ordinateur, et non du côté du serveur proxy.

SOCKS5h est le même protocole, mais avec le modificateur « h » (hostname), qui indique à l'application cliente de ne pas résoudre le domaine elle-même, mais de l'envoyer tel quel au serveur proxy, qui effectuera la requête DNS en son nom. La différence est d'une seule lettre, mais les conséquences pour l'anonymat et la stabilité de fonctionnement sont fondamentales.

Il est important de comprendre : SOCKS5h n'est pas un protocole distinct, mais un accord au niveau d'une bibliothèque ou d'une application spécifique sur la façon de formuler une requête au proxy. Le serveur proxy fonctionne de la même manière dans les deux cas, la seule différence est qui initie la résolution DNS — le client ou le serveur.

Pourquoi les requêtes DNS contournent le proxy

Lorsque vous accédez à une adresse de type https://example.com, avant d'établir la connexion, l'application doit connaître l'adresse IP de ce domaine. Ce processus s'appelle la résolution DNS. En utilisant un SOCKS5 classique, de nombreuses bibliothèques et configurations système effectuent la résolution via le serveur DNS système — celui qui est configuré dans les paramètres réseau de votre fournisseur ou de votre routeur.

En conséquence, une situation paradoxale se produit : le trafic HTTP/TCP lui-même passe par le proxy et semble provenir de l'IP du serveur proxy, tandis que la requête DNS « Quelle est l'IP de example.com ? » part directement de votre IP réelle vers le serveur DNS du fournisseur. C'est ce qu'on appelle une fuite DNS (DNS leak). Un site ou un service qui analyse l'activité réseau à un niveau plus profond (et de telles méthodes de détection sont activement utilisées par les systèmes anti-fraude de Facebook, Google, TikTok) peut voir une incohérence entre l'IP de la connexion et la source de la requête DNS.

La raison en est que le protocole SOCKS5 a été initialement développé comme un niveau de transport pour des connexions IP déjà établies, et non pour la résolution de noms. Les développeurs de bibliothèques et d'outils ont dû mettre en œuvre séparément la fonction de transmission des requêtes DNS via le tunnel — d'où l'apparition de SOCKS5h comme une indication explicite « résolvez le domaine vous-même, pas moi ».

Quels sont les dangers d'une fuite DNS en pratique

Pour un développeur de parseur ou de script d'automatisation, une fuite DNS n'est pas une théorie abstraite, mais une cause concrète de blocages et de bans de comptes. Examinons quelques scénarios.

Parsing de marketplaces et de sites. Si vous parsez Wildberries, Ozon ou une autre ressource via un proxy de la région souhaitée, mais que les requêtes DNS passent par le fournisseur, le système anti-bot peut détecter une incohérence de géolocalisation et augmenter le niveau de suspicion de la session — jusqu'à captcha ou blocage temporaire de l'IP du proxy.

Multi-comptes et arbitrage de trafic. Lors de l'utilisation de Facebook Ads, TikTok Ads ou Google Ads via plusieurs comptes, les systèmes anti-fraude analysent des dizaines de paramètres, y compris l'empreinte DNS. Si les requêtes DNS de plusieurs « différents » comptes passent soudainement par le même serveur DNS du fournisseur, c'est un signal pour regrouper les comptes en un seul cluster — et par conséquent, une chaîne de bans (chain-ban).

Automatisation dans Selenium/Playwright. Les scripts qui simulent les actions de l'utilisateur dans le navigateur sont particulièrement vulnérables : le navigateur lui-même peut résoudre le DNS via les paramètres système de l'OS, ignorant le proxy configuré uniquement pour le trafic HTTP. En fin de compte, tout le reste de l'empreinte réseau révèle la localisation réelle.

Pour la plupart de ces tâches, il est crucial d'utiliser des proxies résidentiels avec une résolution DNS correctement configurée du côté du serveur — cela réduit considérablement le risque de détection par des signes réseau.

Comment vérifier s'il y a une fuite DNS

Avant de corriger le problème, il vaut mieux s'assurer qu'il existe réellement. Voici quelques méthodes rapides de vérification.

Ouvrez le site dnsleaktest.com ou ipleak.net via votre connexion proxy et lancez le test avancé (Extended test).
Comparez la liste des serveurs DNS dans les résultats avec ce qu'est réellement votre fournisseur d'accès Internet. Si vous voyez le fournisseur au lieu du centre de données du proxy — la fuite est confirmée.
Pour la ligne de commande, utilisez la combinaison tcpdump ou Wireshark, en filtrant le trafic par le port 53 (DNS) — si les paquets vont directement au serveur du fournisseur, et non via le tunnel proxy, le problème est de votre côté.
En Python, vous pouvez rapidement vérifier la résolution manuellement via socket.getaddrinfo() avant et après l'activation du proxy — si l'IP correspond au résultat sans proxy, la résolution se fait localement.

Correction en Python (requests, PySocks, urllib3)

L'erreur la plus courante dans les scripts Python est l'utilisation de la bibliothèque requests avec PySocks sans indiquer explicitement le schéma socks5h. La différence d'un caractère détermine qui résout le domaine.

import requests

# MAUVAIS : DNS résolu localement, contournant le proxy
proxies_leak = {
    "http": "socks5://user:pass@proxy_host:1080",
    "https": "socks5://user:pass@proxy_host:1080",
}

# BON : DNS résolu du côté du serveur 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])

Pour que le schéma socks5h fonctionne correctement avec requests, vous devrez installer la dépendance :

pip install "requests[socks]" PySocks

Si vous utilisez urllib3 à bas niveau directement, l'exemple ressemblera à ceci :

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)

Pour les scripts asynchrones utilisant aiohttp, la bibliothèque aiohttp-socks est utilisée, où le schéma est spécifié de la même manière :

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

Correction dans curl

Dans curl, il y a aussi deux drapeaux différents pour les proxies SOCKS5, et la confusion entre eux est une cause classique de fuite DNS dans les scripts bash.

# MAUVAIS : résolution sur la machine locale
curl --socks5 proxy_host:1080 https://example.com

# BON : résolution du côté du serveur proxy
curl --socks5-hostname proxy_host:1080 https://example.com

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

Le drapeau --socks5-hostname est l'analogue direct de socks5h dans d'autres outils. Il indique à curl : « ne touche pas au DNS, transmets simplement le domaine au serveur proxy tel quel ».

Correction dans Selenium et Playwright

Avec l'automatisation des navigateurs, la situation est plus complexe : Chrome ou Firefox peuvent par défaut résoudre le DNS via les paramètres système, ignorant le proxy configuré uniquement au niveau de la requête réseau. Pour Selenium avec Chrome, il est nécessaire d'activer explicitement la résolution via le proxy avec un drapeau de lancement du navigateur.

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

options = Options()
options.add_argument("--proxy-server=socks5://proxy_host:1080")
# Drapeau critique : résoudre le DNS via le proxy
options.add_argument("--host-resolver-rules=MAP * ~NOTFOUND , EXCLUDE proxy_host")

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

Dans Playwright, la situation est plus simple : la bibliothèque résout par défaut le DNS via le proxy s'il est spécifié dans la configuration du contexte du navigateur.

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

Néanmoins, il est recommandé de toujours vérifier le comportement réel via dnsleaktest.com après la configuration — le comportement peut varier entre les versions de Chromium.

Configuration dans les navigateurs anti-détection

Si vous ne codez pas, mais travaillez avec des navigateurs anti-détection comme Dolphin Anty, AdsPower, Multilogin ou GoLogin — la bonne nouvelle est que la plupart d'entre eux résolvent déjà le DNS via le serveur proxy automatiquement lors du choix du protocole SOCKS5, sans avoir besoin d'indiquer « h » manuellement. C'est l'un de leurs principaux avantages par rapport aux scripts faits maison.

Cependant, il est conseillé de le vérifier en pratique : ouvrez un profil dans le navigateur anti-détection, allez sur dnsleaktest.com et lancez un test avancé directement dans le profil. Si vous voyez des serveurs DNS correspondant à la région de votre proxy, et non à votre fournisseur réel — la configuration est correcte. Sinon, contactez le support du navigateur anti-détection spécifique ou changez le type de proxy en HTTP(S), où le problème de résolution DNS n'est pas aussi aigu, car le proxy HTTP fonctionne toujours avec des URL complètes.

Pour la création de comptes sur Instagram, TikTok et la gestion de campagnes publicitaires sur Facebook Ads, les proxies mobiles se montrent efficaces — grâce à la rotation dynamique des IP des opérateurs de téléphonie mobile, elles sont moins souvent suspectées par les systèmes anti-fraude, même si une petite fuite DNS s'est produite quelque part dans la chaîne.

Tableau comparatif des protocoles de proxy

Protocole	Qui résout le DNS	Risque de fuite	Où appliquer
SOCKS5	Client (votre ordinateur)	Élevé	Uniquement si le DNS n'est pas critique (tests locaux)
SOCKS5h	Serveur proxy	Faible	Parsing, multi-comptes, automatisation
Proxy HTTP/HTTPS	Serveur proxy (par défaut)	Faible	Trafic web, navigateurs, requêtes API

Si votre tâche est de collecter des données à haute vitesse sans lien avec une région utilisateur spécifique, envisagez les proxies de centres de données — elles sont moins chères en fonction du volume de trafic et fonctionnent très bien avec SOCKS5h pour le parsing, où la vitesse est plus importante que la dissimulation en tant qu'utilisateur résidentiel.

Liste de contrôle avant de lancer le projet

Utilisez le schéma socks5h://, et non socks5:// dans toutes les bibliothèques et configurations.
Pour curl, utilisez le drapeau --socks5-hostname, et non --socks5.
Dans Selenium, le drapeau --host-resolver-rules est ajouté ou Playwright est utilisé avec la résolution proxy intégrée.
Vérifiez le résultat sur dnsleaktest.com ou ipleak.net après la configuration, et non avant.
Dans le navigateur anti-détection, testez l'empreinte DNS à l'intérieur du profil lui-même, et non seulement l'IP externe.
Pour les tâches avec de fortes exigences d'anonymat, envisagez des proxies résidentiels ou mobiles au lieu de ceux des centres de données.

Conclusion

La différence entre SOCKS5 et SOCKS5h est littéralement une lettre, mais elle détermine qui résout la requête DNS : votre ordinateur ou le serveur proxy. La fuite DNS est l'une des causes les plus discrètes, mais fréquentes de détection lors du parsing, du multi-comptes et de l'automatisation des campagnes publicitaires. La vérification via dnsleaktest.com et l'indication explicite du schéma socks5h dans le code, les commandes curl ou les configurations d'automatisation des navigateurs comblent cette faille en quelques minutes.

Si vous choisissez uniquement l'infrastructure pour la tâche — pour le parsing et le travail avec l'API, les proxies de centres de données conviennent mieux, pour le multi-comptes et les réseaux sociaux — les proxies résidentiels, et pour une empreinte réseau aussi naturelle que possible lors de l'utilisation d'applications mobiles — les proxies mobiles. Dans tous ces cas, une configuration correcte de la résolution DNS via SOCKS5h reste une étape obligatoire avant de lancer le projet en production.