Un proxy ne modifie que l’adresse de sortie. La résolution DNS, IPv6, le fuseau horaire et la langue, ainsi que les empreintes graphiques peuvent encore révéler des incohérences de l’environnement.
Le proxy est configuré et la page de test indique la région cible, pourtant le compte reste associé. Le premier réflexe est souvent d’accuser le proxy et d’en changer. Si le problème persiste après plusieurs changements, l’adresse de sortie n’est probablement pas en cause.
Un proxy ne peut modifier que le point de sortie des requêtes réseau. Pour que les sites fonctionnent normalement, le navigateur expose activement de nombreuses informations : versions du système et du navigateur, fuseau horaire, langue, résolution d’écran, caractéristiques graphiques et audio, ainsi que l’état du réseau local. Lorsque ces signaux ne concordent pas, la plateforme voit un environnement incohérent plutôt qu’un utilisateur normal ayant simplement changé d’IP.
La plupart des canaux ci-dessous ne passent pas nécessairement par le tunnel du proxy.
La résolution DNS peut ne pas suivre le proxy
Le trafic peut passer par le proxy tandis que les requêtes de résolution de noms continuent d’être émises par le réseau local. Le site cible voit l’adresse du proxy, mais les journaux de requêtes DNS peuvent pointer vers le réseau réellement utilisé.
Utilisez un test de fuite DNS pour vérifier l’origine des requêtes de résolution. L’objectif est de faire passer les requêtes DNS par le chemin du proxy ou d’utiliser un résolveur correspondant à la région de sortie.
IPv6 peut contourner le proxy en connexion directe
C’est l’un des canaux les plus faciles à oublier. Si le réseau local prend en charge IPv4 et IPv6 alors que le proxy ne gère que le trafic IPv4, le navigateur peut accéder directement au site cible via IPv6.
Dans ce cas, le proxy est pratiquement contourné. Vérifiez si la page de test renvoie une adresse IPv6. Au niveau de l’environnement, contrôlez l’activation d’IPv6 afin que le trafic ne puisse pas passer autour du proxy.
Un fuseau horaire et une langue incohérents peuvent être plus faciles à détecter qu’une fuite
Techniquement, ce n’est pas une fuite d’IP, mais les conséquences peuvent être plus importantes, car cela crée une contradiction géographique.
Une IP de la région cible combinée à un fuseau horaire local, une interface en langue locale et un format d’heure local constitue une incohérence typique. Les contradictions peuvent déclencher des contrôles de risque plus facilement qu’un seul signal exposé : une fuite peut être une omission isolée, alors qu’une contradiction suggère un environnement assemblé à partir d’éléments incompatibles.
Vérifiez que l’IP de sortie, le fuseau horaire et la langue correspondent comme un ensemble. Il est préférable d’activer la synchronisation automatique avec l’IP de sortie plutôt que de les définir manuellement.
Les empreintes graphiques et audio identifient l’appareil
Les caractéristiques graphiques produites par Canvas et WebGL, ainsi que les différences de formes d’onde liées au traitement audio, reflètent des propriétés matérielles indépendantes du réseau.
Même si l’IP passe dans un autre pays, la carte graphique continue de produire le rendu de la même machine. À ce niveau, ce n’est pas l’IP qui est exposée, mais l’identité de l’appareil.
Comparez plusieurs environnements et vérifiez si leurs empreintes graphiques se répètent. Chaque environnement doit disposer de sa propre empreinte au lieu de partager un profil unique pour toutes les tâches.
L’instant du changement de proxy
Lorsqu’un proxy se déconnecte, change de nœud ou se connecte pour la première fois, le navigateur peut envoyer des requêtes avant que le tunnel soit actif.
Ce phénomène est difficile à détecter sur une page de test et nécessite généralement d’examiner l’origine des requêtes dans les journaux. Mettez en pause l’activité du navigateur pendant le changement de proxy et reprenez uniquement lorsque la connexion est stable.
WebRTC est aussi un canal
WebRTC est le canal le plus souvent cité. Ses détails sont traités séparément ; ici, il est simplement compté parmi les voies d’exposition.
Une checklist pratique d’auto-vérification
| Canal | Élément à vérifier | Résultat attendu |
|---|---|---|
| DNS | Origine des requêtes de résolution | Suit le chemin du proxy |
| IPv6 | Présence d’une adresse IPv6 renvoyée | Non exposée |
| Paramètres géographiques | IP de sortie, fuseau horaire, langue | Les trois correspondent |
| Empreintes graphiques et audio | Répétition entre environnements | Indépendantes par environnement |
| Stabilité du proxy | Fenêtre de changement pendant la tâche | Stable en continu |
| WebRTC | Adresse renvoyée | Correspond à l’adresse du proxy |
Configurer l’environnement comme un ensemble
Un proxy ne résout qu’un seul de ces canaux. L’environnement forme un tout, et l’exposition par un seul canal peut suffire à faire reconnaître l’ensemble.
L’enjeu n’est donc pas de chercher sans cesse un meilleur proxy, mais de configurer et vérifier l’environnement comme une unité cohérente : empreintes indépendantes, sorties réseau liées à chaque environnement et paramètres géographiques concordants. C’est précisément la couche traitée par PurpleMark, qui sépare plusieurs environnements sur un même appareil afin que la sortie et les paramètres suivent chacun d’eux.
Ces mesures servent à maintenir un fonctionnement stable des comptes conformes : respectez les conditions d’utilisation des plateformes et les protocoles robots, n’utilisez pas de fausses informations d’identité et ne contournez pas les mesures techniques de protection.
Ces informations servent uniquement à expliquer des principes techniques. Utilisez les outils concernés uniquement dans un cadre légal et conforme.
