Test de fuite WebRTC
Exécution du test de fuite...
IPv4 (HTTP) Vérification...
IPv6 (HTTP) Vérification...
Candidats ICE recueillis
Aucun candidat ICE n'a été recueilli.
Emplacement approximatif
Localisation de votre réseau…

Le marqueur indique le centre approximatif de la zone desservie par votre opérateur , pas votre domicile, votre rue ni votre appareil. Un écart de plusieurs dizaines de kilomètres est normal.

Comment arrêter une fuite WebRTC
Chrome / Edge — installez une extension bloquant WebRTC (par exemple « WebRTC Leak Prevent »), ou utilisez un client VPN qui bloque explicitement le trafic WebRTC — Chrome n'intègre plus de réglage dédié.
Firefox — ouvrez about:config, cherchez media.peerconnection.enabled et passez-le à false pour désactiver entièrement WebRTC.
Safari — WebRTC ne peut pas être désactivé globalement ; retirez l'accès caméra/micro site par site dans Safari > Réglages > Sites web, ou reposez-vous sur un VPN qui bloque WebRTC au niveau réseau.
Brave — ouvrez le panneau Shields et réglez le limiteur réseau WebRTC sur son mode le plus strict (« Proxied ») pour éviter les fuites d'IP locale.
À propos du test de fuite WebRTC

WebRTC est une technologie de navigateur conçue pour les appels vidéo en temps réel et le transfert de fichiers pair-à-pair. Pour relier deux ordinateurs directement, il doit découvrir toutes les adresses réseau par lesquelles chaque côté est joignable : il demande donc à un serveur STUN public « quelle IP cette connexion présente-t-elle vue de l'extérieur ? » et recueille la réponse sous forme de candidat ICE. Cet échange se déroule normalement de façon invisible entre deux pairs d'un appel — mais n'importe quel site peut aussi le déclencher en silence en arrière-plan, lire les candidats et en extraire vos adresses.

Cela devient un problème de confidentialité surtout pour les utilisateurs de VPN. Un VPN réachemine votre trafic HTTP habituel par son tunnel, si bien que les sites voient l'IP du VPN au lieu de la vôtre. WebRTC, lui, dialogue avec le serveur STUN via sa propre connexion et, sur certaines configurations, cette connexion contourne entièrement le tunnel — divulguant votre vraie IP alors même que la barre d'adresse laisse croire que vous êtes « protégé ». Les navigateurs modernes tentent aussi de masquer votre adresse réseau locale en la remplaçant par un nom mDNS aléatoire à usage unique se terminant par .local plutôt qu'une IP comme 192.168.1.5 ; cette substitution est une véritable amélioration de la confidentialité, pas un signe de dysfonctionnement.

Cet outil exécute exactement le même processus de collecte ICE qu'une page malveillante pourrait lancer, en utilisant deux serveurs STUN indépendants pour la fiabilité, et compare chaque candidat public recueilli à votre véritable adresse IP HTTP. S'ils concordent, WebRTC n'ajoute aucune exposition au-delà de ce que tout site voit déjà. S'ils diffèrent alors que vous pensez être sous VPN, cet écart est la fuite — et les correctifs ci-dessus expliquent comment la colmater dans votre navigateur.

Ce test ne révèle que ce que votre propre navigateur expose via la collecte ICE de WebRTC ; il ne peut pas détecter les fuites survenant au niveau du système d'exploitation ou du routeur.

Test de fuite WebRTC : votre VPN révèle-t-il votre adresse IP réelle ?

Ce test de fuite WebRTC reproduit exactement le mécanisme de connexion directe qu'utiliserait un script de traçage et détermine si les adresses recueillies révèlent l'IP que votre VPN est censé masquer. Il ouvre une connexion RTCPeerConnection avec un canal de données vierge — sans caméra, sans micro et sans demander la moindre autorisation —, interroge deux serveurs STUN publics sur l'apparence de votre liaison depuis l'extérieur et compare ce résultat avec l'adresse IP d'origine de vos requêtes HTTPS.

Comment lire les candidats ICE présentés par ce test

WebRTC doit répertorier l'ensemble des adresses par lesquelles un correspondant peut communiquer avec vous, ce qui produit une liste de candidats ICE. Cette page affiche cette liste brute avec le type et le protocole de transport, et suspend la détection après cinq secondes.

Au-dessus figurent vos adresses IPv4 et IPv6 habituelles détectées par HTTP — identiques aux données délivrées par quelle est mon adresse IP. Elles constituent le point de repère ; le verdict découle de la confrontation entre ces deux sources.

host, srflx et relay : signification des étiquettes

  • Local (host) : adresse assignée à votre propre carte réseau, soit une IP LAN comme 192.168.1.14, soit un nom .local anonymisé.
  • Public (via STUN) : le candidat srflx, correspondant à l'adresse externe perçue par le serveur STUN. C'est l'indicateur crucial pour un VPN.
  • Relay (TURN) : paquet relayé par un serveur intermédiaire ; ce test utilisant uniquement STUN, une ligne relay demeure exceptionnelle.

