DNS Leak Test

Découvrez quels serveurs DNS répondent vraiment à vos recherches et si votre VPN les laisse fuiter vers votre fournisseur d'accès. Ce test DNS se lance dès l'ouverture de la page, nomme chaque serveur et donne un verdict clair.

Vu par notre propre serveur de noms de test · serveurs DNS affichés avec leur adresse IPv4 · observations gardées 10 minutes en mémoire, puis oubliées

Que voulez-vous vérifier ?
Lancez le test une fois avec le VPN désactivé, puis une seconde fois avec le VPN activé : nous vous montrerons quels serveurs DNS ont disparu.

Démarre tout seul à l'ouverture de la page · 6 recherches que personne n'a jamais faites · environ 4 s · oublié après 10 minutes

VousIPv4IPv6Recherche de votre connexion…
Serveurs DNS qui ont interrogé notre serveur de noms
  1. Les serveurs DNS qui interrogent notre serveur de noms apparaissent ici, une ligne chacun, à mesure qu'ils arrivent.

Vérifier en ligne de commande

1Le DNS de votre système

Le serveur DNS qu'utilisent vos applications. Comparez-le aux lignes ci-dessus.

C:\> nslookup -type=txt whoami.leak.dnsrobot.net
  • La réponse est l'adresse du serveur DNS qui nous a interrogés.
  • Une réponse différente signifie que votre navigateur et vos applications prennent des chemins différents, par exemple le DNS sécurisé du navigateur.
  • Vous gérez votre propre résolveur (Pi-hole avec Unbound) ? La réponse est l'adresse de votre domicile : ne la publiez pas.

2Le test de détournement

Interroge directement Cloudflare (1.1.1.1).

C:\> nslookup -type=txt whoami.leak.dnsrobot.net 1.1.1.1
  • Une adresse Cloudflare (AS13335) : votre recherche a bien atteint Cloudflare.
  • L'adresse de n'importe quel autre réseau : un signe fort que quelque chose détourne votre DNS : votre application VPN (certaines le font exprès), un logiciel de sécurité, votre routeur ou votre fournisseur.
Quelle commande ?

Le texte reste sur cette page ; seule l'adresse est recherchée sur notre serveur pour nommer son réseau.

Notre serveur de noms garde les observations de chaque test pendant 10 minutes en mémoire, puis les oublie. Votre dernier résultat reste uniquement dans ce navigateur, pour la comparaison avant/après.

Que signifie le résultat de mon test de fuite DNS ?

Tout dépend de deux choses : quels serveurs DNS ont interrogé notre serveur de noms, et si vous êtes sur un VPN. Le DNS de votre fournisseur d'accès est normal sans VPN et constitue une fuite avec un VPN ; un DNS public comme Cloudflare ou Google n'est jamais une fuite en soi.

Une fuite DNS (DNS leak) signifie que les serveurs DNS de votre fournisseur ont répondu alors que vous étiez sur un VPN : votre fournisseur voit donc les sites que vous recherchez malgré le tunnel. Les partenaires ou hébergeurs qui font tourner le DNS de votre VPN ne sont pas une fuite : Proton VPN fait la même distinction.

