Fuite WebRTC et fuite DNS : comment prévenir l'exposition de votre IP
Une fuite WebRTC survient lorsque le navigateur expose votre IP réelle via des requêtes STUN, même avec un proxy actif. Une fuite DNS survient lorsque les résolutions de noms de domaine sont envoyées à votre FAI au lieu du tunnel proxy. Ces deux fuites annulent l'intérêt du routage du trafic via Nsocks ou tout autre fournisseur. Le test ne prend que quelques minutes, et les correctifs ci-dessous s'appliquent à Chrome, Firefox et aux sessions scriptées.
Légende utilisée sur cette page : ✅ confirmé par la vérification · ❌ fuite ou contrôle manquant · ⚠️ protection partielle · 💡 conseil pratique. Aucune autre marque n'est utilisée.
Qu'est-ce qu'une fuite WebRTC ?
Une fuite WebRTC expose votre IP locale ou publique via les candidats ICE collectés lors d'une connexion pair à pair, quels que soient les paramètres du proxy. Les navigateurs utilisent WebRTC pour les appels vidéo, et les requêtes vers le serveur STUN passent par UDP, un protocole que la plupart des proxys HTTP ne couvrent pas. La barre d'adresse semble proxyfiée, mais le navigateur rapporte en silence autre chose.
💡 Exécutez un test de fuite WebRTC avant toute tâche orientée client, pas après que quelque chose semble anormal.
Qu'est-ce qu'une fuite DNS ?
Une fuite DNS se produit lorsque la résolution du nom d'hôte se fait sur votre réseau local au lieu de passer par le proxy. Les requêtes DNS révèlent les sites que vous visitez, et le résolveur utilisé expose souvent le réseau d'origine. Les configurations SOCKS5 standard résolvent le DNS localement par défaut, et c'est là que cette exposition commence.
Types de fuites, causes et correctifs
La plupart des problèmes d'exposition remontent à une courte liste de causes. Le tableau ci-dessous est la référence unique de cet article, donc les types de fuites ne sont pas répétés sous chaque titre. Chaque ligne indique une cause, un moyen de la détecter et le correctif.
| Type de fuite | Cause | Comment la détecter | Correctif |
|---|---|---|---|
| WebRTC | les requêtes STUN contournent le proxy via UDP | vérification des candidats ICE du navigateur | restreindre la politique de gestion des IP |
| DNS | requêtes du résolveur envoyées hors du tunnel | comparer le résolveur à l'emplacement du proxy | utiliser la résolution DNS distante |
| IPv6 | le proxy ne couvre que l'IPv4 | un test double pile affiche une seconde adresse | désactiver l'IPv6 ou le router |
| Candidat mDNS | nom d'hôte local exposé pendant la collecte ICE | nom d'hôte mDNS visible | activer l'obfuscation des candidats |
| Tunnel interrompu | le proxy se déconnecte en pleine session | changement soudain d'IP en cours de tâche | ajouter une logique d'échec rapide |
Comment tester votre configuration pour détecter les fuites
Ce qu'il faut vérifier après le lancement du profil
Un test de fuite WebRTC associé à un test de fuite DNS détecte la plupart des expositions avant qu'elles n'atteignent la production. Les étapes ci-dessous fonctionnent de la même manière pour un onglet de navigateur ou une session scriptée. Exécutez les cinq à chaque fois, pas seulement quand quelque chose semble anormal.
- Notez votre IP réelle avec le proxy désactivé.
- Activez le proxy et confirmez que l'IP affichée a changé.
- Lancez un test de fuite IP avec une vérification du résolveur sur un site réputé.
- Comparez chaque résultat avec votre IP réelle et le résolveur de votre FAI, signalez toute correspondance.
- Répétez dans l'environnement de travail réel, car un résultat propre dans un onglet n'a que peu de valeur pour l'automatisation.
Comment prévenir les fuites DNS avec socks5h
Le SOCKS5 classique résout les noms d'hôtes côté client, tandis que socks5h envoie cette résolution à travers le proxy lui-même. Cette seule lettre ferme d'emblée le chemin de fuite DNS le plus courant. La résolution DNS distante garde chaque requête dans le tunnel, ce qui compte pour la recherche, la QA et le travail spécifique à un marché.
Là où le nom de domaine est résolu
curl --socks5-hostname NOM_D'UTILISATEUR:MOT_DE_PASSE@IP_DU_PROXY:PORT https://example.com
La plupart des bibliothèques de scraping utilisent le socks5 classique par défaut sauf indication contraire, donc vérifier la chaîne vaut trente secondes. ✅ Une prise en charge documentée de socks5h économise une étape.
Comment contrôler WebRTC dans le navigateur
Les navigateurs sont livrés avec des politiques de gestion des IP WebRTC différentes, et aucune ne promet une anonymisation complète à elle seule. Firefox permet de désactiver entièrement WebRTC via about:config, tandis que Chromium s'appuie sur la même politique ou sur une extension, faute de bouton natif. La politique définie sur désactiver l'UDP non proxyfié force les candidats ICE à passer par le proxy actif.
- ✅ Firefox : media.peerconnection.enabled sur false, ou ice.no_host pour une protection partielle
- ✅ Chromium : politique de gestion des IP définie sur désactiver l'UDP non proxyfié
- ⚠️ Les extensions aident, mais les mises à jour peuvent réinitialiser les paramètres
- ❌ Supposer qu'un proxy bloque WebRTC automatiquement, la plupart ne le font pas
Retestez après chaque mise à jour du navigateur, car les éditeurs modifient le comportement par défaut plus souvent que les notes de version ne le laissent entendre. Une mauvaise politique est souvent la principale cause d'une fuite WebRTC à cette couche. L'obfuscation mDNS masque l'IP locale, mais le côté public nécessite son propre correctif.
Trafic IPv6 et routes hors tunnel
Le trafic IPv6 passe outre un proxy conçu uniquement pour l'IPv4, et cette faille est l'un des chemins d'exposition les plus négligés en ce moment. Une connexion double pile peut afficher une adresse IPv4 propre via le proxy tandis que l'IPv6 sort par le FAI réel. La plupart des outils de vérification d'IP n'affichent que le résultat IPv4. Une fuite IP WebRTC via une interface IPv6 non tunnellisée ressemble à une session propre.
💡 Désactivez l'IPv6 au niveau de l'adaptateur si la configuration du proxy ne le couvre pas, ou confirmez le routage double pile avant d'exécuter quoi que ce soit d'orienté client.
Cohérence : IP, DNS, fuseau horaire et langue
Réussir les tests laisse quand même des failles si d'autres signaux ne s'alignent pas. Un test de fuite DNS seul ne détectera pas un décalage de fuseau horaire entre l'horloge système et la région du proxy. La langue, la disposition du clavier et les paramètres régionaux alimentent tous l'image qu'une plateforme construit à partir d'une session. Ce risque se multiplie à travers plusieurs profils clients, et l'analyse approfondie se trouve dans notre guide sur la gestion de plusieurs profils de navigateur.
Checklist pré-vol pour les tâches automatisées
Les tâches automatisées et les navigateurs headless nécessitent une vérification répétable avant chaque exécution, pas une configuration unique. Cette liste diffère des étapes manuelles ci-dessus, car les scripts échouent silencieusement de manières qu'un testeur remarque immédiatement. Considérez-la comme le seuil minimal avant la production.
- ✅ Journaliser l'IP sortante par requête, pas seulement au début de la session
- ✅ Échouer rapidement si l'IP journalisée sort de la plage attendue
- ✅ Revérifier les fuites après chaque mise à jour du navigateur ou du pilote
- ✅ Confirmer que la résolution distante est active dans la chaîne de connexion
- ✅ Vérifier le routage IPv6 séparément de l'IPv4
- ✅ Vérifier que le fuseau horaire et les paramètres régionaux correspondent à la région du proxy
- ⚠️ Considérer le succès de la semaine dernière comme expiré, pas comme actuel
- ❌ Ne pas sauter la vérification parce que « ça marchait hier »
Une courte liste ne vaut que si quelqu'un en est responsable, épinglez-la donc là où l'équipe la voit avant qu'une tâche ne soit mise en production.
Erreurs courantes
La plupart des problèmes d'exposition répétés proviennent de failles de processus, pas d'un type de fuite inconnu. Les équipes vérifient souvent une fois à l'installation et sautent le retest après une mise à jour. Tester dans un onglet normal, au lieu de l'environnement réel, donne un faux sentiment de sécurité. Se fier uniquement au tableau de bord d'un fournisseur, plutôt qu'à un outil de vérification indépendant, rate ce qu'il n'a pas été conçu pour détecter. Traiter une fuite WebRTC comme un incident isolé, plutôt qu'une défaillance de processus, garantit une récidive.
Comment la configuration du proxy affecte le risque de fuite
Transparence : Nsocks est notre service, et cette section décrit comment notre configuration gère les risques ci-dessus. Nous vendons des proxys résidentiels et des proxys IP statiques, tous deux avec résolution DNS distante côté proxy. La plupart des tickets d'assistance concernant une fuite WebRTC remontent à une ligne du tableau ci-dessus. Le tableau décrit ce que chaque fonctionnalité signifie au quotidien, sans langage marketing.
| Fonctionnalité | Ce que cela signifie en pratique |
|---|---|
| Prise en charge de socks5h | La résolution se fait sur le proxy, pas sur le client |
| Routage compatible IPv6 | Le trafic double pile reste dans le tunnel là où c'est possible |
| Gestion des IP documentée | Les étapes correspondent aux politiques actuelles du navigateur |
| Journalisation des sessions | IP sortante visible par requête pour la QA |
Rien de tout cela ne remplace la configuration au niveau du navigateur ni l'habitude de retester. Un proxy gère le routage ; le navigateur décide de ce qu'il révèle. Les équipes qui exécutent un test de fuite WebRTC avant chaque session client constatent moins de surprises. Essayez la démo Nsocks pour voir les détails de connexion, ou inscrivez-vous pour accéder au tableau de bord.
Points clés à retenir
- Exécutez un test de fuite pour WebRTC et DNS avant chaque session client, pas juste une fois.
- socks5h déplace la résolution vers le proxy, fermant le chemin d'exposition le plus courant.
- L'IPv6 nécessite sa propre vérification, car la plupart des outils IP n'affichent que l'IPv4 par défaut.
- La cohérence entre IP, DNS, fuseau horaire et paramètres régionaux compte autant qu'un seul test.
- Retester après les mises à jour détecte la plupart des fuites que les équipes décrivent comme « soudaines ».
Transparence et sources des données
Cet article est publié par Nsocks. Nous vendons des proxys et avons un intérêt commercial dans la section décrivant notre propre configuration. Les outils de test et paramètres de navigateur mentionnés appartiennent à leurs propriétaires respectifs, y compris les éditeurs de navigateurs et les services de vérification indépendants. Les détails ont été vérifiés en août 2026, et le comportement peut changer selon les versions, revalidez donc d'abord les indicateurs.
Questions fréquentes
Qu'est-ce qu'une fuite WebRTC ?
Un navigateur révèle votre IP réelle via des candidats STUN ou ICE malgré un proxy actif.
Comment tester une fuite DNS ?
Lancez une vérification du résolveur sur un site de test de fuite et comparez-la à l'emplacement de votre proxy.
Quelle est la différence entre SOCKS5 et socks5h ?
SOCKS5 résout les noms d'hôtes localement ; socks5h envoie cette résolution via le serveur proxy.
Désactiver WebRTC casse-t-il les appels vidéo ?
Oui, le désactiver arrête complètement les appels, les restrictions ICE partielles fonctionnent donc mieux.
L'IPv6 peut-il exposer mon IP réelle ?
Oui, si un proxy ne gère que le trafic IPv4, l'IPv6 peut aussi le contourner.
À quelle fréquence dois-je retester ma configuration d'automatisation ?
Après chaque mise à jour du navigateur ou du pilote, plus selon un calendrier fixe.
