Sommaire de l'article

Imaginez la scène. Vous avez connecté un proxy dans la région souhaitée, vérifié l'adresse IP – tout est correct, la ville et le pays correspondent. Mais le site cible vous montre obstinément un contenu différent, et le système anti-fraude marque votre session comme suspecte. Familiar ? Vous avez probablement rencontré l'un des phénomènes les plus sournois lors de l'utilisation d'un proxy : la fuite DNS ou un mauvais chemin de résolution de nom de domaine.

Cet article est un guide complet sur la manière exacte dont la conversion d'un nom de domaine en adresse IP se produit lorsque le trafic passe par un proxy. Nous allons examiner en quoi les schémas socks5 et socks5h diffèrent fondamentalement, qui envoie la requête DNS et à quelle étape, pourquoi le site voit parfois une région complètement différente de celle attendue, et comment configurer la résolution distante dans les clients et bibliothèques populaires. Le sujet est spécifique, mais terriblement important. C'est sur la résolution des noms que des milliers de configurations apparemment correctes échouent.

Introduction : pourquoi le proxy est connecté mais le site voit une mauvaise région

Commençons par le symptôme qui amène la plupart des lecteurs à ce sujet. Vous avez configuré un proxy. L'adresse IP est correctement remplacée – c'est facile à vérifier sur n'importe quel service de détection IP. Pourtant, quelque chose ne va pas : le site affiche une localisation d'un autre pays, le CDN vous dirige vers un nœud inattendu, et parfois le système de sécurité de la ressource cible bloque la requête sans raison apparente.

La cause est presque toujours la même. Votre trafic HTTP ou applicatif passe bien par le proxy, mais la requête DNS – celle qui transforme un nom comme example.com en une adresse IP spécifique – contourne le proxy, partant directement de votre machine. Et cette requête vous trahit complètement.

Pourquoi cela se produit-il ? Parce que la résolution du nom et la transmission des données sont deux étapes distinctes qui peuvent emprunter des chemins différents. De nombreux clients résolvent le nom localement par défaut, puis envoient la connexion déjà établie via le proxy. Du point de vue réseau, c'est logique. Du point de vue de la vie privée et de la géolocalisation, c'est une catastrophe.

À la fin de cet article, vous comprendrez :

  • qui exactement effectue la résolution du nom – le système d'exploitation, la bibliothèque de l'application, le navigateur ou le proxy lui-même ;
  • en quoi le schéma socks5 diffère de socks5h au niveau du protocole et pourquoi une seule lettre change tout ;
  • comment la méthode CONNECT dans un proxy HTTP résout presque automatiquement le problème de résolution ;
  • par quels canaux le DNS fuit même avec une configuration apparemment correcte ;
  • comment activer la résolution distante dans curl, Python, Node.js, Go, Chrome, Firefox, Selenium et Playwright ;
  • comment vérifier le chemin réel de résolution avec des outils comme dig, nslookup et tcpdump.

Fixons d'emblée le cadre. Nous ne discutons pas du meilleur serveur DNS public et ne recommandons pas de fournisseurs spécifiques. Notre sujet est uniquement le chemin de résolution lors de l'utilisation d'un proxy. Ni plus, ni moins.

Bases : qu'est-ce que la résolution de nom et qui l'effectue

Pour comprendre les fuites, il faut d'abord maîtriser la mécanique de la résolution. Décomposons-la.

Qu'est-ce que la résolution de nom de domaine