Le test classe chaque serveur par type (DNS de votre VPN, DNS public, DNS de votre FAI, réseau d'hébergement ou votre propre résolveur) et rédige le verdict à partir du mélange, en nommant la marque. Le DNS de votre VPN plus celui de votre fournisseur, c'est une fuite partielle : certaines recherches s'échappent de temps en temps.

Rien n'est arrivé n'est jamais un feu vert : quelque chose a arrêté les recherches du test avant qu'elles atteignent Internet. Et un serveur DNS situé dans un autre pays n'est pas non plus une fuite.

Qui a interrogé notre serveur de noms × êtes-vous sur un VPN ?les six verdicts

Serveurs DNS vusSans VPNAvec un VPN
DNS de votre VPNImpossibleSans VPN, il n'y a pas de DNS de VPN à voir.Aucune fuiteM247 à Francfort répond : votre fournisseur ne voit rien.
DNS publicCloudflare répondVotre configuration 1.1.1.1 fonctionne. Pas de fuite.Aucune fuiteSes recherches arrivent depuis l'adresse du VPN, pas la vôtre.
DNS de votre FAIDNS de votre FAIExample Broadband répond, comme il se doit sans VPN. Pas de fuite.Fuite DNSVotre fournisseur voit chaque nom que vous recherchez, malgré le VPN.
Un mélange : VPN ou public + FAIPas de fuiteUn second réglage DNS ou un DNS de secours : normal sans VPN.Fuite partielleCertaines recherches s'échappent du tunnel : lancez le test étendu.
Un réseau d'hébergementProbablement Quad9Ou le partenaire d'un autre service, ou le serveur amont de votre routeur : la page le dit quand elle ne peut pas trancher.Aucune fuitePas le réseau de votre fournisseur : probablement le partenaire DNS de votre VPN.
Rien n'est arrivéPas de feu vertJamais « sûr » : quelque chose a arrêté les recherches du test.Pas de feu vertAutorisez les noms du test, ou lancez le test étendu.
Les lignes sont les types de serveurs DNS que le test nomme, dans leurs couleurs des résultats ; les cases sont les verdicts que la page écrit. La règle avec un VPN : tout ce qui n'est pas le réseau de votre fournisseur n'est pas une fuite.
Résultat du test de fuite DNS : les recherches d'un utilisateur de VPN traitées par le DNS de son FAI, chaque serveur nomméRésultat du test de fuite DNS : les recherches d'un utilisateur de VPN traitées par le DNS de son FAI, chaque serveur nomméLe verdictUne phrase qui nomme qui répond à vos recherches et s'il s'agit d'une fuite, avec la marche à suivre.Un serveur DNSChaque serveur qui a interrogé notre serveur de noms : sa marque ou son réseau, son adresse IPv4, sa localisation, son type et sa part des requêtes.Également vérifiéPar où sort votre adresse IPv6, et une remarque quand iCloud Private Relay ou Tor transporte votre trafic.Votre chemin DNSVotre appareil, le tunnel VPN et les serveurs DNS qui ont demandé, une fuite étant dessinée comme une recherche hors du tunnel.
Un résultat fictif sur un VPN : le DNS d'Example Broadband répond toujours hors du tunnel, le test signale donc une fuite. Sélectionnez un numéro pour voir ce que montre chaque partie.

Comment fonctionne un test de fuite DNS ?

Ce vérificateur de fuite DNS fait rechercher à votre navigateur des noms qui n'ont jamais existé, comme 1-k3x9q2mfp7c1vn4a.leak.dnsrobot.net. Aucun serveur DNS ne les a en cache : le serveur qui traite vos recherches doit donc interroger notre serveur de noms, qui note son adresse et répond « ce nom n'existe pas ».

La page demande ensuite à notre serveur de noms quels serveurs DNS sont venus demander les noms de ce test. Ce sont les serveurs que votre navigateur utilise vraiment, quels que soient vos réglages ; un routeur domestique se contente en général de transmettre les recherches, et c'est donc le serveur vers lequel il les transmet qui apparaît. Chaque nom ne sert qu'une fois, et notre serveur de noms oublie le test au bout de 10 minutes.

Le test standard fait 6 recherches, ce qui suffit en général pour repérer une fuite. Le test étendu en fait 36, par lots de 6, pour attraper un serveur DNS qui ne répond que de temps en temps, par exemple quand Windows essaie toutes les cartes réseau parce que le DNS du VPN tarde à répondre.

Si un serveur DNS transmet une partie de votre adresse (EDNS Client Subnet), sa ligne vous montre ce sous-réseau, à vous seul. Il n'est jamais journalisé.

Une recherche, suivie pas à pasun test réel, adresses remplacées

Votre navigateurVotre serveur DNSNotre serveur de noms1-k3x9q2….leak.dnsrobot.net ?qui a 1-k3x9q2… ?demandé par203.0.113.53NXDOMAIN · nom inexistantl'image échoue : recherche faitequels serveurs ont demandé k3x9q2… ?→ 203.0.113.53 ×4 · 203.0.113.54 ×2Votre navigateurVotre serveur DNSNotre serveur de noms1-k3x9q2….leak.dnsrobot.net ?qui a 1-k3x9q2… ?demandé par203.0.113.53NXDOMAIN · nom inexistantl'image échoue : recherche faitequels serveurs ont demandé k3x9q2… ?→ 203.0.113.53 ×4203.0.113.54 ×2
En haut : l'une des six recherches depuis une connexion domestique, étape par étape. Chaque nom ne sert qu'une fois, et notre serveur de noms garde qui l'a demandé pendant 10 minutes, en mémoire. En bas : les deux formats de test, une case par recherche ; chaque lot de 6 attend au plus 3 secondes. Les couleurs illustrent un VPN qui envoie 2 recherches sur 36 au DNS du fournisseur, ce qu'un test de 6 recherches peut facilement manquer. Le test lui-même montre la part des requêtes de chaque serveur DNS.

Pourquoi Google, Cloudflare ou un autre pays apparaissent-ils ?

Parce que l'adresse que vous configurez n'est pas l'adresse qui interroge. Les services DNS publics répondent sur 1.1.1.1 ou 8.8.8.8 depuis de nombreux sites à la fois (anycast), et chaque site interroge les autres serveurs de noms depuis son propre ensemble d'adresses, parfois sur le réseau d'un partenaire.

Depuis une connexion que nous avons testée, seuls Cloudflare, Google et OpenDNS ont atteint notre serveur de noms depuis leurs propres réseaux ; Quad9 est passé par Equinix, AdGuard par Datacamp et NextDNS par Vultr. Rien de tout cela n'est une fuite. Un DNS public dans votre résultat signifie que votre navigateur, votre appareil ou votre VPN y envoie les recherches, et depuis un VPN, elles arrivent depuis l'adresse du VPN, pas la vôtre.

Le test ne se fie donc pas à un tableau : il demande à chaque service DNS public, depuis votre navigateur, quelle adresse il utilise pour vous, et vérifie Google grâce aux plages que Google publie. Un serveur qu'il ne peut pas confirmer est affiché comme probable pour ce service, ou comme un serveur sur un réseau d'hébergement, jamais comme une fuite.

Les pays aussi sont trompeurs : les données des registres indiquent le pays où un réseau est enregistré, pas celui où se trouve le serveur (1.1.1.1 lui-même est enregistré en Australie). Une fuite, c'est une question de qui voit vos recherches, pas de l'endroit où elles se trouvent.

Votre réglage · qui nous a interrogés · son réseauun test enregistré, adresses remplacées

Enregistré sur une ligne fibre (Inde), 24 oct. 2026

  • Cloudflare1.1.1.1192.0.2.10son propre réseau, AS13335pays du registre : États-UnisPas une fuite
  • Google8.8.8.8192.0.2.12, 192.0.2.13son propre réseau, AS15169pays du registre : États-Unisdeux adresses pour deux recherchesPas une fuite
  • Quad99.9.9.9192.0.2.11via Equinix, AS15830pays du registre : Pays-Basle réseau d'un partenairePas une fuite
  • AdGuard94.140.14.14192.0.2.30via Datacamp (CDN77), AS60068un hébergeur partenaire (porte aussi DNS4EU)Pas une fuite
  • NextDNSvotre configuration192.0.2.41via Vultr, AS20473un hébergeur partenaire (porte aussi CleanBrowsing)Pas une fuite
Sur les 12 services DNS publics interrogés depuis cette connexion, seuls Cloudflare, Google et OpenDNS ont atteint notre serveur de noms depuis leurs propres réseaux ; les autres sont passés par des partenaires ou des hébergeurs. Le drapeau indique où un réseau est enregistré, pas où se trouve le serveur. La page demande en direct à chaque service quelle adresse il utilise pour vous, au lieu de se fier à un tableau comme celui-ci.

Quelles sont les causes d'une fuite DNS ?

En général, votre appareil envoie des recherches ailleurs qu'au VPN : l'application VPN ne définit pas son propre DNS, Windows interroge toutes les cartes réseau, ou l'IPv6 contourne un tunnel qui ne transporte que l'IPv4.

Windows peut envoyer chaque recherche à la fois sur le Wi-Fi et sur le VPN pour répondre plus vite (smart multi-homed name resolution). Beaucoup de VPN ne transportent que l'IPv4 et laissent le trafic IPv6, ainsi que le DNS envoyé par ce biais, hors du tunnel (RFC 7359). Un DNS personnalisé réglé sur le système peut aussi passer outre la protection de l'application VPN.

Chaque cause laisse sa propre trace dans le résultat. Un fournisseur de DNS sécurisé personnalisé dans le navigateur apparaît comme ce DNS public, en contournant celui du VPN. Le mode automatique de Chrome garde toutefois votre fournisseur actuel, et le réglage par défaut de Firefox s'efface devant un VPN.

Quelque chose qui détourne le DNS sur le port 53, comme un proxy transparent du fournisseur, fait apparaître votre fournisseur même si vous avez configuré 1.1.1.1. Un VPN qui décroche sans kill switch ne fuit qu'un instant, et un seul test peut donc le manquer : refaites le test une fois le VPN reconnecté.

Six causes, et ce que ce test montre pour chacunela dernière ligne de la carte

  • Le VPN ne définit pas son propre DNS

    Le trafic passe par le tunnel, mais le système garde les serveurs DNS qu'il avait avant, généralement ceux de votre fournisseur.

    Fuite DNSle DNS de votre FAI sur un VPN

  • Un DNS sécurisé personnalisé dans le navigateur

    Réglé sur un fournisseur personnalisé, le navigateur lui envoie les recherches en HTTPS, en contournant le DNS du VPN. Le mode automatique de Chrome garde votre fournisseur actuel, et le réglage par défaut de Firefox s'efface quand il détecte un VPN.

    Aucune fuiteun DNS public, pas celui de votre VPN

  • Windows interroge toutes les cartes réseau

    Avec « smart multi-homed name resolution », Windows envoie les recherches sur tous les réseaux à la fois : le VPN comme le Wi-Fi.

    Fuite partielleDNS de votre VPN + DNS de votre FAI

  • L'IPv6 contourne le tunnel

    Beaucoup de VPN ne transportent que l'IPv4. Le trafic IPv6, et tout DNS envoyé par ce biais, sort par votre fournisseur.

    Fuite IPv6sa propre ligne sous le résultat

  • Quelque chose détourne le DNS

    Un routeur, un logiciel de sécurité ou le fournisseur (ou une application VPN, volontairement) intercepte les recherches sur le port 53 et y répond, même celles destinées à 1.1.1.1.

    DNS de votre FAI« Pas Cloudflare 1.1.1.1 : votre FAI a répondu »

  • Le VPN décroche, sans kill switch

    Si le tunnel est interrompu, les recherches peuvent partir vers le DNS par défaut du système, probablement celui de votre fournisseur, jusqu'à son rétablissement.

    Fuite partielleseulement de temps en temps : le test étendu l'attrape plus souvent

Teredo, l'ancienne méthode de Windows pour faire passer l'IPv6 dans l'IPv4, est désactivé depuis Windows 10 version 1803 : c'est donc rarement une cause aujourd'hui.

Comment corriger une fuite DNS ?

Activez dans votre application VPN DNS leak protection, IPv6 leak protection et le kill switch (les noms varient selon l'application), puis refaites le test. La protection contre les fuites garde le DNS dans le VPN grâce à des règles de pare-feu ; le kill switch couvre les moments où le tunnel tombe.

Si la fuite persiste, corrigez le système. Sous Windows, block-outside-dns dans un profil OpenVPN tient les recherches à l'écart de toutes les autres cartes réseau, et un tunnel WireGuard qui fait tout passer (0.0.0.0/0) avec une ligne DNS = ne laisse le port 53 atteindre que le DNS du tunnel. Désactiver « smart multi-homed name resolution » arrête seulement les recherches parallèles ; ce n'est pas la solution.

Sous Linux avec systemd-resolved, donnez au lien VPN le domaine de routage ~. pour qu'aucun autre lien ne soit interrogé. Laissez l'application VPN transporter ou bloquer l'IPv6 plutôt que de désactiver l'IPv6, ce que Microsoft déconseille. Retirez du navigateur tout fournisseur de DNS sécurisé personnalisé, et du système tout DNS personnalisé, pendant que vous utilisez le VPN.

Sur Android, réglez « DNS privé » sur Désactivé pendant que le VPN est actif, comme le conseillent Proton VPN et Mullvad : un nom d'hôte de DNS privé envoie chaque recherche à ce fournisseur. Relancez ensuite le test : l'avant/après montre quels serveurs DNS ont disparu.

Les réglages qui comptentpar système

Application VPN · Paramètres

DNS leak protectiongarde chaque recherche dans le tunnel
IPv6 leak protectionbloque l'IPv6 ou le fait passer dans le tunnel
Kill Switchaucun trafic tant que le tunnel est coupé
Custom DNSà laisser désactivé : dans certaines applications, il coupe la protection contre les fuites

Profil OpenVPN (.ovpn)

block-outside-dns
# Windows uniquement : le port 53 n'atteint aucune autre carte réseau

WireGuard (.conf)

[Interface]
DNS = 10.2.0.1
# sans cette ligne, le système garde son ancien DNS
[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
# WireGuard pour Windows : avec une route /0, le port 53 n'atteint que le DNS ci-dessus

Windows 11 · Settings

SettingsNetwork & internetWi-FiManage known networks

DNS server assignmentsur un VPN, un DNS saisi à la main peut passer outre sa protection contre les fuitesAutomatic (DHCP)

Laissez l'IPv6 activé : Microsoft déconseille de le désactiver. Utilisez la protection contre les fuites IPv6 de l'application VPN.

Group Policy

Computer Configuration › Network › DNS Client
Turn off smart multi-homed name resolution = Enabled
# arrête seulement les recherches parallèles : ce n'est pas la solution

valeur de registre

DisableSmartNameResolution

Vérifier le DNS du système

C:\> nslookup -type=txt whoami.leak.dnsrobot.net

macOS · System Settings

Apple menuSystem SettingsNetworkWi-FiDetailsDNS

DNS Serversretirez les serveurs ajoutés à la main pendant que vous utilisez un VPN

Un profil ou une application de DNS chiffré que vous avez activé s'applique à tout le système, et une application VPN ne peut pas le rediriger.

Avec un VPN activé, iCloud Private Relay s'efface.

Vérifier le DNS du système

$ dns-sd -q whoami.leak.dnsrobot.net TXT
# tourne jusqu'à ce que vous appuyiez sur Ctrl-C
$ dig +short TXT whoami.leak.dnsrobot.net
# dig n'interroge que le résolveur principal, celui de /etc/resolv.conf

Linux

systemd-resolvedUne recherche qui ne correspond à aucun domaine de routage part vers chaque lien ayant la route par défaut : le VPN comme le Wi-Fi.la solution : donnez au lien VPN le domaine de routage ~.
NetworkManagerUne priorité DNS négative sur le profil VPN écarte les serveurs DNS des autres connexions.
/etc/resolv.confSans systemd-resolved : supprimez de /etc/resolv.conf les lignes nameserver restantes après la connexion.
# envoyer chaque recherche au lien VPN
$ resolvectl domain wg0 '~.'
# NetworkManager : uniquement le DNS du profil VPN
$ nmcli connection modify my-vpn ipv4.dns-priority -10

Vérifier le DNS du système

$ resolvectl query --type=TXT whoami.leak.dnsrobot.net

Android · Settings

SettingsNetwork & internetPrivate DNS

Samsung: SettingsConnectionsMore connection settingsPrivate DNS

  • Off
  • Automatic
  • Private DNS provider hostname
  • Les éditeurs de VPN conseillent de choisir « Désactivé » pendant que vous utilisez le VPN.
  • Un nom d'hôte envoie chaque recherche à ce fournisseur, en contournant le DNS du VPN.

iPhone · Settings

SettingsWi-FiⓘConfigure DNS

  • Automatic
  • Manual

Un DNS saisi à la main ne s'applique qu'à ce réseau Wi-Fi, et peut passer outre celui du VPN.

  • Un profil ou une application de DNS chiffré que vous avez activé s'applique à tout le système, et une application VPN ne peut pas le rediriger.
  • Avec un VPN activé, iCloud Private Relay s'efface.

Chrome · Settings

SettingsPrivacy and securitySecurityAdvanced

Use secure DNS
  • your current service provider
  • a custom service provider

Edge : les mêmes choix, sousSettingsPrivacy, search, and services

  • Le mode automatique ne fait que passer votre fournisseur actuel au DNS chiffré.
  • Un fournisseur personnalisé envoie les recherches en contournant le VPN, là où l'application VPN ne peut pas les rediriger.
  • Les éditeurs de VPN vont plus loin et conseillent de le désactiver.

Firefox · Settings

DNS over HTTPS

  • Default Protection
  • Increased Protection
  • Max Protection
  • Off
  • « Default Protection » désactive le DNS over HTTPS quand il détecte un VPN.
  • « Increased » et « Max » gardent le fournisseur que vous avez choisi, en contournant le DNS du VPN.
  • Activé par défaut uniquement dans ces pays : États-Unis, Canada, Russie et Ukraine.
Les noms des réglages varient selon l'application : ce sont des libellés génériques. Les noms de menu sont les libellés anglais des éditeurs. 10.2.0.1 est le DNS de Proton VPN dans le tunnel, à titre d'exemple ; l'option d'OpenVPN ne fonctionne que sous Windows.

Votre DNS personnalisé fonctionne-t-il ? Testez 1.1.1.1, NextDNS, AdGuard ou Pi-hole

Choisissez ce que vous avez configuré sous Que voulez-vous vérifier ? et lancez le test : le verdict indique si ce service répond vraiment. Une configuration qui fonctionne ne montre que ce service, souvent depuis le réseau d'un partenaire ou d'un hébergeur plutôt que le sien, comme le montre le tableau. Une fois que cela fonctionne, le Test de vitesse DNS le chronomètre face à d'autres résolveurs depuis votre connexion.

Un Pi-hole transmet les recherches à son DNS amont : le test montre donc ce serveur amont (Cloudflare, par exemple), pas le Pi-hole. Avec Unbound, il recherche les noms lui-même, et c'est l'adresse de votre domicile qui apparaît : normal sans VPN. Cloudflare et NextDNS confirment aussi leurs propres services, sur la page de vérification de Cloudflare et sur test.nextdns.io.

Si c'est votre fournisseur qui apparaît, un routeur, une application ou le navigateur remplace votre choix, ou quelque chose détourne le port 53 ; certains routeurs acheminent même mal 1.1.1.1. La vérification en ligne de commande permet de savoir lequel.

Ce que chaque service devrait montrerl'exemple d'une connexion

ServiceVotre réglageCe test devrait montrerArrive souvent de
Cloudflare1.1.1.1DNS public Cloudflareson propre réseau · AS13335
Google Public DNS8.8.8.8DNS public Googleses propres plages publiées · AS15169 +3 autres
Quad99.9.9.9DNS public Quad9un partenaire, comme Equinix · AS15830
NextDNSvotre ID de configurationHébergement NextDNS probableun hébergeur, comme Vultr · AS20473
AdGuard DNS94.140.14.14Hébergement AdGuard probableun hébergeur, comme Datacamp (CDN77) · AS60068
Control D76.76.2.0DNS public Control Dun hébergeur régional · AS146943
Pi-holel'adresse de votre Pi-holeDNS public le serveur amont de votre Pi-hole, ou Le vôtre avec Unboundle réseau de votre serveur amont, ou votre propre adresse
« Arrive souvent de » est l'exemple d'une seule connexion (vérification des faits, 24 oct. 2026) ; chez vous, cela peut différer. La page ne s'y fie pas : elle demande à chaque service, en DNS over HTTPS, quelle adresse il utilise pour vous, et indique « probable » quand un service ne peut pas être interrogé.

Comment détecter une fuite DNS en ligne de commande ?

Lancez nslookup -type=txt whoami.leak.dnsrobot.net : notre serveur de noms répond avec l'adresse du serveur DNS qui l'a interrogé, celui de votre système par défaut. Sur Mac, utilisez dns-sd -q whoami.leak.dnsrobot.net TXT (arrêtez-le avec Ctrl-C), car dig n'y voit que le réglage DNS principal ; sous Linux, resolvectl query --type=TXT whoami.leak.dnsrobot.net. Le panneau de commandes copie chacune d'elles.

Ce test voit le DNS qu'utilise votre navigateur, et les applications peuvent prendre un autre chemin : un fournisseur de DNS sécurisé personnalisé dans Chrome ou Firefox reçoit les recherches du navigateur à la place du DNS du système. Si le navigateur et la commande ne sont pas d'accord, la fuite ne concerne que l'un des deux.

Ajoutez 1.1.1.1 à la fin pour interroger directement Cloudflare (dig @1.1.1.1 TXT whoami.leak.dnsrobot.net +short sur Mac ou Linux). La réponse doit être une adresse du réseau de Cloudflare. L'adresse de n'importe quel autre réseau est un signe fort que quelque chose répond aux requêtes DNS destinées à 1.1.1.1 : votre application VPN (certaines le font exprès), un logiciel de sécurité, votre routeur ou votre fournisseur.

Si vous gérez votre propre résolveur, comme Pi-hole avec Unbound, la réponse est l'adresse de votre domicile : pensez-y avant de la coller où que ce soit.

Deux vérifications depuis un terminalnslookup sous Windows, forme réelle de la sortie

1 · le DNS de votre système

C:\> nslookup -type=txt whoami.leak.dnsrobot.net
Server:  cache2.broadband.example
Address:  203.0.113.53

Non-authoritative answer:
whoami.leak.dnsrobot.net        text =

        "203.0.113.53"

Le DNS Example Broadband : le même serveur que dans le test du navigateur, donc ici le navigateur et le système prennent le même chemin.

Vous gérez votre propre résolveur (Pi-hole avec Unbound) ? La réponse est alors votre propre adresse publique.

2 · le test de détournement

C:\> nslookup -type=txt whoami.leak.dnsrobot.net 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
whoami.leak.dnsrobot.net        text =

        "192.0.2.10"

Une adresse Cloudflare (AS13335) : votre recherche a atteint Cloudflare, comme demandé. Cela seul ne prouve pas que rien ne s'interpose : un proxy peut transmettre les recherches à 1.1.1.1.

Si la réponse avait été "203.0.113.53" : un signe fort que quelque chose détourne votre DNS : votre application VPN (certaines le font exprès), un logiciel de sécurité, votre routeur ou votre fournisseur.

La forme de la sortie réelle de nslookup sous Windows face à notre serveur de noms, avec des adresses de documentation. Le panneau de l'outil copie ces commandes pour Windows, macOS et Linux, ainsi que PowerShell.

Fuite DNS, fuite IPv6 et fuite WebRTC : quelle différence ?

Ce sont trois chemins différents qui contournent un VPN. Une fuite DNS montre à votre fournisseur les noms que vous recherchez ; une fuite IPv6 fait sortir le trafic IPv6 avec votre vraie adresse ; une fuite WebRTC permet à un site de lire votre adresse via la fonction d'appel en temps réel du navigateur. Un test de fuite VPN complet, ou test de fuite IP, examine les trois.

Cette page vérifie les deux premières en un seul test : les serveurs DNS qui interrogent, et par où sort votre adresse IPv6, sur sa propre ligne sous le résultat. WebRTC ne touche jamais au DNS, il a donc son propre Test de fuite WebRTC ; les adresses que voient les sites sont sur Quelle est mon IP, et le Test IPv6 indique si vous pouvez joindre les sites IPv6.

Il sert aussi de test de fuite DNS IPv6, avec une limite : notre serveur de noms n'est joignable qu'en IPv4, donc chaque serveur DNS est affiché avec son adresse IPv4. Une recherche que votre appareil envoie en IPv6 est tout de même détectée, car le serveur DNS qu'elle atteint doit nous interroger en IPv4 ; un rare serveur DNS uniquement IPv6 ne peut pas nous joindre et apparaît comme Rien n'est arrivé.

Trois chemins qui contournent un VPNune connexion, trois vérifications

TUNNEL VPN · M247Recherches DNSWebRTCTrafic IPv6les noms que vous visitezles adresses qu'il proposevotre propre adressehors du tunnel : ce VPN ne transporte que l'IPv4DNS de votre VPN198.51.100.53 · M247non vérifié par ce testExample Broadband · IPv62001:db8:4a1f:7c00::1cTUNNEL VPN · M247Recherches DNSWebRTCTrafic IPv6les noms que vous visitezles adresses qu'il proposevotre propre adressehors du tunnel : ce VPN ne transporte que l'IPv4DNS de votre VPN198.51.100.53 · M247non vérifié par ce testExample Broadband · IPv62001:db8:4a1f:7c00::1c
  • Fuite DNSLes serveurs DNS qui ont demandé : les lignes de ce test.
  • Fuite WebRTCLes adresses que votre navigateur peut partager avec les sites : le Test de fuite WebRTC les vérifie.
  • Fuite IPv6Par où sort votre trafic IPv6 : sa propre ligne sous le résultat de ce test.
L'exemple de fuite IPv6 de l'outil : le DNS passe par le tunnel jusqu'au DNS du VPN, il n'y a donc pas de fuite DNS, tandis que l'IPv6 sort par Example Broadband parce que ce VPN ne transporte que l'IPv4. WebRTC a besoin de son propre test.

Que doit montrer un VPN lors d'un test de fuite DNS ?

Uniquement le DNS propre au VPN : un serveur sur le réseau du VPN ou de son partenaire, généralement près du serveur auquel vous êtes connecté. Le nom de votre fournisseur d'accès ne devrait jamais apparaître tant que le VPN est actif ; Quel est mon FAI montre quel réseau les sites voient à la place.

Les éditeurs le décrivent différemment. Surfshark indique qu'un test de fuite DNS Surfshark doit montrer un seul serveur DNS avec la même adresse que votre VPN ; Proton VPN et Windscribe disent que l'adresse diffère mais se trouve au même endroit. Mullvad utilise le serveur DNS du serveur VPN auquel vous êtes connecté, ExpressVPN fait tourner son propre DNS chiffré sur chaque serveur, et NordVPN publie ses deux adresses DNS.

Un test de fuite DNS pour ExpressVPN, Mullvad ou NordVPN, comme tout test de fuite DNS de VPN, est donc réussi quand aucun serveur DNS ne se trouve dans le réseau de votre fournisseur, quelle que soit l'adresse : ce test ne compare jamais les adresses. La règle de Mullvad est plus stricte : chez Mullvad, tout serveur DNS qui n'est pas le sien compte comme une fuite.

Un DNS personnalisé dans l'application VPN change la donne : l'option « Use Existing DNS » de PIA et l'option de DNS personnalisé de Mullvad envoient les recherches en contournant le DNS propre au VPN, et c'est alors ce serveur qui apparaît. Le tableau reprend ce que disent les pages d'aide de chaque VPN ; ce n'est ni un classement ni une recommandation.

Ce que sept VPN disent que vous devriez voird'après leurs propres pages d'aide

VPNSon propre DNS par défautCe que ce test montreAdresse DNS publiée
MullvadouiLe serveur DNS sur le serveur Mullvad auquel vous êtes connecténon publiée
Proton VPNouiUn serveur DNS dans le même centre de données que votre serveur VPN, à une autre adresse ; il peut appartenir à un partenaire10.2.0.1
NordVPNouiLes serveurs DNS propres à NordVPN103.86.96.100103.86.99.100
SurfsharkouiUn serveur DNS du même emplacement ; Surfshark dit que vos adresses IP et DNS sont identiquesnon publiée
ExpressVPNouiLe DNS chiffré propre à ExpressVPN, qui tourne sur chacun de ses serveursnon publiée
Private Internet AccessouiLe DNS PIA, réglage par défaut de l'application10.0.0.24210.0.0.243
WindscribeouiSon propre DNS dans le même pays, généralement pas exactement votre adresse VPN10.255.255.x
D'après les pages d'aide de chaque VPN, consultées le 24 oct. 2026. Leurs règles diffèrent (Surfshark : la même adresse ; Proton et Windscribe : une adresse différente au même endroit), donc le test ne compare jamais les adresses : si aucun serveur DNS n'est dans le réseau de votre fournisseur, il n'y a pas de fuite.

Test de fuite DNS : questions fréquentes

Qu'est-ce qu'une fuite DNS, et est-ce grave ?

Une fuite DNS, c'est quand les serveurs DNS de votre fournisseur d'accès répondent à vos recherches alors que vous êtes sur un VPN. C'est important si vous comptez sur le VPN pour votre vie privée : votre fournisseur peut alors voir le nom de chaque site que vous recherchez, même si votre trafic passe par le tunnel. Sans VPN, le DNS de votre fournisseur est le chemin normal, pas une fuite. Le test vous dit dans quel cas vous êtes.

Mon FAI peut-il voir ma navigation si le DNS fuit ?

Il peut voir le nom des sites que vous recherchez, comme example.com, et à quel moment. Il ne peut pas voir les pages ni ce que vous tapez, car HTTPS les chiffre. Avec un VPN qui fonctionne, il ne voit que le tunnel. Avec une fuite DNS, il voit de nouveau les noms : le DNS classique n'est pas chiffré, même quand le site lui-même utilise HTTPS (RFC 9076).

Un VPN corrige-t-il les fuites DNS ?

Une bonne application VPN les empêche en envoyant chaque recherche à son propre DNS dans le tunnel, tant que sa protection contre les fuites DNS est activée et que rien sur votre appareil ne passe outre. Les cartes réseau de Windows, l'IPv6, un fournisseur de DNS sécurisé personnalisé dans le navigateur et le DNS privé d'Android peuvent quand même envoyer des recherches ailleurs. Lancez le test après vous être connecté pour vérifier.

Pourquoi le test affiche-t-il un serveur DNS dans un autre pays ?

Les services DNS répondent depuis le plus proche de leurs nombreux sites, et ce site peut interroger les autres serveurs de noms depuis une adresse enregistrée ailleurs ou depuis le réseau d'un partenaire. Le DNS d'un VPN peut aussi se trouver dans un centre de données voisin. Un autre pays n'est jamais une fuite en soi : ce qui compte, c'est à qui appartient le serveur, ce que vous indique l'étiquette de chaque ligne.

Pourquoi je vois Google ou Cloudflare alors que je ne les ai pas configurés ?

Quelque chose sur votre appareil ou votre réseau y envoie les recherches : un DNS sécurisé personnalisé dans le navigateur, les réglages du routeur, votre application VPN ou une application DNS. Si le DNS de votre système est 1.1.1.1 ou 8.8.8.8, Chrome peut continuer à utiliser ce service en HTTPS, en contournant un VPN qui n'intercepte que le port 53. Rien de cela n'est une fuite en soi : depuis un VPN, ces recherches arrivent avec l'adresse du VPN, pas la vôtre.

Le test n'a trouvé aucun serveur DNS. Cela veut-il dire qu'il n'y a pas de fuite ?

Non. « Rien n'est arrivé » signifie qu'aucun serveur DNS n'a interrogé notre serveur de noms, en général parce qu'un bloqueur de publicités, une liste Pi-hole, un DNS filtrant ou un blocage réseau a arrêté les noms du test : le test ne peut donc pas voir votre DNS du tout. Autorisez *.leak.dnsrobot.net et relancez le test, ou essayez le test étendu. Un résultat vide n'est jamais considéré comme un feu vert.

Ce test DNS est-il privé ?

Le test recherche des noms aléatoires sous notre domaine ; notre serveur de noms garde 10 minutes en mémoire les serveurs DNS qui ont demandé, puis les oublie. Pour lire votre autre adresse et nommer les DNS publics, votre navigateur pose aussi une ou deux questions à ipify et à quelques services DNS, qui voient donc votre adresse IP. Un sous-réseau transmis à votre sujet n'est montré qu'à vous. Votre dernier résultat reste dans votre navigateur ; vous pouvez l'effacer.

Qu'est-ce qu'une fuite IPv6, et ce test la vérifie-t-il ?

Une fuite IPv6, c'est quand votre VPN transporte le trafic IPv4 mais que votre trafic IPv6 sort par votre fournisseur, avec votre vraie adresse IPv6. Ce test vérifie dans le même passage par où sort votre adresse IPv6 et l'affiche sur sa propre ligne. La solution est la protection contre les fuites IPv6 de l'application VPN, ou un VPN qui transporte l'IPv6 ; Microsoft déconseille de désactiver l'IPv6.

Le DNS over HTTPS empêche-t-il les fuites DNS ?

Il cache vos recherches à votre réseau, pas à l'entreprise DNS à qui vous les envoyez : un service DoH comme Cloudflare ou NextDNS n'est donc pas une fuite vers votre fournisseur. Un fournisseur DoH personnalisé dans le navigateur contourne en revanche le DNS de votre VPN. Le mode automatique de Chrome garde votre fournisseur actuel, et Firefox n'active le DoH par défaut qu'aux États-Unis, au Canada, en Russie et en Ukraine, et s'efface devant un VPN.

Peut-on avoir une fuite DNS sans VPN ?

Pas au sens habituel : sans VPN, le DNS de votre fournisseur est le chemin normal. Ce qui peut arriver, c'est qu'un DNS que vous avez choisi, comme 1.1.1.1, ne soit pas celui qui répond, parce que votre routeur, une application ou votre fournisseur le remplace ou détourne le port 53. Choisissez ce service sous « Que voulez-vous vérifier ? » et le verdict dira s'il répond vraiment.

Comment corriger une fuite DNS sur Android ou sur iPhone ?

Sur Android, réglez « DNS privé » sur « Désactivé » pendant que vous utilisez un VPN : un nom d'hôte saisi là envoie chaque recherche à ce fournisseur au lieu du VPN. Sur iPhone, un profil ou une application de DNS chiffré, une fois activé, vaut pour tout le système : supprimez ceux qui ne servent plus. Avec iCloud Private Relay, les partenaires relais d'Apple font les recherches de Safari, et ce sont leurs serveurs qui apparaissent ; un VPN a la priorité sur Private Relay.

À quelle fréquence faut-il tester les fuites DNS ?

Après avoir installé ou mis à jour une application VPN, après avoir modifié vos réglages DNS, et chaque fois que vous changez de réseau, par exemple du Wi-Fi de la maison à celui d'un café ou aux données mobiles. Chaque réseau distribue son propre DNS, et un VPN qui décroche peut y revenir un instant. La page garde votre dernier résultat dans votre navigateur : chaque nouveau test montre donc quels serveurs DNS ont changé.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil