Le proxy du navigateur couvre-t-il WebRTC ?
Un test d’IP Web et une connexion WebRTC peuvent suivre des chemins différents. Vérifiez séparément les communications en temps réel du navigateur.
Le réglage de proxy HTTP d’un navigateur ne couvre pas automatiquement WebRTC. Une page classique de vérification d’IP mesure une requête Web ; un appel peut emprunter d’autres chemins pour la connexion et la découverte d’adresses.
SOCKS5 ne supprime pas cette distinction. L’implémentation de proxy d’URL SOCKS5 intégrée à Chromium prend en charge TCP, pas une association UDP générale. Le protocole permet davantage que cette interface du navigateur.
Les navigateurs proposent des contrôles réseau distincts pour WebRTC. Chrome expose une politique de traitement des IP via son API d’extension de confidentialité, dont disable_non_proxied_udp ; Mozilla documente aussi des réglages de confidentialité réseau pour WebRTC. Cette valeur de Chrome est une politique d’API, pas une case à cocher universelle ni une garantie de masquer toutes les adresses.
Vérifiez la sortie Web ordinaire, puis le comportement WebRTC dans l’application de visioconférence réellement utilisée, avec un diagnostic dont vous comprenez les champs. Les adresses locales, de relais et publiques observées décrivent différentes parties d’une connexion. Notez le navigateur et les conditions du test : politiques, extensions, comportement de confidentialité et chemins disponibles influencent le résultat. Ni « cela fuit toujours » ni un test d’IP Web réussi ne suffit donc à conclure.
Si vous restreignez un chemin WebRTC, réessayez les appels dont vous avez besoin. Réduire l’exposition des adresses peut aussi empêcher un appel d’aboutir. Ce compromis est distinct de la disponibilité d’un point d’accès proxy HTTP.