Jildt de browserproxy ek foar WebRTC?
In gewoane web-IP-test en in WebRTC-ferbining kinne oare rûtes brûke. Kontrolearje de realtimekommunikaasje fan de browser apart.
De HTTP-proxyynstelling fan in browser jildt net automatysk foar WebRTC. In gewoane IP-kontrôleside mjit in webfersyk; in petear kin aparte rûtes brûke foar ferbining en it ûntdekken fan adressen.
SOCKS5 nimt dat ûnderskied net wei. De ynboude SOCKS5-URL-proxyymplemintaasje fan Chromium stipet TCP, gjin algemiene UDP-assosjaasje. It protokol kin mear as wat dizze browserynterface biedt.
Browsers hawwe aparte netwurkkontrôles foar WebRTC. Chrome biedt fia syn API foar privacyútwreidingen in belied foar IP-ôfhanneling, ûnder oaren disable_non_proxied_udp; Mozilla dokumintearret ek ynstellingen foar WebRTC-netwurkprivacy. Dy Chrome-wearde is API-belied, gjin universeel karfakje of garânsje dat elk adres ferburgen wurdt.
Kontrolearje de gewoane webútgong, en besjoch dêrnei WebRTC yn de konferinsje-app dy'tst echt brûkst, mei in diagnoaze wêrfan'tst de rapportearre fjilden begrypst. Lokale adressen, relêadressen en iepenbier waarnommen adressen beskriuwe ferskillende dielen fan in ferbining. Notearje browser en testomstannichheden: belied, útwreidingen, privacygedrach en beskikbere rûtes beynfloedzje it resultaat. Noch «lekt altyd» noch in slagge web-IP-test is dêrom in foldwaande konklúzje.
Beheinst in WebRTC-rûte, besykje dan de nedige petearen opnij. Minder bleatstelling fan adressen kin ek foarkomme dat in petear ferbining makket. Dy ôfwaging stiet los fan oft in HTTP-proxy-einpunt online is.