Interprétation des diagnostics

  • Fuite détectée : un candidat public STUN diffère de votre IP HTTP ; avec un VPN, cela prouve que le paquet a contourné le tunnel.
  • Aucune fuite : les deux valeurs correspondent parfaitement.
  • IP locale exposée : une adresse LAN réelle apparaît au lieu d'un nom mDNS masqué.
  • Protégé : votre adresse locale est protégée derrière un nom d'hôte .local aléatoire.
  • Aucune IP publique / WebRTC bloqué : serveurs STUN inaccessibles ou WebRTC désactivé dans votre navigateur.

Pourquoi WebRTC révèle l'IP que votre VPN cherche à cacher

WebRTC a été développé pour permettre les visioconférences, les appels audio et le partage de fichiers directs entre navigateurs. Connecter deux postes situés derrière des routeurs distincts impose une traversée de NAT, ce qui exige de répondre à une interrogation externe : de quelle adresse provient ce flux ? Un serveur STUN renvoie cette information, et n'importe quel site web peut déclencher cet échange en arrière-plan via JavaScript.

Cela pose problème dès lors qu'une autre adresse doit être affichée. Votre VPN achemine le trafic HTTP dans son tunnel chiffré, mais WebRTC transmet ses paquets UDP à STUN en empruntant la passerelle par défaut en cas de split-tunneling. Les extensions VPN pour navigateurs illustrent parfaitement ce cas : elles relayent les requêtes web mais négligent les flux UDP du système — ce qui peut contredire les données d'un test VPN réalisé en HTTP.

Un nom d'hôte .local anonyme ne constitue pas une fuite

Si un candidat host indique 7b3f9c21-4d0a-48e7.local au lieu de 192.168.1.14, votre protection est totalement opérationnelle. Il s'agit de l'obfuscation mDNS : le navigateur génère un nom de domaine multicast éphémère pour la carte réseau locale et le fournit à la place de l'IP du réseau local. Chrome, Edge, Brave, Firefox et Safari l'appliquent par défaut — uBlock Origin a supprimé son option WebRTC dédiée dès la version 1.38 car les éditeurs ont intégré cette protection en natif. Deux rappels importants : cela ne protège que l'IP locale (et non une fuite de VPN public), et un site bénéficiant de l'accès caméra ou micro verra l'IP locale réelle.

Comment colmater une fuite WebRTC sous Chrome et Edge

Aucun de ces navigateurs ne propose d'interrupteur direct, et les sections chrome://flags ou edge://flags ne permettent plus de neutraliser WebRTC. Trois solutions éprouvées existent :

  • Adoptez un client VPN système complet (Full-Tunnel) plutôt qu'une extension de navigateur. Si l'intégralité des flux UDP traverse le tunnel, STUN ne verra que l'IP du VPN.
  • Ajustez la politique de traitement IP par extension. Des modules comme WebRTC Leak Prevent configurent chrome.privacy.network.webRTCIPHandlingPolicy sur default_public_interface_only ou disable_non_proxied_udp, empêchant ainsi l'exposition d'adresses locales.
  • Appliquez des stratégies système d'entreprise. Configurez WebRtcIPHandling pour Chrome ou WebRtcLocalhostIpHandling sous SOFTWARE\Policies\Microsoft\Edge avec les clés AllowPublicInterfaceOnly ou DisableNonProxiedUdp. Un redémarrage est requis ; vérifiez dans edge://policy.

Comment désactiver complètement WebRTC dans Firefox

Firefox est l'unique grand navigateur de bureau à intégrer un coupe-circuit direct. Saisissez about:config, confirmez l'avertissement, filtrez sur media.peerconnection.enabled et double-cliquez pour basculer la valeur sur false. WebRTC est alors neutralisé sur tous les sites sans redémarrage, et notre outil l'indiquera comme bloqué.

Cette solution est radicale : les services de conférence web comme Teams, Meet, Discord ou Zoom ne pourront plus se connecter. Pour préserver ces outils, laissez la clé active et passez plutôt media.peerconnection.ice.default_address_only à true — Firefox n'émettra alors que l'adresse de votre passerelle par défaut (celle du VPN).

Comment éliminer les fuites WebRTC sous Brave

Brave met à disposition les paramètres que Chrome dissimule. Rendez-vous dans brave://settings/privacy et recherchez la section WebRTC IP handling policy. Deux choix se démarquent avec un VPN ou un proxy :

  • Default : énumère toutes les interfaces et peut exposer les adresses locales.
  • Default Public and Private Interfaces : route par défaut, mais laisse entrevoir l'IP privée.
  • Default Public Interface Only : route par défaut sans adresses locales ; vos communications fonctionnent. C'est le réglage idéal au quotidien.
  • Disable Non-Proxied UDP : bascule en TCP via le proxy à moins que l'UDP ne soit pris en charge. C'est le profil le plus strict (utilisé dans les fenêtres Tor), mais il peut perturber les appels directs.

Spécificités pour Safari, iPhone et Android

Sur mobile et avec WebKit, les conseils génériques pour PC cessent de s'appliquer.

Safari sous macOS

