Fuite DNS : pourquoi « mon IP a changé » ne prouve rien

07/09/2026

Dernière mise à jour : 07/09/2026

Une fuite DNS est la panne la plus contre-intuitive du VPN : tout fonctionne, le tunnel est actif, le site que vous consultez voit bien l’adresse du serveur VPN — et votre fournisseur d’accès connaît malgré tout la liste des sites que vous visitez. Rien ne s’affiche, aucune alerte ne se déclenche. C’est pour cela qu’elle mérite une page à elle.

La fuite DNS : l’adresse change, la liste des sites consultés reste visible Avant d’atteindre un site, l’appareil demande à un résolveur de traduire le nom du site en adresse. Quand cette requête sort du tunnel, le fournisseur d’accès conserve la liste des sites consultés même si le trafic lui-même est chiffré et que l’adresse IP visible a changé. DEUX FLUX PARTENT DE VOTRE APPAREIL, PAS UN SEUL Votre appareil VPN actif 1 — LE TRAFIC Serveur VPN dans le tunnel, chiffré Le site voit l’IP du serveur c’est la partie qui fonctionne 2 — LE DNS Hors du tunnel vers le résolveur du FAI Le FAI garde la liste des sites les noms, pas le contenu POURQUOI LE TEST HABITUEL NE LE VOIT PAS « Mon adresse IP a changé » vrai, et insuffisant Le flux 2 est indépendant du flux 1 l’adresse peut changer alors que la résolution fuit toujours Les deux flux se règlent séparément. Un VPN correctement configuré fait passer la résolution dans le tunnel et utilise ses propres résolveurs ; beaucoup le font par défaut, certains seulement si l’option est activée. Le même raisonnement vaut pour l’IPv6 : si le service ne le gère pas, ce trafic sort en clair pendant que le tunnel IPv4 fonctionne.
Deux flux quittent l'appareil, pas un seul. L'adresse IP peut avoir changé alors que les requêtes de résolution partent toujours chez le fournisseur d'accès, qui garde donc la liste des sites consultés.

Deux flux quittent votre appareil, pas un

Quand vous tapez un nom de site, deux choses distinctes se produisent.

  1. La résolution du nom. Votre appareil demande à un résolveur DNS « à quelle adresse correspond ce nom ? » et reçoit une adresse en retour.
  2. La connexion elle-même. Votre appareil contacte cette adresse et échange les données.

Un VPN est censé faire passer les deux dans le tunnel. Quand il ne prend en charge que la seconde, la première continue de sortir en clair vers le résolveur habituel — celui de votre opérateur, dans la configuration par défaut d’une box française. Résultat : le contenu de vos échanges est protégé, mais la liste de ce que vous consultez ne l’est pas.

Pourquoi « mon IP a changé » ne prouve rien

C’est la vérification que tout le monde fait, et elle ne teste que la moitié du problème. Vous ouvrez une page qui affiche votre adresse, vous voyez celle du serveur VPN, vous en concluez que tout est en ordre.

Sauf que les deux flux sont indépendants. La substitution d’adresse et la résolution de noms empruntent des chemins séparés, gérés par des composants différents du système. L’un peut être parfaitement dérouté pendant que l’autre ne l’est pas du tout. Constater que votre adresse a changé prouve exactement une chose : que votre adresse a changé.

C’est aussi la raison pour laquelle un coupe-circuit ne règle pas une fuite DNS. Le coupe-circuit surveille l’état du tunnel et coupe le trafic s’il tombe. Ici le tunnel ne tombe pas : il est debout, il fonctionne, et les requêtes DNS passent simplement à côté. Il n’y a rien à détecter.

Les trois causes réelles

1. Windows interroge toutes les interfaces à la fois

Depuis Windows 8, le système utilise une fonction appelée smart multi-homed name resolution : face à plusieurs interfaces réseau — votre Wi-Fi et l’adaptateur virtuel du VPN —, il envoie la requête DNS sur toutes en parallèle et retient la première réponse arrivée. Le résolveur de votre opérateur, physiquement plus proche, gagne souvent la course.

Ce n’est pas un bug : c’est une optimisation de latence qui devient un problème de confidentialité dès qu’une interface est censée être privée. Les clients VPN sérieux neutralisent ce comportement à l’installation. C’est un des rares points où la qualité du logiciel compte davantage que le protocole employé.

2. L’IPv6 sort par la porte à côté

Beaucoup de configurations VPN ne transportent que l’IPv4. Sur une connexion française qui dispose des deux — et l’IPv6 est actif par défaut chez plusieurs opérateurs —, le système résout et se connecte en IPv6 en dehors du tunnel, avec votre véritable adresse.

Deux réponses possibles côté fournisseur : transporter réellement l’IPv6, ou le désactiver proprement pendant la connexion. Les deux sont acceptables. Ce qui ne l’est pas, c’est de l’ignorer.

3. Une couche DNS que vous avez configurée vous-même