Les ordinateurs communiquent via des adresses IP, les humains via des noms. La résolution (de l'anglais resolve, résoudre) est le processus de conversion d'un nom lisible par l'homme, comme shop.example.com, en une adresse IP machine comme 93.184.216.34. Sans cette étape, aucune connexion n'est possible : le navigateur ne sait pas à quel serveur se connecter tant qu'il n'a pas obtenu l'IP.

La résolution est une transaction réseau distincte. Elle utilise généralement le protocole DNS sur UDP ou TCP sur le port 53. Le client envoie une requête au résolveur, le résolveur renvoie une réponse. Le point clé : qui envoie exactement cette requête et par quelle route – c'est la question centrale de tout notre sujet.

Quatre exécutants possibles de la résolution

Lorsqu'une application souhaite se connecter à example.com, la résolution peut être effectuée par l'un des quatre acteurs. Analysons chacun.

1. Le système d'exploitation

La plupart des applications ne résolvent pas les noms elles-mêmes. Elles appellent la fonction système – dans le monde C, c'est getaddrinfo. Le système d'exploitation possède son propre résolveur (stub resolver) qui sait quel serveur DNS interroger, gère un cache local et tient compte du fichier hosts. C'est le chemin le plus courant. Et le plus dangereux en termes de fuites : le résolveur système, par défaut, se rend directement sur le réseau, ignorant votre proxy.

2. La bibliothèque de l'application

Certains programmes et bibliothèques ont leur propre logique de résolution, qui peut soit déléguer la tâche au système d'exploitation, soit l'effectuer eux-mêmes, soit – et c'est le plus important – transmettre le nom au serveur proxy pour que la résolution se fasse côté distant. C'est exactement ce mécanisme que réalisent les schémas socks5h et le proxy-hosting.

3. Le navigateur

Les navigateurs modernes sont un univers à part. Ils ont leur propre politique de résolution, leur propre cache DNS, des mécanismes comme DoH (DNS over HTTPS), le préchargement des connexions et WebRTC. Le navigateur peut résoudre le nom complètement indépendamment des paramètres système, ce qui génère toute une classe de fuites.

4. Le serveur proxy lui-même

Le scénario idéal pour la vie privée. Le client ne résout pas du tout le nom. Il transmet au serveur proxy une chaîne avec le nom d'hôte, et le proxy, de son côté, effectue la résolution et se connecte à l'IP souhaitée. Du point de vue du site cible, la requête DNS provient du réseau du proxy, pas du vôtre.

Analogie clé

Imaginez que vous envoyez un coursier (proxy) avec un colis dans une autre ville. Il y a deux façons de procéder. La première : vous trouvez vous-même l'adresse exacte du destinataire dans un annuaire chez vous, notez les coordonnées sur le colis et ne donnez au coursier que les coordonnées. L'annuaire de votre ville peut donner une adresse différente de celle de la ville de destination – et vous ne le remarquerez pas. La seconde : vous donnez au coursier uniquement le nom du destinataire, et il trouve l'adresse sur place, via l'annuaire local. La seconde méthode est la résolution distante. Elle garantit que l'adresse est déterminée depuis le bon point du réseau.

socks5 vs socks5h : où la décision de résolution est-elle prise

Nous arrivons maintenant au cœur du sujet. La différence entre socks5 et socks5h n'est pas cosmétique et n'est pas un synonyme. Ce sont des chemins de résolution fondamentalement différents, bien que le protocole SOCKS5 soit le même sous le capot.

Ce que dit le protocole SOCKS5

Le protocole SOCKS5 est flexible en soi. Dans la commande d'établissement de connexion, le client spécifie le type d'adresse de destination. Trois options sont possibles :

  • Adresse IPv4 – le client transmet une IP prête ;
  • Adresse IPv6 – idem, mais pour IPv6 ;
  • Nom de domaine – le client transmet une chaîne de nom, et la résolution doit alors être effectuée par le serveur proxy.

Le protocole lui-même sait donc gérer à la fois la résolution locale et distante. La question est seulement de savoir quel type d'adresse le client enverra. Et c'est là qu'intervient la convention de nommage des schémas.

Schéma socks5 : résolution locale

Lorsqu'un client utilise le schéma socks5 (sans la lettre h), cela signifie par convention établie : résoudre le nom localement. Le client demande d'abord à son résolveur (généralement système) l'IP de example.com, obtient l'adresse, puis transmet au serveur proxy une IPv4 ou IPv6 déjà prête.

Que voit le site cible ? Il voit la connexion provenant du proxy – c'est correct. Mais la requête DNS est partie de votre réseau, de votre côté, via votre résolveur local. Si votre résolveur est géographiquement ou logiquement lié à votre région, l'infrastructure cible via le CDN et la géolocalisation DNS peut déterminer précisément votre région, et non celle du proxy. D'où le symptôme de l'introduction.

Schéma socks5h : résolution distante

La lettre h dans socks5h signifie hostname – nom d'hôte. Ce schéma indique au client : ne résous pas toi-même, transmet le nom au serveur proxy. Le client envoie une commande avec un type d'adresse « nom de domaine », et le serveur proxy effectue la résolution de son côté.

Que voit maintenant le site cible ? La requête DNS provient du résolveur utilisé par le proxy, c'est-à-dire du réseau du proxy. La géolocalisation par DNS pointe vers la région du proxy. Votre résolveur local n'est pas du tout sollicité et ne sait rien des sites que vous visitez. C'est le chemin correct et propre pour la plupart des tâches.

Tableau comparatif de la mécanique

Rassemblons les différences sous forme compacte :

  • socks5 : la résolution est effectuée par le client (OS/bibliothèque). Le proxy reçoit une IP. La requête DNS part de votre réseau. Possibilité de désynchronisation géographique et de fuite.
  • socks5h : la résolution est effectuée par le proxy. Le proxy reçoit un nom. La requête DNS part du réseau du proxy. La région est cohérente, pas de fuite.

Retenez cette règle simple : si la confidentialité et la justesse de la géolocalisation sont importantes – toujours socks5h. Une seule lettre économise des heures de débogage.

Pourquoi cette convention existe-t-elle

Un peu d'histoire est utile pour comprendre. À l'origine, les clients SOCKS résolvaient eux-mêmes car les premières versions du protocole (SOCKS4) ne savaient pas transmettre les noms. SOCKS5 a ajouté la prise en charge des noms de domaine, mais l'écosystème des outils a introduit le suffixe h pour indiquer clairement le comportement. Ainsi est née la paire socks5 / socks5h, comprise aujourd'hui par curl, Python et de nombreux clients HTTP. C'est une norme de facto, pas une partie de la RFC.

Proxy HTTP et HTTPS : pourquoi la méthode CONNECT résout sur le proxy

SOCKS n'est pas le seul type de proxy. Une grande partie des tâches professionnelles utilise des proxies HTTP. Et ici, la mécanique de résolution est différente, et dans de nombreux cas, plus avantageuse.

Requête HTTP classique via un proxy

Lorsque vous accédez à une ressource HTTP (sans chiffrement) via un proxy HTTP, le client envoie au proxy la requête complète avec l'URL absolue. La ligne de requête contient le nom d'hôte. Le proxy voit le nom, le résout lui-même et se connecte au serveur. Avec un proxy HTTP classique, la résolution se fait naturellement du côté du proxy. Le client n'a pas besoin de connaître l'IP.

Méthode CONNECT pour HTTPS

Avec HTTPS, c'est plus intéressant. Le trafic chiffré ne peut pas être lu par le proxy – et ce n'est pas son rôle. C'est pourquoi une méthode spéciale appelée CONNECT est utilisée pour HTTPS. Le client envoie au proxy une commande du type CONNECT example.com:443. Notez que c'est le nom d'hôte qui est transmis, pas l'IP.

Que se passe-t-il ensuite ? Le serveur proxy reçoit le nom, le résout de son côté, ouvre un tunnel TCP vers l'IP cible et se transforme en un tube transparent. À l'intérieur de ce tube, la poignée de main TLS complète a lieu entre votre client et le serveur cible – le proxy ne la déchiffre pas.

Conclusion clé : avec une implémentation correcte d'un proxy HTTP utilisant la méthode CONNECT, la résolution est distante par défaut. Le nom va vers le proxy, le proxy résout lui-même. C'est l'une des raisons pour lesquelles les proxies HTTP pour le trafic HTTPS se comportent souvent mieux dès le départ qu'un SOCKS mal configuré.

Réserve concernant l'optimisation client

Il y a un point important : certains clients, cherchant à optimiser la connexion, résolvent tout de même le nom localement avant d'envoyer CONNECT, puis transmettent dans CONNECT l'adresse IP au lieu du nom. Formellement, c'est permis, mais cela annule tout l'avantage de la résolution distante. Même avec un proxy HTTP, on ne peut donc pas faire aveuglément confiance au comportement – il faut le vérifier. Nous parlerons des méthodes de vérification dans une section séparée.

Proxy HTTPS en tant que terme distinct

Ne confondez pas deux significations. Parfois, proxy HTTPS signifie un proxy qui proxy le trafic HTTPS (via CONNECT). Parfois, cela signifie un proxy dont la connexion elle-même est chiffrée via TLS (le canal client-proxy est sécurisé). Ce sont deux choses différentes. Du point de vue de la résolution, le premier sens est plus important : comment le nom de destination est transmis. Le chiffrement du canal vers le proxy n'affecte pas directement le chemin de résolution, bien qu'il protège le fait même de la transmission du nom contre un observateur entre vous et le proxy.

Fuites DNS : mécanique d'apparition et scénarios typiques

Venons-en maintenant à la partie la plus intéressante : l'anatomie des fuites. Une fuite DNS est une situation où la requête DNS contourne le proxy, révélant votre véritable résolveur, votre région ou le simple fait que vous accédez à un domaine spécifique. Analysons les scénarios un par un, car chacun nécessite un traitement spécifique.

Scénario 1 : le résolveur système contourne le proxy

Le cas le plus fréquent. Vous avez configuré l'application en socks5 (sans h), ou le client ne supporte tout simplement pas la résolution distante. L'application appelle la fonction système getaddrinfo, le système d'exploitation envoie une requête DNS à son résolveur directement sur le réseau, en contournant le proxy. Les données passent ensuite par le proxy, mais le nom a déjà fui.

Comment le reconnaître : sur le proxy, les connexions arrivent par IP, pas par nom. Dans une capture réseau de votre machine, on voit des paquets sortants sur le port 53 qui ne sont pas encapsulés dans le tunnel du proxy.

Traitement : passer à socks5h, activer la résolution distante dans le client, ou isoler l'application de manière à ce qu'elle n'ait pas d'accès réseau direct pour le DNS.

Scénario 2 : WebRTC dans le navigateur

WebRTC est une technologie en temps réel pour l'audio, la vidéo et le transfert de données directement entre navigateurs. Pour établir une connexion, WebRTC utilise le mécanisme ICE qui collecte des candidats – y compris en résolvant les hôtes des serveurs STUN et en pouvant initier des requêtes qui contournent le proxy configuré. Historiquement, WebRTC était connu pour révéler les adresses réelles même avec un proxy actif. Bien que les navigateurs modernes aient considérablement renforcé les politiques, le risque demeure si la configuration n'est pas précise.

Traitement : contrôler la politique WebRTC dans le navigateur, désactiver ou limiter le traitement des candidats ICE, utiliser des paramètres de navigateur qui forcent tout le trafic, y compris WebRTC, à passer par le proxy.

Scénario 3 : DoH intégré dans le navigateur

Les navigateurs modernes savent effectuer du DNS over HTTPS – une résolution via une requête HTTPS chiffrée vers leur fournisseur DoH. Le problème est que cette requête peut contourner votre configuration SOCKS, en partant directement de la machine, si le navigateur est configuré pour résoudre via son propre DoH et que ce trafic n'est pas encapsulé dans le proxy. On obtient un paradoxe : le nom est résolu de manière chiffrée et privée vis-à-vis du fournisseur, mais en contournant votre proxy, ce qui est le pire pour les tâches de géolocalisation. Nous détaillerons ce mécanisme dans la section sur DoH.

Scénario 4 : chemin IPv6 parallèle

Un scénario particulièrement sournois. Votre proxy fonctionne en IPv4, vous avez configuré la résolution distante. Mais votre machine a une interface IPv6 fonctionnelle, et le client, suivant l'algorithme Happy Eyeballs (tentatives simultanées en IPv4 et IPv6), essaie de résoudre les enregistrements AAAA et de se connecter directement en IPv6, contournant le proxy. Une partie du trafic et du DNS fuit. La région se désynchronise, la connexion passe partiellement ailleurs.

Traitement : désactiver IPv6 pour l'application utilisant le proxy, ou s'assurer que le proxy supporte IPv6 et que tout le trafic, y compris la résolution AAAA, passe par lui. Pour de nombreuses tâches, il est plus simple de forcer le client à n'utiliser que l'IPv4.

Scénario 5 : cache et préchargement

Les navigateurs et les systèmes d'exploitation mettent agressivement en cache le DNS et établissent des connexions à l'avance (preconnect, prefetch). Si le cache s'est rempli avant la configuration du proxy, l'application peut utiliser d'anciennes entrées ou des connexions préétablies en contournant la nouvelle configuration. C'est un détail, mais lors du débogage, cela peut rendre fou.

Traitement : vider le cache DNS du système d'exploitation et du navigateur, redémarrer, désactiver le préchargement agressif pendant la phase de diagnostic.

Règle générale des fuites

Avez-vous remarqué un schéma commun ? Toutes les fuites se résument à une chose : il existe un canal par lequel le nom ou la connexion ne passe pas par le proxy. La tâche de l'ingénieur est de trouver et de fermer tous ces canaux. Une fuite est toujours une porte non verrouillée, pas une mystification.

Pratique par outil : comment activer la résolution distante

Passons aux choses concrètes. Analysons les clients spécifiques et montrons comment activer la résolution distante et éviter la résolution locale. C'est la section la plus pratique – gardez-la à portée de main.

curl : socks5 vs socks5-hostname

curl est l'outil de référence pour comprendre la différence. Il offre un choix explicite.

  • --socks5 host:port – résolution locale. curl détermine lui-même l'IP, puis passe par le proxy.
  • --socks5-hostname host:port – résolution distante. curl transmet le nom au serveur proxy.

Via l'option --proxy, on peut aussi gérer le schéma : socks5://... donne une résolution locale, tandis que socks5h://... donne une résolution distante. Exemple d'appel correct pour une résolution distante : curl --proxy socks5h://user:pass@proxyhost:1080 https://example.com. Pour un proxy HTTP, le schéma http://... avec la méthode CONNECT résout par défaut sur le proxy, mais il faut tout de même vérifier le comportement réel.

Python : requests et httpx

Dans l'écosystème Python, le schéma socks5h est le standard de facto pour la résolution distante.

Pour requests, un package de support SOCKS est nécessaire. Le proxy est défini par un dictionnaire : utilisez le schéma socks5h://user:pass@host:port pour https et http. Le schéma socks5:// sans h signifie une résolution locale – c'est souvent la cause des fuites chez les débutants. Une seule lettre fait la différence.

Pour httpx, la logique est similaire : transmettez un proxy avec le schéma socks5h:// pour une résolution distante. httpx est strict avec les schémas et documente bien le comportement, mais le principe reste le même – la lettre h bascule la résolution du côté du proxy.

Observation importante : même en spécifiant socks5h, vérifiez que le proxy système via les variables d'environnement (HTTP_PROXY, ALL_PROXY) n'a pas un autre schéma qui s'applique. Les variables d'environnement peuvent surcharger vos intentions.

Node.js

Dans Node.js, il n'y a pas de support direct de SOCKS dans le http standard. On utilise des agents SOCKS qui créent la connexion via le proxy. Le paramètre clé de ces agents est une option qui détermine si le nom doit être résolu localement. Dans les agents SOCKS populaires, il existe un indicateur, généralement nommé quelque chose comme lookup ou une option responsable du DNS : lorsqu'elle désactive la recherche locale, le nom est transmis au proxy. Assurez-vous que l'agent est configuré pour transmettre le hostname, et non pour résoudre préalablement via dns.lookup.

Conseil pratique : dans Node, soyez particulièrement attentif à ne pas appeler dns.resolve ou dns.lookup quelque part dans le code avant d'établir la connexion. Une telle résolution prématurée annule la résolution distante.

Go

En Go, la bibliothèque standard fournit un package pour travailler avec les proxies. Via golang.org/x/net/proxy, on peut créer un dialer SOCKS5. Par défaut, le comportement dépend de si vous passez à Dial un nom ou une adresse déjà résolue. La clé est d'utiliser le dialer de sorte qu'il reçoive bien le nom de domaine, et non le résultat de net.LookupHost. Si vous résolvez vous-même et transmettez l'IP, c'est une résolution locale avec toutes les conséquences. La bonne approche : passer au dialer la chaîne host:port avec le nom et ne pas résoudre à l'avance.

Chrome : flags de lancement

Chrome se configure via des flags de ligne de commande et des politiques. Pour spécifier un proxy, on utilise le flag proxy-server. Il est critique que lorsque l'on travaille via SOCKS5, Chrome peut résoudre localement par défaut. Il existe un flag qui force la résolution pour les connexions proxyées à se faire côté proxy – son nom est lié à host-resolver-rules et à un paramètre qui force tous les hôtes à passer par le proxy. Il est également important de contrôler le DoH intégré : si Secure DNS est actif dans le navigateur et configuré avec son propre fournisseur, il peut contourner votre configuration. Pour la pureté du test, Secure DNS est généralement désactivé pendant la phase de diagnostic, et la politique WebRTC est renforcée.

Firefox : paramètres about:config

Firefox est historiquement plus pratique pour contrôler la résolution. Le paramètre clé est network.proxy.socks_remote_dns. Mettez-le à true, et Firefox enverra les noms d'hôtes au proxy SOCKS pour une résolution distante au lieu d'une résolution locale. C'est l'un des paramètres les plus importants de tout cet article. Contrôlez également :

  • network.trr.mode – le mode DoH (TRR, Trusted Recursive Resolver). Une valeur qui désactive le DoH forcé est importante si vous voulez que la résolution passe uniquement par le proxy.
  • media.peerconnection.enabled – pour gérer WebRTC et éviter une fuite via ICE.
  • les paramètres désactivant IPv6 ou le préchargement si un chemin parallèle est observé.

Selenium

Selenium pilote un vrai navigateur, donc la logique de résolution est héritée de Chrome ou Firefox. Pour Chrome, transmettez les mêmes flags via les options de lancement (arguments proxy-server et ceux liés à la résolution). Pour Firefox, définissez un profil avec network.proxy.socks_remote_dns activé via un objet de profil. Le secret du succès : ne vous fiez pas aux valeurs par défaut du driver – spécifiez explicitement la résolution distante dans le profil ou les flags, puis vérifiez le chemin réel.

Playwright

Playwright fournit un paramètre proxy lors du lancement d'un contexte ou d'un navigateur. Vous spécifiez server avec le schéma (par exemple socks5://host:port) et les identifiants. Il y a une subtilité : le comportement de la résolution dépend du moteur (Chromium, Firefox, WebKit) et de la manière dont le proxy est implémenté. Pour garantir la résolution distante dans le moteur Chromium, combinez la configuration proxy avec les arguments de lancement appropriés, et dans le moteur Firefox, avec le paramètre de profil socks_remote_dns. Terminez toujours la configuration par une vérification de fuite.

Tableau récapitulatif : client, comment activer la résolution distante, comment vérifier

Voici le tableau pratique principal de cet article :

  • curl – activer : utiliser --socks5-hostname ou le schéma socks5h:// dans --proxy – vérifier : curl en mode verbose et observer que le nom est transmis ; capture réseau pour l'absence de requêtes directes sur le port 53.
  • Python requests – activer : schéma socks5h:// dans le dictionnaire proxies – vérifier : requête vers un service montrant la source de résolution ; contrôle des variables d'environnement.
  • Python httpx – activer : proxy avec le schéma socks5h:// – vérifier : test de fuite, analyse du résolveur visible.
  • Node.js – activer : agent SOCKS avec transmission du hostname, sans dns.lookup préalable – vérifier : absence d'appels dns.resolve avant la connexion ; capture sur le port 53.
  • Go – activer : dialer SOCKS5, transmission de host:port avec le nom, sans net.LookupHost préalable – vérifier : journalisation de ce qui est passé au dialer ; tcpdump.
  • Chrome – activer : proxy-server avec SOCKS5, host-resolver-rules vers le proxy, désactiver Secure DNS pour le diagnostic – vérifier : test de fuite en ligne, comparaison de la région IP et de la région DNS.
  • Firefox – activer : network.proxy.socks_remote_dns à true, contrôle de network.trr.mode – vérifier : about:networking, test de fuite en ligne.
  • Selenium – activer : mêmes flags Chrome ou profil Firefox avec socks_remote_dns – vérifier : lancer un test de fuite dans le navigateur contrôlé.
  • Playwright – activer : paramètre proxy plus arguments du moteur pour la résolution distante – vérifier : navigation vers un test de fuite dans une session automatisée.

DoH et DoT : comment ils interagissent avec le proxy

DNS over HTTPS (DoH) et DNS over TLS (DoT) sont des méthodes de chiffrement des requêtes DNS. En elles-mêmes, elles sont excellentes pour protéger le contenu de la requête contre un observateur. Mais dans le contexte d'un proxy, elles génèrent des effets subtils qu'il faut comprendre.

Qu'est-ce que DoH et DoT en bref

DoT encapsule le DNS dans TLS sur un port dédié. DoH cache la requête DNS à l'intérieur d'un trafic HTTPS normal, la rendant indiscernable d'une navigation web. Les deux protocoles chiffrent la requête. Mais – et c'est critique – le chiffrement de la requête n'est pas équivalent à un routage via le proxy. Ce sont deux dimensions différentes.

Le conflit clé : le DoH du navigateur contourne le proxy

Voici l'information clé de cette section. Lorsqu'un navigateur active son propre DoH et est configuré pour résoudre via son propre fournisseur, il établit une connexion HTTPS vers le point de terminaison DoH. La question : cette connexion passe-t-elle par votre proxy ? Souvent non. Le navigateur peut ouvrir un canal DoH directement, car la résolution est perçue comme une opération de service, distincte de la navigation utilisateur.

Le résultat est paradoxal. D'un côté, la requête DNS est chiffrée et le fournisseur ne voit pas quel domaine vous demandez. De l'autre, cette requête part de votre vraie machine, de votre réseau, en contournant le proxy. Pour la géolocalisation, c'est un échec : l'infrastructure cible voit la résolution provenant de votre région, pas de celle du proxy. Votre belle configuration socks5h est contournée car le navigateur n'est pas passé par SOCKS pour la résolution – il a emprunté son propre chemin DoH.

Quand le DoH du navigateur casse complètement votre configuration

Précisons les situations où DoH contourne le proxy :

  • le navigateur est configuré pour un DoH forcé via son propre fournisseur, tandis que le proxy n'est défini que pour le trafic normal, pas pour la résolution de service ;
  • le système d'exploitation ou l'application a un DoH activé au niveau OS et il n'est pas encapsulé dans le tunnel ;
  • le point de terminaison DoH est mis en cache et la connexion vers lui a été établie avant l'application des paramètres proxy.

Conclusion pratique : pour les tâches où la cohérence de la région est importante, lors de l'utilisation d'un proxy, le DoH du navigateur et du système doit être soit désactivé, soit explicitement dirigé via le même proxy. La situation idéale est que toute la résolution, qu'elle soit chiffrée ou non, passe par le serveur proxy (résolution distante) et non en dehors.

DoT et proxy

DoT fonctionne sur un port dédié et se prête plus facilement aux politiques réseau, mais il peut tout aussi bien contourner le proxy s'il n'est pas explicitement encapsulé. Pour nos besoins, le principe est le même : contrôlez que la résolution passe par le proxy, pas par un canal indépendant.

Règle d'or du DoH dans le contexte d'un proxy

Souvenez-vous : le chiffrement de la résolution et son routage via le proxy sont des propriétés indépendantes. On peut avoir une résolution chiffrée qui révèle entièrement votre région car elle contourne le proxy. Pour la cohérence, cherchez toujours à obtenir une résolution distante sur le proxy, et traitez la question du chiffrement séparément et de manière consciente.

Comment vérifier : dig, nslookup, tcpdump et tests en ligne

Configurer est une chose. Un ingénieur se doit de vérifier que la résolution passe bien par le chemin prévu. Analysons les outils de diagnostic, des plus simples aux plus sérieux.

dig et nslookup via un proxy

dig et nslookup sont des utilitaires classiques pour la résolution manuelle. La subtilité est que le DNS classique fonctionne en UDP, alors que les proxies SOCKS ne proxyent nativement que le TCP. Par conséquent, vérifier la résolution via un proxy nécessite que la requête DNS passe par TCP, et que l'utilitaire soit dirigé via une enveloppe SOCKS. En pratique, pour observer le comportement, il est plus pratique d'encapsuler les outils via des programmes qui font passer le trafic TCP dans SOCKS. Le but de la vérification : s'assurer qu'avec une résolution distante, votre machine locale n'envoie pas elle-même de requêtes DNS, mais ne voit que le résultat arrivant via le canal proxy.

nslookup est utile pour une vérification rapide du résolveur qui répond et de l'IP retournée. Comparez l'IP obtenue localement avec l'IP à laquelle la connexion via le proxy se fait réellement. Une divergence indique que la résolution emprunte des chemins différents.

tcpdump sur le port 53 – le test le plus honnête

C'est ma méthode favorite car elle ne ment pas. Lancez une capture réseau sur votre machine avec un filtre sur le port 53 (et sur le 443 pour les soupçons DoH). Ensuite, effectuez une requête via le proxy. La logique est simple :

  • si, avec une résolution distante, vous voyez des paquets DNS sortants sur le port 53 directement depuis votre machine – vous avez une fuite, la résolution est locale ;
  • si le port 53 reste silencieux et que tout le trafic part dans le tunnel du proxy – la résolution distante fonctionne correctement ;
  • si le port 53 est silencieux mais qu'il y a des connexions HTTPS suspectes vers des points de terminaison DoH connus en contournant le proxy – vous avez une fuite via DoH.

tcpdump montre la réalité physique du réseau, pas les déclarations des configurations. C'est pourquoi il est indispensable lors de la vérification finale.

Test de fuite en ligne : comment lire correctement le résultat

Il existe des services web qui montrent quel résolveur a effectué votre requête DNS et dans quelle région il se trouve. La clé pour lire correctement le résultat est de ne pas confondre deux paramètres :

  • votre IP visible – c'est l'IP d'où provient la connexion HTTP, c'est-à-dire l'IP du proxy ;
  • le résolveur DNS – c'est l'adresse et la région de celui qui a effectivement effectué la résolution.

La bonne situation avec une résolution distante : l'IP visible et le résolveur pointent tous deux vers la région du proxy. Un signe alarmant : l'IP visible est dans la région du proxy, mais le résolveur est dans votre région réelle. C'est une fuite classique via la résolution locale. Une autre variante de fuite : le résolveur appartient à un grand fournisseur DoH, mais la connexion vers lui a contourné le proxy – alors la région du résolveur peut être neutre, mais le chemin lui-même ne passe pas par le proxy, ce qui est déjà visible via tcpdump.

Check-list de vérification de la résolution

Suivez ces étapes dans l'ordre :

  1. Videz le cache DNS du système d'exploitation et du navigateur, redémarrez l'application.
  2. Assurez-vous que le schéma est socks5h ou que la résolution distante est activée dans le client.
  3. Vérifiez les variables d'environnement du proxy pour des schémas conflictuels.
  4. Lancez tcpdump avec un filtre sur les ports 53 et 443.
  5. Effectuez une requête via le proxy vers une ressource de test.
  6. Vérifiez qu'aucun paquet DNS direct n'apparaît sur le port 53.
  7. Vérifiez l'absence de connexions HTTPS indépendantes vers des points de terminaison DoH.
  8. Ouvrez un test de fuite en ligne et comparez la région de l'IP avec celle du résolveur.
  9. Vérifiez le chemin IPv6 : absence de requêtes AAAA parallèles et de connexions.
  10. Documentez la configuration de référence dans la documentation de l'équipe.

Erreurs typiques que presque tout le monde commet

Au fil des années de travail avec les proxies, on accumule une collection de râteaux. Analysons les plus fréquents pour que vous ne marchiez pas dedans.

Erreur 1 : confondre socks5 et socks5h

Le leader absolu. Une personne écrit socks5:// et est convaincue que la résolution est distante. Mais elle est locale. Une lettre manquante – et toute la région dérape. Spécifiez toujours explicitement socks5h si vous avez besoin d'une résolution distante, et vérifiez-le par capture réseau.

Erreur 2 : configurer le proxy mais oublier DoH

Un classique pour les navigateurs. Le proxy est défini, mais le Secure DNS / DoH intégré est actif et le contourne. L'utilisateur voit la bonne IP et se repose, pendant que la résolution fuit. Synchronisez toujours la politique DoH avec le proxy.

Erreur 3 : ignorer IPv6

Le proxy est en IPv4, mais la machine vit en double pile. Happy Eyeballs fait son travail, et une partie des connexions part directement en IPv6. Soit désactivez IPv6 pour l'application, soit assurez-vous que le proxy gère également IPv6.

Erreur 4 : résolution locale préalable dans le code

Un problème courant en Node.js et Go. Le développeur, de bonne foi, appelle une résolution à l'avance (pour vérification, pour journalisation) et transmet au proxy l'IP déjà obtenue. La résolution distante est morte. Ne résolvez pas le nom avant de le passer au dialer proxy.

Erreur 5 : faire confiance aux variables d'environnement

HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY – des saboteurs silencieux. Ils surchargent les paramètres dans le code ou entrent en conflit avec le schéma. Vérifiez l'environnement avant de lancer et nettoyez ce qui est superflu.

Erreur 6 : croire la configuration plutôt que de vérifier

Vous avez écrit la bonne ligne et vous passez à autre chose. Mais la configuration est une intention, pas un fait. Le comportement réel ne se vérifie que par capture réseau et test de fuite. Ne terminez jamais une configuration sans vérification.

Erreur 7 : cache DNS oublié

Vous changez la configuration, mais le résultat reste le même – car les anciennes entrées et connexions sont mises en cache. Videz toujours le cache et redémarrez avant de vérifier.

Erreur 8 : mélanger les types de proxy dans le même pipeline

Un endroit utilise un proxy HTTP avec CONNECT, un autre un SOCKS avec résolution locale. Le comportement de résolution diffère, et une partie des requêtes fuit. Uniformisez l'approche sur tout le pipeline.

Erreur 9 : ne pas tenir compte du cache de l'application

Certaines applications conservent leur propre cache DNS et un pool de connexions qui survivent aux changements de configuration. Un redémarrage du processus est parfois obligatoire.

Erreur 10 : ignorer WebRTC dans l'automatisation

Lors de l'automatisation des navigateurs, WebRTC est souvent oublié. Le navigateur contrôlé peut tranquillement lancer ICE et révéler des chemins en contournant le proxy. Contrôlez toujours la politique WebRTC dans les sessions automatisées.

Outils et ressources pour travailler avec la résolution via proxy

Rassemblons l'arsenal à garder à portée de main. Divisons par fonction.

Outils de diagnostic

  • tcpdump – capture du trafic réseau, le juge de paix pour les chemins de résolution.
  • Wireshark – analyse graphique des paquets, pratique pour les cas complexes avec DoH et IPv6.
  • dig et nslookup – résolution manuelle, vérification rapide des réponses du résolveur.
  • tests de fuite DNS en ligne – montrent le résolveur et sa région, donnent un verdict rapide.
  • about:networking dans Firefox – diagnostic intégré des connexions et du DNS du navigateur.

Outils et bibliothèques de configuration

  • curl – référence pour tester le comportement de socks5 et socks5-hostname, idéal pour le débogage.
  • Encapsuleurs SOCKS pour trafic TCP – permettent de faire passer une application arbitraire dans SOCKS pour des tests de résolution.
  • Bibliothèques SOCKS pour les langages – packages de support SOCKS en Python, agents SOCKS en Node.js, package proxy en Go.
  • Outils d'automatisation de navigateurs – Selenium et Playwright avec configuration explicite du proxy et de la résolution.

Ressources de connaissances

  • documentation officielle de curl sur les options proxy – meilleure source pour la sémantique socks5 vs socks5h ;
  • documentation des clients HTTP Python sur l'utilisation des proxies et des schémas ;
  • références about:config de Firefox pour les paramètres réseau et de résolution ;
  • documentation de votre fournisseur de proxy, en particulier du service MobileProxy.space, où les schémas supportés et les recommandations pour la résolution distante avec les proxies mobiles sont décrits.

Mini-framework de choix d'approche

Pour ne pas vous perdre, gardez cette logique simple :

  1. Vous avez besoin de trafic HTTPS et de résolution distante ? Proxy HTTP avec CONNECT ou SOCKS5 avec le schéma socks5h.
  2. Vous travaillez depuis une bibliothèque ou en CLI ? Spécifiez explicitement socks5h ou le flag de résolution distante.
  3. Vous travaillez depuis un navigateur ? Activez la résolution distante, désactivez ou dirigez DoH via le proxy, limitez WebRTC et IPv6.
  4. Terminez toujours la configuration par une capture réseau et un test en ligne.

Cas concrets et résultats : à quoi cela ressemble en pratique

La théorie sans pratique est morte. Analysons des cas généralisés reflétant des situations typiques. Les chiffres sont indicatifs, mais les proportions et la logique sont tirées de la pratique réelle d'ingénierie.

Cas 1 : désynchronisation de région chez un analyste de données

Une équipe collectait des données via un script Python avec un proxy dans la région souhaitée. Les résultats arrivaient avec une localisation d'un autre pays dans environ quarante pour cent des cas. Le diagnostic a montré le schéma socks5:// dans le dictionnaire proxies – résolution locale. Le remplacer par socks5h:// a complètement éliminé la désynchronisation. tcpdump a confirmé : les requêtes directes sur le port 53 ont disparu. Leçon : une seule lettre a résolu un problème sur lequel on avait passé deux jours.

Cas 2 : fuite via le DoH du navigateur en automatisation

Lors de l'automatisation de Chromium via Playwright, la région IP était correcte, mais la ressource cible persistait à détecter une autre région. Un test en ligne a montré un résolveur ne correspondant pas à la région du proxy. Wireshark a révélé des connexions HTTPS indépendantes vers un point de terminaison DoH en contournant le proxy. Solution : désactiver Secure DNS dans la configuration de lancement et forcer la résolution distante. Après correction, la région du résolveur correspondait à celle de l'IP, et les faux positifs anti-fraude ont chuté de manière significative.

Cas 3 : IPv6 parallèle dans un microservice

Un service Go passait par SOCKS5, mais périodiquement, une partie des requêtes partait directement. La cause : la double pile et des tentatives IPv6 contournant le proxy. Limiter le client à l'IPv4 uniquement et transmettre correctement le nom dans le dialer a éliminé la fuite. tcpdump a cessé de montrer des requêtes AAAA directes. La stabilité de la région a atteint près de cent pour cent.

Cas 4 : les variables d'environnement saboteuses

Un script se comportait différemment sur deux machines avec un code identique. Sur l'une, la résolution distante fonctionnait, sur l'autre non. L'explication : sur la machine problématique, la variable ALL_PROXY était définie avec un schéma sans h, surchargeant les paramètres. Après avoir nettoyé l'environnement, le comportement est devenu cohérent. Leçon : l'environnement fait partie de la configuration, il doit être contrôlé aussi strictement que le code.

Conclusion générale des cas

Remarquez la régularité. Dans tous les cas, le symptôme était similaire – mauvaise région ou déclenchement de la protection – mais les causes étaient différentes : schéma, DoH, IPv6, environnement. C'est pourquoi un diagnostic systématique via une check-list est plus important que l'intuition. Une approche structurée trouve la racine plus rapidement que les suppositions.

FAQ : questions fréquemment posées

Quelle est la différence entre socks5 et socks5h en termes simples ?

socks5 résout le nom de domaine de votre côté et envoie l'IP prête au proxy. socks5h envoie le nom lui-même au proxy, et c'est le proxy qui résout. Pour la vie privée et une géolocalisation correcte, c'est presque toujours socks5h qu'il faut utiliser. La lettre h signifie hostname – le nom d'hôte est transmis à distance.

Si j'utilise un proxy HTTP, dois-je me soucier de la résolution ?

Avec HTTPS via la méthode CONNECT, le nom va généralement au proxy et celui-ci résout lui-même – c'est bon. Mais certains clients résolvent localement auparavant et transmettent l'IP dans CONNECT. Même avec un proxy HTTP, vérifiez donc le comportement réel par capture réseau.

Pourquoi l'IP est correcte mais le site voit une autre région ?

Presque certainement, votre requête DNS contourne le proxy – via un résolveur local ou le DoH du navigateur. L'infrastructure cible, via la géolocalisation DNS et le CDN, détermine la région de votre résolveur, pas celle du proxy. Solution : résolution distante et contrôle de DoH.

Quel est le lien entre WebRTC et la résolution et les fuites ?

WebRTC, pour établir des connexions, collecte des candidats réseau et peut lancer des requêtes qui contournent le proxy. Cela peut révéler des chemins et des adresses. Lorsque l'on utilise un proxy, surtout en automatisation de navigateurs, il faut contrôler ou limiter la politique WebRTC.

DoH casse-t-il ma configuration proxy ?

Peut la casser. Le chiffrement de la résolution et son routage via le proxy sont deux choses différentes. Le DoH du navigateur ou du système peut partir directement, contournant le proxy et révélant votre région. Pour la cohérence, désactivez ce DoH ou dirigez la résolution via le proxy.

Comment vérifier rapidement s'il y a une fuite ?

Deux étapes. Premièrement, lancez tcpdump avec un filtre sur le port 53 et effectuez une requête via le proxy : des paquets DNS directs indiquent une fuite. Deuxièmement, ouvrez un test en ligne et comparez la région de l'IP visible avec celle du résolveur. S'ils correspondent, c'est bon ; s'ils diffèrent, c'est une fuite.

Que faire avec IPv6 si le proxy est uniquement en IPv4 ?

Soit désactivez IPv6 pour l'application utilisant le proxy, soit assurez-vous que le proxy gère IPv6 et que tout le trafic, y compris la résolution AAAA, passe par lui. Sinon, l'algorithme Happy Eyeballs enverra une partie des connexions directement, contournant le proxy.

Pourquoi un même code se comporte-t-il différemment sur deux machines ?

Une cause fréquente : les variables d'environnement du proxy (HTTP_PROXY, ALL_PROXY, etc.). Elles surchargent les paramètres du code ou définissent un autre schéma. Vérifiez et nettoyez l'environnement pour obtenir un comportement cohérent.

Suffit-il de spécifier socks5h pour être sûr de ne pas avoir de fuites ?

Pour l'application elle-même, c'est un grand pas en avant, mais ce n'est pas une garantie pour l'ensemble du système. Il reste des canaux comme le DoH du navigateur, WebRTC et IPv6. Une protection complète passe par la résolution distante, le contrôle de tous les canaux de contournement, et une vérification obligatoire par capture réseau.

Peut-on effectuer une résolution via proxy en ligne de commande pour tester ?

Oui. curl avec l'option --socks5-hostname ou le schéma socks5h est le moyen le plus simple de tester la résolution distante. Pour des utilitaires comme dig, il est pratique d'encapsuler le trafic TCP dans SOCKS, en gardant à l'esprit que le DNS classique sur UDP n'est pas nativement proxyé par SOCKS.

Conclusion : résumé et prochaines étapes

Nous avons parcouru le chemin du symptôme à une compréhension approfondie. Résumons l'essentiel dans un cadre sémantique compact qui restera avec vous.

La résolution de nom de domaine est une transaction réseau distincte qui peut emprunter un chemin différent de votre trafic principal. C'est cette indépendance qui génère la plupart des problèmes. Quatre acteurs peuvent effectuer la résolution : le système d'exploitation, la bibliothèque de l'application, le navigateur et le proxy lui-même. Votre objectif est presque toujours de confier la résolution au serveur proxy afin que le nom soit déterminé depuis le bon point du réseau.

La différence entre socks5 et socks5h est fondamentale. socks5 – résolution locale, socks5h – résolution distante. Une seule lettre change tout : la région, la vie privée, la cohérence. Les proxies HTTP avec la méthode CONNECT transmettent naturellement le nom au proxy, mais même là, ne faites pas aveuglément confiance – vérifiez.

Les fuites se résument à un principe : il existe un canal par lequel le nom ne passe pas par le proxy. Résolveur système, WebRTC, DoH du navigateur, IPv6 parallèle, cache – voilà les principaux suspects. Et rappelez-vous l'information clé : le chiffrement de la résolution n'est pas équivalent à son routage via le proxy. On peut avoir un DoH chiffré qui révèle entièrement votre région.

Que faire maintenant ? Voici votre plan d'action :

  1. Passez en revue vos configurations actuelles et remplacez socks5 par socks5h là où vous avez besoin d'une résolution distante.
  2. Vérifiez les navigateurs : activez la résolution distante, gérez la politique DoH et WebRTC.
  3. Assurez-vous qu'IPv6 ne crée pas de chemin parallèle contournant le proxy.
  4. Nettoyez les variables d'environnement du proxy des valeurs conflictuelles.
  5. Effectuez une vérification via tcpdump et un test en ligne selon la check-list de l'article.
  6. Documentez la configuration de référence dans la documentation de votre équipe pour éviter de réinventer la roue.

Le sujet de la résolution via proxy semble restreint, mais c'est sur lui que se brisent les configurations les plus coûteuses et les plus frustrantes. Vous avez maintenant la carte du terrain : vous comprenez qui résout, où la décision est prise, comment les fuites surviennent et comment les colmater. Gardez cet article sous la main et revenez au tableau et aux check-lists chaque fois que le proxy est connecté mais que le site persiste à voir une mauvaise région. Vous savez désormais où chercher.