Les moutures modernes de Safari ne possèdent plus d'interrupteur global persistant. Les menus du mode Développeur ne restent valables que pour la session en cours. Safari protégeant les IP locales derrière mDNS jusqu'à l'autorisation du micro ou de la caméra, la meilleure protection repose sur la gestion des autorisations dans Safari > Réglages > Sites web associée à un VPN système.

iPhone et iPad

Tous les navigateurs sous iOS s'appuient sur le moteur WebKit ; Chrome ou Firefox sur iPhone n'ont ni about:config, ni page de flags, ni extensions, et les bloqueurs de contenu ne peuvent intercepter WebRTC. Pour vous prémunir des fuites, installez un profil VPN complet dans Réglages > VPN acheminant les paquets UDP, puis refaites le test dans Safari.

Android

Chrome pour Android ne dispose d'aucun flag WebRTC ni support d'extensions. Brave pour Android propose en revanche les mêmes politiques de gestion d'IP dans ses réglages de confidentialité. Sous Firefox pour Android, about:config n'est accessible que sur les versions Nightly et Beta. La solution globale consiste à cocher VPN permanent et Bloquer les connexions sans VPN.

Ce que ce test de fuite ne peut pas vous révéler

Cette page observe uniquement ce que votre navigateur communique aux scripts exécutés sur ce domaine. Elle ne peut pas déceler une anomalie située sous la couche applicative — comme un défaut de routage au niveau de l'OS ou un flux IPv6 ignoré par votre VPN — et n'analyse pas les fuites DNS. Si un pare-feu bloque STUN, le résultat affichera „Aucune IP publique“, ce qui indique simplement l'absence de réponse. Par ailleurs, l'IP n'est qu'un critère d'identification parmi d'autres : les polices d'écriture, définitions d'écran et en-têtes recensés par Quel est mon navigateur suffisent souvent à vous distinguer malgré un VPN actif.

Foire aux questions (FAQ)

WebRTC peut-il divulguer ma vraie IP même connecté à un VPN ?

Oui, cela arrive régulièrement. WebRTC émet ses propres requêtes UDP vers des serveurs STUN. Avec un tunnel partagé ou une extension VPN dans le navigateur, ces paquets transitent hors du tunnel sur votre connexion standard. Le serveur STUN détecte alors votre IP de FAI et n'importe quelle page web peut la lire via JavaScript. Un client VPN système complet élimine cette fuite.

Existe-t-il un moyen de désactiver WebRTC dans Microsoft Edge ?

Pas via les paramètres graphiques ordinaires : Edge ne comporte pas d'interrupteur et l'ancien flag dans about:flags a disparu. Sous Windows, vous pouvez néanmoins configurer la stratégie WebRtcLocalhostIpHandling sur AllowPublicInterfaceOnly ou DisableNonProxiedUdp dans le registre sous SOFTWARE\Policies\Microsoft\Edge. Cela nécessite un redémarrage ; contrôlez l'effet sur edge://policy.

Où peut-on désactiver WebRTC et PeerConnection dans Firefox ?

Dans about:config : cherchez la ligne media.peerconnection.enabled et double-cliquez pour la basculer sur false. Cela désactive WebRTC sans redémarrage, mais vos conférences web cesseront de se connecter. Pour préserver les appels vidéo, laissez cette valeur sur true et passez plutôt media.peerconnection.ice.default_address_only à true.

Comment désactiver WebRTC de manière permanente dans Safari ?

C'est impossible dans les versions actuelles de Safari. Le menu expérimental d'autrefois a été retiré et les réglages de développement sont réinitialisés à la fermeture. Comme Safari masque les IP locales derrière mDNS, la démarche la plus efficace consiste à verrouiller les autorisations de sites dans Safari > Réglages > Sites web et à exécuter un VPN système.

Quels sont les meilleurs réglages sous Brave contre les fuites WebRTC ?

Ouvrez brave://settings/privacy et réglez la WebRTC IP handling policy sur « Disable Non-Proxied UDP » lorsque vous êtes sous VPN ou proxy. WebRTC utilisera le protocole TCP via le proxy et STUN n'aura jamais accès à votre adresse réelle. Le mode « Default Public Interface Only » est une excellente option intermédiaire laissant les appels opérationnels.

Quelle politique de gestion d'IP WebRTC devrais-je choisir ?

L'option « Default Public Interface Only » convient à la majorité des usagers : elle masque vos interfaces locales, préserve le protocole UDP et assure le bon déroulement de vos appels. Choisissez « Disable Non-Proxied UDP » uniquement pour une confidentialité renforcée derrière un proxy. Les réglages par défaut continuent quant à eux d'exposer vos cartes réseau locales.

Pourquoi mon adresse IP privée est-elle exposée par WebRTC ?

Dans les navigateurs modernes, ce n'est plus le cas. Chrome, Edge, Brave, Firefox et Safari remplacent votre IP de réseau local par un nom d'hôte mDNS éphémère se terminant par .local. Les pages web reçoivent ce nom au lieu d'une adresse comme 192.168.1.14. Si une IP privée en clair apparaît dans notre test, cette protection est désactivée et doit être corrigée.