Celle-ci est particulière, parce qu’elle vient d’un réglage souvent adopté pour de bonnes raisons.

  • Le « DNS privé » d’Android, s’il pointe vers un fournisseur précis, envoie vos requêtes à ce fournisseur en DNS-over-TLS, quel que soit l’état du VPN.
  • Le DNS sécurisé du navigateur (Firefox, Chrome) fait la même chose en DNS-over-HTTPS, pour le trafic du navigateur.

Soyons précis sur ce que cela implique, parce que la nuance est réelle. Ces requêtes sont chiffrées : votre opérateur ne peut pas les lire. Ce n’est donc pas une fuite vers le fournisseur d’accès. Mais elles ne passent pas par le résolveur du VPN : c’est le service que vous avez désigné qui voit la liste, et non plus personne. Vous avez déplacé la confiance, vous ne l’avez pas supprimée. Selon ce qui vous préoccupe, c’est un bon arrangement ou un mauvais ; ce n’est en aucun cas neutre, et un test de fuite le signalera.

Ce qu’une fuite révèle, et ce qu’elle ne révèle pas

Ce qui sort : les noms de domaine que vous avez résolus, avec l’heure. exemple.fr, pas exemple.fr/page/precise. Le chemin, le contenu, ce que vous avez écrit ou téléchargé restent dans le tunnel.

C’est peu et c’est beaucoup. Une liste de domaines horodatée dessine une journée avec une précision inconfortable : votre banque, votre employeur, un site médical, un forum. Elle ne dit pas ce que vous y avez fait.

Ce qui ne sort pas non plus : votre adresse réelle vers le site consulté. De son point de vue, vous êtes toujours le serveur VPN. La fuite est en amont, pas en aval — et c’est exactement pourquoi elle est invisible depuis une page qui affiche votre adresse.

Comment tester réellement

Un test valable ne demande pas « quelle est mon adresse » mais « quels résolveurs ont répondu ». Il doit nommer les résolveurs interrogés, et c’est cette liste que vous examinez.

  1. Notez d’abord ce que vous voyez sans VPN : normalement, un ou deux résolveurs appartenant à votre opérateur. C’est votre point de comparaison, et sauter cette étape rend le reste illisible.
  2. Activez le VPN et relancez. Les résolveurs affichés doivent appartenir au fournisseur de VPN, ou à un opérateur neutre s’il l’annonce dans sa documentation.
  3. Si le nom de votre opérateur réapparaît dans la liste, il y a fuite. Si un tout autre service apparaît, revoyez la cause n° 3 : vous avez probablement un DNS configuré ailleurs.
  4. Refaites le test avec un second outil indépendant. La plupart des fournisseurs proposent le leur, ce qui est pratique mais juge et partie : deux sources valent mieux qu’une.

Testez aussi après une bascule de réseau — Wi-Fi vers données mobiles — et après une sortie de veille. Ce sont les moments où les réglages DNS sont réappliqués, donc ceux où une configuration fragile lâche.

Ce que cela change au moment de choisir

Deux critères, et aucun ne figure sur les pages de comparaison habituelles. D’abord, le fournisseur exploite-t-il ses propres résolveurs ? S’il sous-traite à un service public, la liste de vos domaines est vue par ce tiers, et sa politique de conservation devient la vôtre — ce qui vide une partie de la promesse examinée dans VPN no-log. Ensuite, la protection contre les fuites est-elle documentée explicitement, IPv6 compris ? Un fournisseur qui nomme le problème l’a traité ; un fournisseur silencieux ne l’a pas forcément fait.

Questions fréquentes

Comment savoir si j’ai une fuite DNS ?

Avec un test qui affiche les résolveurs ayant répondu, pas votre adresse IP. Si le nom de votre fournisseur d’accès apparaît alors que le VPN est actif, la fuite est confirmée. Vérifier son adresse ne détecte rien.

Un coupe-circuit protège-t-il d’une fuite DNS ?

Non. Le coupe-circuit réagit à la chute du tunnel. Lors d’une fuite DNS le tunnel reste debout : les requêtes passent simplement à côté, et il n’y a aucune anomalie à détecter.

Le mode navigation privée empêche-t-il une fuite DNS ?

Non. Il n’agit que sur ce que votre navigateur conserve localement — historique, cookies, formulaires. Les requêtes DNS quittent l’appareil exactement de la même manière.

Faut-il désactiver le DNS privé d’Android quand j’utilise un VPN ?

Si vous voulez que le VPN gère la résolution de bout en bout, oui : repassez le réglage sur automatique. Si vous préférez conserver votre résolveur, c’est un choix défendable — sachez simplement que c’est lui, et non le fournisseur de VPN, qui voit la liste de vos domaines.

Une fuite DNS révèle-t-elle mon adresse IP au site que je visite ?

Non. Le site continue de voir l’adresse du serveur VPN. Ce qui fuit part vers un résolveur, en amont de la connexion ; le site consulté n’en sait rien. La seule exception est le cas IPv6, où c’est la connexion elle-même qui sort du tunnel.

Changer de protocole règle-t-il le problème ?

Rarement. Une fuite DNS relève de la configuration du client et du système, pas du protocole de chiffrement — voir protocoles VPN. Changer de fournisseur, ou corriger le réglage fautif, est plus efficace que passer de WireGuard à OpenVPN.

À lire aussi