En webbläsares HTTP-proxyinställning omfattar inte automatiskt WebRTC. En vanlig sida för IP-kontroll mäter en webbförfrågan; ett samtal kan använda separata vägar för anslutning och adressupptäckt.

SOCKS5 tar inte bort den skillnaden. Chromiums inbyggda SOCKS5-URL-proxyimplementering stöder TCP, inte en allmän UDP-association. Protokollets möjligheter är bredare än vad det här webbläsargränssnittet erbjuder.

Webbläsare har separata nätverkskontroller för WebRTC. Chrome erbjuder en policy för IP-hantering via sitt API för integritetstillägg, bland annat disable_non_proxied_udp; Mozilla dokumenterar också inställningar för nätverksintegritet i WebRTC. Chrome-värdet är en API-policy, ingen universell kryssruta eller garanti för att alla adresser döljs.

Kontrollera den vanliga webbutgången och undersök sedan WebRTC i det konferensprogram du faktiskt använder, med en diagnostik vars rapporterade fält du förstår. Lokala adresser, reläadresser och offentligt observerade adresser beskriver olika delar av en anslutning. Anteckna webbläsare och testvillkor: policyer, tillägg, integritetsbeteende och tillgängliga vägar påverkar resultatet. Varken ”läcker alltid” eller ett lyckat webb-IP-test räcker därför som slutsats.

Om du begränsar en WebRTC-väg, prova samtalen du behöver igen. Minskad exponering av adresser kan också hindra ett samtal från att ansluta. Den avvägningen är skild från om en HTTP-proxyendpoint är online.

Relaterade artiklar