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.
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.
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

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.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
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
- Cloudflare
1.1.1.1192.0.2.10son propre réseau, AS13335pays du registre : États-UnisPas une fuite
- Google
8.8.8.8192.0.2.12,192.0.2.13son propre réseau, AS15169pays du registre : États-Unisdeux adresses pour deux recherchesPas une fuite
- Quad9
9.9.9.9192.0.2.11via Equinix, AS15830pays du registre : Pays-Basle réseau d'un partenairePas une fuite
- AdGuard
94.140.14.14192.0.2.30via Datacamp (CDN77), AS60068un hébergeur partenaire (porte aussi DNS4EU)Pas une fuite - NextDNSvotre configuration
192.0.2.41via Vultr, AS20473un hébergeur partenaire (porte aussi CleanBrowsing)Pas une fuite
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
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
Profil OpenVPN (.ovpn)
WireGuard (.conf)
Windows 11 · Settings
SettingsNetwork & internetWi-FiManage known networks
Laissez l'IPv6 activé : Microsoft déconseille de le désactiver. Utilisez la protection contre les fuites IPv6 de l'application VPN.
Group Policy
valeur de registre
Vérifier le DNS du système
macOS · System Settings
Apple menuSystem SettingsNetworkWi-FiDetailsDNS
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
Linux
~./etc/resolv.conf les lignes nameserver restantes après la connexion.Vérifier le DNS du système
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
- 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.
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
| Service | Votre réglage | Ce test devrait montrer | Arrive souvent de |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | DNS public Cloudflare | son propre réseau · AS13335 |
| Google Public DNS | 8.8.8.8 | DNS public Google | ses propres plages publiées · AS15169 +3 autres |
| Quad9 | 9.9.9.9 | DNS public Quad9 | un partenaire, comme Equinix · AS15830 |
| NextDNS | votre ID de configuration | Hébergement NextDNS probable | un hébergeur, comme Vultr · AS20473 |
| AdGuard DNS | 94.140.14.14 | Hébergement AdGuard probable | un hébergeur, comme Datacamp (CDN77) · AS60068 |
| Control D | 76.76.2.0 | DNS public Control D | un hébergeur régional · AS146943 |
| Pi-hole | l'adresse de votre Pi-hole | DNS public le serveur amont de votre Pi-hole, ou Le vôtre avec Unbound | le réseau de votre serveur amont, ou votre propre adresse |
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
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.
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.
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
- 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.
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
| VPN | Son propre DNS par défaut | Ce que ce test montre | Adresse DNS publiée |
|---|---|---|---|
| Mullvad | oui | Le serveur DNS sur le serveur Mullvad auquel vous êtes connecté | non publiée |
| Proton VPN | oui | Un serveur DNS dans le même centre de données que votre serveur VPN, à une autre adresse ; il peut appartenir à un partenaire | 10.2.0.1 |
| NordVPN | oui | Les serveurs DNS propres à NordVPN | 103.86.96.100103.86.99.100 |
| Surfshark | oui | Un serveur DNS du même emplacement ; Surfshark dit que vos adresses IP et DNS sont identiques | non publiée |
| ExpressVPN | oui | Le DNS chiffré propre à ExpressVPN, qui tourne sur chacun de ses serveurs | non publiée |
| Private Internet Access | oui | Le DNS PIA, réglage par défaut de l'application | 10.0.0.24210.0.0.243 |
| Windscribe | oui | Son propre DNS dans le même pays, généralement pas exactement votre adresse VPN | 10.255.255.x |
Test de fuite DNS : questions fréquentes
Qu'est-ce qu'une fuite DNS, et est-ce grave ?
Mon FAI peut-il voir ma navigation si le DNS fuit ?
Un VPN corrige-t-il les fuites DNS ?
Pourquoi le test affiche-t-il un serveur DNS dans un autre pays ?
Pourquoi je vois Google ou Cloudflare alors que je ne les ai pas configurés ?
Le test n'a trouvé aucun serveur DNS. Cela veut-il dire qu'il n'y a pas de fuite ?
*.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é ?
Qu'est-ce qu'une fuite IPv6, et ce test la vérifie-t-il ?
Le DNS over HTTPS empêche-t-il les fuites DNS ?
Peut-on avoir une fuite DNS sans VPN ?
Comment corriger une fuite DNS sur Android ou sur iPhone ?
À quelle fréquence faut-il tester les fuites DNS ?
Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil
Autres outils DNS et réseau
Test de Vitesse DNS
Mesurez Cloudflare 1.1.1.1, Google 8.8.8.8 et d'autres serveurs DNS publics depuis votre navigateur, face à votre DNS actuel, et trouvez le plus rapide pour vous
Test de fuite WebRTC
Vérifiez si WebRTC dans votre navigateur révèle votre véritable adresse IP derrière un VPN ou un proxy, ainsi que les IP locales qu'il expose
Quelle Est Mon IP
Votre IP publique IPv4 et IPv6 en un coup d'œil, avec le réseau, la localisation et un test VPN
Quel Est Mon FAI
Découvrez votre FAI, ASN et détails de connexion
Test IPv6
Testez votre IPv6, le choix de votre navigateur et si un site a l'IPv6
Recherche DNS
Tous les enregistrements DNS depuis les serveurs du domaine, à côté du cache de Google et Cloudflare