Test de fuite IP et DNS : Vérifiez la sécurité de votre réseau

De nombreux utilisateurs pensent que l'achat d'un "proxy résidentiel" suffit à se faire passer pour un internaute domestique ordinaire. Cependant, les moteurs modernes de détection des risques ne se fient plus uniquement aux étiquettes statiques des bases GeoIP (comme IP2Location ou MaxMind). Même lorsqu'une IP de sortie est classée comme résidentielle/FAI, la passerelle proxy intermédiaire s'exécute presque toujours sur un serveur Linux dans le cloud, ce qui génère des contradictions manifestes entre les couches : Premièrement, la signature de la pile TCP : le serveur de sortie émet la séquence d'options standard de Linux (MSS, SACK_PERM, TS, NOP, WS) lors du handshake SYN initial plutôt que l'ordre propre à Windows ou Apple. Deuxièmement, la discordance du MTU de chemin : une connexion résidentielle PPPoE présente typiquement un MTU de 1492 (les réseaux mobiles entre 1400 et 1430), tandis qu'Ethernet en centre de données est à 1500 (MSS=1460). Lorsqu'un système anti-fraude détecte une IP résidentielle associée à un MTU de centre de données et une pile Linux, il classe la connexion comme un proxy automatisé.

💡 Testez votre connexion avec notre Test d'anonymat de proxy pour vérifier où votre session TCP se termine.

Il n'existe aucun lien physique fixe entre une adresse IP et une position géographique réelle. Les résultats dépendent de la base de données commerciale GeoIP utilisée et de sa fréquence de mise à jour : Premièrement, les sources de données et modèles de mesure varient : les fournisseurs (comme MaxMind, IP2Location ou DB-IP) analysent les annonces BGP, les registres whois et les temps de latence avec des pondérations et des cycles de rafraîchissement allant de quelques jours à plusieurs mois. Deuxièmement, le routage Anycast et les réseaux CDN : des acteurs comme Cloudflare annoncent un même bloc d'adresses IP depuis des centaines de centres de données mondiaux, dirigeant automatiquement la requête vers le point de présence le plus proche. Troisièmement, les réaffectations internationales d'adresses IP : lorsqu'un hébergeur transfère un bloc d'IP enregistré dans un pays vers des serveurs situés dans un autre, les bases obsolètes continuent de rapporter l'ancienne localisation. Notre outil combine des vérifications multi-bases avec une multilateration de délai RTT à la vitesse de la lumière pour authentifier les zones physiques réelles.

Un score de fraude d'IP (ou score de risque) est un indice numérique (généralement compris entre 0 et 100) utilisé par les moteurs de sécurité pour évaluer la probabilité qu'une connexion provienne d'une activité automatisée ou dissimulée. Les principaux facteurs d'évaluation comprennent : Premièrement, la réputation historique et les listes de blocage : si l'IP a été récemment impliquée dans des attaques de type credential stuffing, du web scraping massif, du spam ou des scans de vulnérabilités. Deuxièmement, le type d'ASN et l'infrastructure : les réseaux de centres de données (hébergement) et de proxys publics présentent un risque de base bien plus élevé que les accès résidentiels ou mobiles. Troisièmement, la cohérence multipoint et protocolaire : la détection d'exits divergents en double pile IPv4/IPv6, le décalage géographique du résolveur DNS ou l'exposition de l'IP locale via WebRTC.

💡 Utilisez notre Test de Split Tunneling pour détecter les fuites de routage susceptibles d'augmenter votre score de risque.

Même avec un VPN ou un proxy activé, votre véritable identité peut s'échapper via des canaux secondaires : Premièrement, les fuites DNS : lorsque le navigateur effectue une résolution de nom de domaine, si le client proxy ne capture pas les requêtes au niveau du système d'exploitation, les requêtes partent en clair vers le serveur DNS de votre FAI local, révélant ainsi les sites consultés et votre véritable position géographique. Deuxièmement, les fuites WebRTC : WebRTC est une technologie de communication multimédia en temps réel intégrée aux navigateurs qui, lors de l'établissement de liaisons peer-to-peer (P2P), contourne les couches proxy HTTP/SOCKS pour envoyer directement des paquets STUN en UDP, exposant vos adresses IP locale et publique réelles. Notre page d'accueil analyse vos sorties DNS et l'état de WebRTC en temps réel.

