Mode d'emploi
- Activez votre VPN, puis ouvrez cette page et appuyez sur Lancer le test.
- Patientez quelques secondes pendant que la page contacte deux serveurs STUN publics.
- Lisez le verdict. S'il indique qu'une adresse publique diffère, désactivez puis réactivez le VPN, et lancez de nouveau le test une fois.
Ce que fait le test
WebRTC permet aux navigateurs de se connecter directement entre eux, pour les appels et le partage de fichiers. Pour trouver un chemin, il recueille des adresses candidates : celles de l'appareil, et l'adresse publique qu'un serveur STUN renvoie. Le test lance cette collecte avec deux serveurs STUN publics, stun.l.google.com de Google et stun.cloudflare.com de Cloudflare, et lit les candidats trouvés par le navigateur.
L'adresse publique renvoyée par un serveur STUN est celle par laquelle votre trafic sort. Si elle n'est pas l'adresse que voit le serveur du site pour votre requête, un VPN ne transporte peut-être pas tout votre trafic. Les serveurs STUN voient votre adresse publique, comme il le faut pour répondre, et rien d'autre de cette page.
Comment arrêter les fuites WebRTC, par navigateur
Chaque navigateur propose des réglages différents, et les étapes changent d'une version à l'autre. Vérifiez le résultat de ce test après chaque changement.
- Firefox : ouvrez about:config et réglez media.peerconnection.ice.default_address_only sur true, pour que WebRTC n'utilise que la route par défaut. Régler media.peerconnection.enabled sur false désactive WebRTC complètement, ce qui arrête les appels dans le navigateur. Le wiki de Mozilla (en anglais) décrit les deux réglages.
- Edge : Microsoft documente une stratégie nommée WebRtcLocalhostIpHandling, réglée par les administrateurs (en anglais). Sa valeur AllowPublicInterfaceOnly fait que WebRTC n'utilise que l'interface publique. Aucun réglage pour les utilisateurs ordinaires n'a été trouvé.
- Brave : ses réglages comportent une option d'adresse IP pour WebRTC, Default Public Interface Only, décrite dans la documentation de Brave (en anglais). L'emplacement dans le menu dépend de la version.
- Chrome : aucun réglage officiel pour les utilisateurs ordinaires n'a été trouvé. Les extensions qui appliquent la même limite sont la voie habituelle ; choisissez-en une dont vous connaissez le code.
- Safari : aucun réglage pour les adresses WebRTC n'a été vérifié.
- Tous navigateurs : un VPN qui bloque le trafic WebRTC, ou qui fait passer tout l'appareil par lui, supprime le problème à la source. Relancez ensuite ce test.
Ce que ce test ne montre pas
- Il ne teste pas toutes les routes. Une connexion peut utiliser une adresse que les serveurs STUN n'ont pas signalée.
- Il ne peut pas dire de quelle interface réseau vient un candidat ; une adresse qui diffère peut donc provenir d'une connexion ordinaire.
- Un nom .local masqué représente une adresse locale que le navigateur n'a pas révélée ; le test ne peut pas la lire.
Exemple : un VPN qui laisse fuir
Les adresses ci-dessous sont des adresses de documentation de la RFC 5737, qui tiennent la place de vraies adresses. Le serveur du site voit l'adresse du serveur VPN, mais le navigateur signale aussi l'adresse de la connexion ordinaire.
Le verdict est alors une fuite possible, et la page liste l'adresse qui diffère.
| Adresse | Vue par | Résultat |
|---|---|---|
| 203.0.113.7 | Le serveur du site | L'adresse du VPN |
| 198.51.100.9 | Le navigateur (WebRTC) | Diffère : la connexion ordinaire |
| 192.168.1.10 | Le navigateur (local) | Adresse locale, non publique |
Questions fréquentes
Pourquoi WebRTC révèle-t-il mon adresse IP ?
WebRTC recueille toutes les adresses de l'appareil, pour trouver une route vers un autre navigateur. Un VPN transporte votre trafic web, mais une partie du trafic WebRTC peut encore sortir par la connexion ordinaire, sauf si le navigateur ou le VPN est réglé pour l'empêcher.
Ce test envoie-t-il mon adresse IP quelque part ?
Votre adresse parvient aux deux serveurs STUN pendant le test, car ils doivent y répondre. Le serveur du site la voit aussi, comme pour toute requête, et ne la conserve pas. Rien d'autre de ce que vous saisissez ou cliquez n'est envoyé.
Pourquoi le test dit-il qu'un nom .local masqué n'est pas mon adresse ?
Les navigateurs remplacent l'adresse privée d'un appareil par un nom aléatoire se terminant par .local, si bien qu'une page web ne peut pas lire l'adresse elle-même. Ce nom est un substitut : le test compte ces noms, mais ne peut pas voir derrière.
Que faire si le verdict indique une adresse publique différente alors que je n'ai pas de VPN ?
Votre appareil peut avoir une adresse IPv6 que votre trafic IPv4 n'utilise pas, et le test la signale. Vérifiez les réglages IPv6 de votre connexion avant de conclure à une fuite.
Pourquoi le test ne demande-t-il pas l'accès à la caméra ou au micro ?
Il n'en a pas besoin. Accorder l'accès à la caméra ou au micro ferait afficher au navigateur votre vraie adresse locale ; le test laisse ce choix à votre discrétion.
Puis-je faire confiance à un VPN qui affirme bloquer WebRTC ?
Testez-le. Lancez cette page avec le VPN actif et lisez le verdict. Une affirmation n'est pas une preuve, et une fuite peut revenir après une mise à jour ou un changement de réseau.
Sources
- RFC 8839 (en anglais) : syntaxe SDP pour ICE (attribut candidate, section 5.1)
- Brouillon IETF (en anglais) : utiliser Multicast DNS pour protéger la vie privée lors de l'exposition des candidats ICE (expiré)
- Wiki de Mozilla (en anglais) : réglages de confidentialité WebRTC
- Microsoft (en anglais) : stratégie WebRtcLocalhostIpHandling pour Microsoft Edge
- Cloudflare (en anglais) : serveurs TURN et STUN
- RFC 5737 (en anglais) : blocs d'adresses IPv4 réservés à la documentation
Chiffres et texte vérifiés pour la dernière fois le mardi 10 novembre 2026.