Vous configurez un proxy sur une sortie allemande, vous lancez votre collecte, et la cible continue de vous servir du contenu pour la mauvaise région. L’adresse de sortie est bien allemande, les requêtes réussissent, et pourtant les résultats semblent provenir de l’endroit où votre serveur se trouve réellement. Une cause fréquente est que la connexion est passée par le proxy mais que la résolution de nom, non.
C’est une fuite DNS. Dans un contexte de confidentialité, on la décrit comme le fait que votre résolveur voit quels domaines vous visitez, ce qui est réel, mais pour la collecte de données il y a une conséquence plus immédiate : la résolution DNS est souvent sensible à la géographie, donc résoudre localement en sortant à distance produit une incohérence qui peut vous donner le mauvais point de terminaison régional et corrompre silencieusement un jeu de données ciblé géographiquement.
Ce qui fuit réellement, et pourquoi c’est important ici
Une requête vers un nom d’hôte comporte deux étapes : transformer le nom en adresse, puis se connecter à cette adresse. Un proxy intercepte la seconde étape. Le fait qu’il intercepte la première dépend entièrement de votre client.
Quand le client résout localement, la requête DNS part de votre propre réseau vers votre propre résolveur, révélant le domaine à votre FAI ou à l’opérateur de votre résolveur, et renvoyant une réponse calculée pour votre emplacement.
C’est ce dernier point qui casse la collecte. Les grands sites reposent sur des CDN et un DNS sensible à la géographie qui renvoient des adresses différentes selon l’endroit d’où provient la requête, de sorte qu’une résolution locale peut pointer vers un nœud de périphérie proche de votre serveur plutôt que de votre sortie proxy. Vous vous connectez alors à ce nœud via une adresse allemande, et cette incohérence peut produire du contenu pour la mauvaise région, des résultats incohérents d’une exécution à l’autre, ou un signal qui paraît inhabituel à la cible. Si votre travail dépend d’un ciblage au niveau de la ville, ce mode de défaillance mérite d’être écarté en premier lorsque la géographie semble erronée, en plus des différences entre bases de données de géolocalisation qui sont l’autre cause fréquente.
Les proxys HTTP fuient rarement, SOCKS5 souvent
Le comportement diffère selon le protocole, et c’est le cœur du problème.
Avec un proxy HTTP, une requête HTTPS utilise CONNECT et envoie le nom d’hôte au proxy, qui le résout à distance. Le HTTP simple envoie de la même façon une URL absolue contenant le nom d’hôte. Dans les deux cas, le proxy effectue la résolution par conception, donc un usage ordinaire de proxy HTTP ne fuit pas le DNS.
Avec SOCKS5, le protocole prend en charge les deux cas. Il peut accepter un nom d’hôte et le résoudre à distance, ou accepter une adresse que le client a résolue lui-même. Lequel des deux se produit est une décision du client, et de nombreux clients résolvent localement par défaut. C’est pourquoi la même passerelle fuit avec une configuration et pas avec une autre, et c’est presque toujours un paramètre côté client plutôt que quelque chose lié au proxy.
Dans la plupart des outils, la distinction tient à un seul caractère. socks5:// signifie résoudre localement, socks5h:// signifie transmettre le nom d’hôte au proxy. Le h est toute la solution.
Corriger cela selon le client
curl. Utilisez le schéma socks5h, ou --proxy avec ce schéma, plutôt que socks5 :
# fuite : résolution locale
curl -x socks5://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.com
# correct : nom d'hôte résolu au niveau du proxy
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comPython. Avec requests et PySocks, le schéma porte la même signification, et il est facile de se tromper car les deux orthographes fonctionnent :
import requests
user = "customer-USERNAME-country-de"
PROXY = f"socks5h://{user}:PASSWORD@p.shifter.io:443" # notez le h
r = requests.get("https://example.com",
proxies={"http": PROXY, "https": PROXY}, timeout=20)Plus simple encore, utilisez le schéma HTTP contre la même passerelle, qui résout à distance par défaut et évite entièrement la question. C’est la configuration présentée dans utiliser des proxys résidentiels avec Python.
Node. Les agents socks exposent généralement un indicateur pour la résolution à distance ; vérifiez qu’il est activé plutôt que de le supposer, car les valeurs par défaut diffèrent entre bibliothèques et versions.
Navigateurs headless. C’est là que les fuites sont les plus probables, car un navigateur a son propre comportement de résolution indépendant du paramètre du proxy. Chromium résout via sa propre pile et nécessite de contraindre explicitement le chemin DNS lors de l’utilisation de SOCKS ; Firefox dispose d’une préférence contrôlant si les noms d’hôtes SOCKS sont résolus à distance, et elle n’est pas toujours activée par défaut. Si vous pilotez des navigateurs, vérifiez plutôt que de supposer, et notez les canaux de fuite spécifiques aux navigateurs ci-dessous.
Tester si vous fuyez réellement
Ne présumez pas à partir de la configuration. Il existe trois niveaux de vérification.
Le plus rapide consiste à comparer ce que la cible voit avec ce que vous attendez : récupérez un point de terminaison qui rapporte l’adresse qu’il a observée et confirmez qu’elle correspond à votre région de sortie, puis récupérez une page sensible à la géographie et confirmez que le contenu correspond. Si l’adresse est correcte mais que le contenu ne l’est pas, le DNS est un suspect de premier plan.
Plus directement, surveillez le trafic DNS sortant pendant l’exécution d’une requête via proxy. Sur la machine effectuant la requête, si vous voyez des requêtes pour le nom d’hôte de votre cible sortir sur le port 53, la résolution se fait localement :
# terminal 1
sudo tcpdump -n -i any port 53
# terminal 2
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comSi des requêtes pour le nom d’hôte de la cible apparaissent dans la capture, le client a résolu localement et vous avez trouvé la fuite.
Troisièmement, pour l’automatisation de navigateur, utilisez l’une des pages publiques de test de fuite DNS, qui rapportent les résolveurs ayant répondu en votre nom, et vérifiez s’ils se situent dans la région de votre sortie ou dans la vôtre.
Les autres canaux de fuite à connaître
Le DNS est le cas fréquent, mais pour être complet, trois autres canaux produisent la même catégorie de défaillance.
IPv6. Si le proxy ne gère que l’IPv4 et que votre système préfère l’IPv6 pour une cible à double pile, ce trafic peut contourner entièrement le proxy. Désactiver l’IPv6 sur la machine effectuant la collecte, ou forcer l’IPv4 dans le client, élimine toute une catégorie de résultats déroutants.
WebRTC. Dans de vrais navigateurs, WebRTC peut exposer des adresses locales et publiques via un mécanisme distinct qui ignore les paramètres du proxy. Si vous pilotez un navigateur pour quoi que ce soit de sensible à l’identité, désactivez-le.
Valeurs par défaut du système et des bibliothèques. Certains runtimes mettent en cache les résultats DNS de manière agressive ou consultent le résolveur du système indépendamment de la configuration du proxy, et une entrée dans le fichier hosts ou un résolveur de cache local peut annuler tout ce que vous avez configuré.
Si la cohérence d’identité compte pour votre travail, le DNS n’est qu’une couche parmi d’autres, et l’ensemble plus large de signaux devant concorder est traité dans empreinte TLS et HTTP/2 et éviter les blocages.
Une checklist rapide
Préférez le schéma HTTP contre la passerelle sauf si vous avez spécifiquement besoin de SOCKS5, car il résout à distance par défaut. Si vous utilisez SOCKS5, utilisez socks5h partout et passez votre code au crible pour repérer les socks5:// isolés qui traînent. Vérifiez avec une capture de paquets sur le port 53 plutôt que de faire confiance à la configuration. Forcez l’IPv4 si votre chemin proxy est uniquement en IPv4. Désactivez WebRTC dans les navigateurs automatisés. Puis relancez une requête sensible à la géographie et confirmez que le contenu correspond à la région de sortie plutôt qu’à la vôtre.
En résumé
Une fuite DNS signifie que votre trafic est passé par le proxy alors que la résolution de nom, non, ce qui expose les domaines que vous interrogez à votre propre résolveur et, plus important pour la collecte, les résout depuis votre emplacement plutôt que depuis votre sortie. Le proxying HTTP résout à distance par défaut et fuit rarement ; SOCKS5 fuit dès que le client résout localement, ce qui explique pourquoi socks5h par rapport à socks5 est la correction la plus fréquente. Les navigateurs headless nécessitent une attention explicite car ils résolvent indépendamment de votre paramètre de proxy. Testez avec une capture de paquets plutôt que de faire confiance à la configuration, et écartez l’IPv6 et WebRTC tant que vous y êtes. Quand une tâche ciblée géographiquement renvoie du contenu pour la mauvaise région alors que l’adresse de sortie semble correcte, c’est la première chose à vérifier.
La passerelle parle à la fois HTTP(S) et SOCKS5 sur le même point de terminaison, donc changer de schéma pour tester ne coûte rien : voir passerelle et authentification. Le produit est constitué des proxys résidentiels avec ciblage par pays et par ville et une tarification par GB.