En browsers HTTP-proxyindstilling dækker ikke automatisk WebRTC. En almindelig IP-tjekside måler en webanmodning; et opkald kan bruge særskilte veje til forbindelse og adresseopdagelse.

SOCKS5 fjerner ikke den forskel. Chromiums indbyggede SOCKS5-URL-proxyimplementering understøtter TCP, ikke en generel UDP-association. Protokollen kan mere end denne browsergrænseflade.

Browsere har særskilte netværkskontroller til WebRTC. Chrome stiller en politik for IP-håndtering til rådighed via sin API til privatlivsudvidelser, herunder disable_non_proxied_udp; Mozilla dokumenterer også netværksindstillinger for privatliv i WebRTC. Denne Chrome-værdi er en API-politik, ikke et universelt afkrydsningsfelt eller en garanti for at skjule alle adresser.

Tjek den almindelige webudgang, og undersøg derefter WebRTC i det konferenceprogram, du faktisk bruger, med en diagnostik, hvis rapporterede felter du forstår. Lokale adresser, relæadresser og offentligt observerede adresser beskriver forskellige dele af en forbindelse. Notér browser og testbetingelser: politikker, udvidelser, privatlivsadfærd og tilgængelige veje påvirker resultatet. Hverken »lækker altid« eller et vellykket web-IP-tjek er derfor en tilstrækkelig konklusion.

Begrænser du en WebRTC-vej, så prøv de nødvendige opkald igen. Mindre adresseeksponering kan også forhindre et opkald i at forbinde. Den afvejning er adskilt fra, om et HTTP-proxyendepunkt er online.

Relaterede artikler