💡 Pour inspecter les fuites matérielles et multimédias, consultez le Test d'empreinte du navigateur.

Le panneau de pile réseau de la page d'accueil exécute trois sondes associées en parallèle : une interroge un domaine avec uniquement des enregistrements A (iptestv4.myipdns.com), une autre un domaine avec uniquement des enregistrements AAAA (iptestv6.myipdns.com), et la troisième un domaine double pile comportant les deux familles d'enregistrements. Les deux premières sont obligatoires : chaque nom d'hôte ne résolvant qu'une seule famille d'adresses, votre système n'a pas le choix, ce qui permet de mesurer indépendamment vos sorties réelles en IPv4 et en IPv6. La troisième sonde n'impose rien ; elle observe au contraire quelle famille d'adresses votre système a lui-même sélectionnée, ce qu'affiche la colonne « Protocole préféré » : ce résultat découle de la politique de sélection d'adresses du système d'exploitation et du navigateur (Happy Eyeballs, RFC 8305 : lorsque les deux piles sont joignables, IPv6 est tenté en premier, IPv4 servant de repli), sans intervention de notre part. Aligner ces trois mesures est primordial car de nombreux clients proxy et VPN ne prennent en charge que l'IPv4 : si votre sortie IPv4 relève de l'ASN du proxy tandis que votre sortie IPv6 demeure celle de votre FAI résidentiel, et que le protocole préféré indique IPv6, lors de l'accès à des sites double pile, la majeure partie de votre trafic n'emprunte absolument pas le tunnel — c'est le cas le plus fréquent de « VPN actif mais identité réelle exposée », sans qu'aucune erreur ne soit signalée.

⚠ Nous pouvons uniquement vous indiquer si vos sorties des deux familles se situent sur des réseaux distincts ; nous ne pouvons pas déterminer la configuration requise pour votre logiciel proxy. Inversement, une sortie IPv6 affichée comme indisponible n'équivaut pas à une garantie de sécurité : votre réseau peut simplement ne pas disposer d'IPv6, ou le proxy peut avoir désactivé intégralement l'IPv6 — ce dernier cas constituant souvent la bonne pratique.

Nous ne lisons pas les paramètres de votre système local : les navigateurs en sont incapables, et toute page prétendant lire votre configuration DNS locale ne fait que deviner. La méthode réelle consiste à procéder au test inverse : notre site héberge son propre serveur DNS faisant autorité et génère lors de chaque test un sous-domaine aléatoire temporaire (de type k3f9x2ab.leakv4.myipdns.com) que votre navigateur doit résoudre. Ce nom n'apparaît qu'une seule fois dans le monde et n'existe dans aucune mémoire cache ; votre chaîne de résolution récursive doit par conséquent remonter jusqu'à notre serveur faisant autorité ; nous consignons l'entité qui émet la requête et transmettons cette adresse à la page. Ainsi, la colonne « Sortie DNS » indique l'adresse réseau de sortie réelle de votre résolveur récursif, et non l'adresse saisie dans vos paramètres système : si vous configurez 8.8.8.8, l'émetteur qui nous interrogera sera une machine spécifique de ce cluster, éventuellement située dans un autre pays ; les grands résolveurs publics utilisant l'anycast et des grappes de serveurs, l'apparition de plusieurs adresses différentes au cours d'un même test est tout à fait normale. Le véritable critère n'est pas la concordance des adresses, mais : si cette sortie appartient au réseau de votre propre fournisseur d'accès à Internet alors que votre IP de navigation transite par le proxy, cela prouve que les requêtes DNS n'ont pas suivi le tunnel.

