Dekker nettlesarproxyen òg WebRTC?
Ein vanleg sjekk av nett-IP og ei WebRTC-tilkopling kan bruke ulike vegar. Undersøk sanntidskommunikasjonen i nettlesaren separat.
HTTP-proxyinnstillinga i nettlesaren dekker ikkje WebRTC automatisk. Ei vanleg IP-sjekkside måler ein nettførespurnad; ein samtale kan bruke eigne vegar for tilkopling og adresseoppdaging.
SOCKS5 fjernar ikkje dette skiljet. Den innebygde SOCKS5-URL-proxyimplementasjonen i Chromium støttar TCP, ikkje ein generell UDP-assosiasjon. Protokollen har fleire moglegheiter enn dette nettlesargrensesnittet.
Nettlesarar har eigne nettverkskontrollar for WebRTC. Chrome tilbyr ein policy for IP-handtering gjennom API-et for personvernutvidingar, mellom anna disable_non_proxied_udp; Mozilla dokumenterer òg innstillingar for nettverkspersonvern i WebRTC. Denne Chrome-verdien er ein API-policy, ikkje ein universell avkryssingsboks eller ein garanti for å skjule alle adresser.
Sjekk den vanlege nettutgangen, og undersøk deretter WebRTC i konferanseappen du faktisk bruker, med ein diagnose der du forstår felta som vert rapporterte. Lokale adresser, reléadresser og offentleg observerte adresser skildrar ulike delar av ei tilkopling. Noter nettlesar og testvilkår: policyar, utvidingar, personvernåtferd og tilgjengelege vegar påverkar resultatet. Verken «lek alltid» eller ein vellukka sjekk av nett-IP er difor ein tilstrekkeleg konklusjon.
Avgrensar du ein WebRTC-veg, prøv samtalane du treng på nytt. Mindre eksponering av adresser kan òg hindre at ein samtale vert kopla opp. Denne avveginga er uavhengig av om eit HTTP-proxyendepunkt er på nett.