⚠ Ce procédé permet uniquement de constater qui a interrogé notre propre serveur faisant autorité ; nous ne voyons pas et ne pouvons techniquement pas voir les autres domaines consultés. Il comporte en outre une limite connue : si votre proxy prend également en charge le DNS, nous observerons le résolveur du fournisseur de proxy — confirmant l'absence de fuite vers votre FAI local, mais vos requêtes demeurent visibles pour votre fournisseur de proxy ; c'est une question distincte que notre outil ne mesure pas.

Grâce à WebRTC, des sondes individuelles sont transmises à plusieurs serveurs STUN afin de collecter les candidats srflx renvoyés — soit l'adresse IP publique et le port observés par le serveur distant après traduction NAT. Le critère déterminant est unique : les candidats sont regroupés selon l'IP publique attribuée ; si deux ports distincts ou davantage apparaissent sous la même IP, la connexion est classée en NAT symétrique (attribution d'un nouveau port externe pour chaque nouvelle destination) ; dans le cas contraire, elle est classée en NAT à cône (association constante d'un même port interne au même port public externe). Ce regroupement préalable avant comparaison des ports est délibéré : dans un environnement de proxy à routage fractionné, différents serveurs STUN peuvent emprunter des sorties distinctes, provoquant des divergences de ports ; toutefois, cela découle de différences d'acheminement et non du comportement du NAT — sans regroupement, ces configurations seraient systématiquement qualifiées de symétriques. L'état « Inconnu » s'explique par deux causes : d'abord, l'absence de tout candidat srflx dans le délai d'attente de 4 secondes (WebRTC désactivé dans le navigateur, bloqué par des extensions ou filtrage UDP sortant) ; ensuite, la réception d'un unique candidat dont l'IP publique ne correspond pas à l'IP d'entrée sur notre site, rendant impossible la distinction entre déduplication du navigateur et routage fractionné ; nous préférons alors indiquer inconnu.

⚠ Précision transparente : nous distinguons uniquement les catégories NAT à cône et symétrique, sans sous-classification en cône intégral, restreint ou restreint aux ports. La classification à quatre états de la RFC 3489 impose de contrôler les combinaisons de ports sources et de destinations via des sondes itératives, or WebRTC dans le navigateur n'offre aucun contrôle de ce niveau ; les outils Web qui prétendent afficher l'une des quatre catégories ne font généralement que renommer ces deux observations.

Une vérification sur la page d'accueil émet en parallèle six sondes ciblant des domaines distincts : une purement IPv4, une purement IPv6, deux dédiées à la capture des empreintes de pile réseau sur IPv4 et IPv6 respectivement, une visant un domaine double pile pour identifier la famille privilégiée par votre système, et une sonde explicitement contrainte en HTTP/1.1. Il ne s'agit pas de requêtes redondantes : chaque sonde recueille des mesures fondamentalement différentes. Leur séparation est indispensable car nos diagnostics reposent sur une confrontation inter-couches : un même terminal présente des signatures de pile différentes sur IPv4 par rapport à IPv6, ainsi que sur HTTP/1.1 par rapport à HTTP/2 (et HTTP/3 lorsque disponible), qui ne peuvent être comparées qu'une fois mesurées isolément. Par ailleurs, le parallélisme ne vise pas la rapidité : des requêtes séquentielles risqueraient, lors d'un basculement de réseau, de proxy ou d'une reconnexion de tunnel, d'associer des données appartenant à une machine hybride inexistante ; l'exécution simultanée garantit que les six sondes observent la même liaison au même instant. Parmi elles, la sonde HTTP/1.1 n'émet volontairement qu'une seule requête — HTTP/1.1 ne possédant pas de table dynamique HPACK, des requêtes supplémentaires n'apporteraient aucune entropie additionnelle, tandis qu'un appel unique garantit que les en-têtes correspondent strictement au même enregistrement.

⚠ En contrepartie, le chargement initial sollicite plusieurs sous-domaines, ce que certains bloqueurs de publicités ou extensions de confidentialité strictes bloquent occasionnellement. Le champ concerné reste alors surmonté d'un voyant gris à l'état inconnu ; nous ne substituerons jamais les résultats d'autres sondes pour fabriquer une valeur d'apparence complète.