Ĉu retumila prokurilo kovras ankaŭ WebRTC?
Ordinara reta IP-kontrolo kaj WebRTC-konekto povas uzi malsamajn vojojn. Kontrolu la realtempan komunikadon de la retumilo aparte.
La agordo de HTTP-prokurilo en retumilo ne aŭtomate kovras WebRTC. Ordinara IP-kontrola paĝo mezuras retpeton; voko povas uzi apartajn vojojn por konektiĝo kaj adresmalkovro.
SOCKS5 ne forigas tiun distingon. La enkonstruita SOCKS5-URL-prokurila realigo de Chromium subtenas TCP, ne ĝeneralan UDP-asocion. La kapabloj de la protokolo estas pli vastaj ol tiu retumila interfaco.
Retumiloj provizas apartajn retajn regilojn por WebRTC. Chrome disponigas politikon pri IP-traktado per sia API por privatecaj kromprogramoj, inkluzive de disable_non_proxied_udp; ankaŭ Mozilla dokumentas agordojn pri reta privateco de WebRTC. Tiu Chrome-valoro estas API-politiko, ne universala markobutono aŭ garantio kaŝi ĉiun adreson.
Kontrolu la ordinaran retan eliron, poste la konduton de WebRTC en la efektive uzata konferenca aplikaĵo, per diagnozilo kies raportitajn kampojn vi komprenas. Lokaj adresoj, relajsoadresoj kaj publike observitaj adresoj priskribas malsamajn partojn de konekto. Registru la retumilon kaj testkondiĉojn: politikoj, kromprogramoj, privateca konduto kaj disponeblaj vojoj influas la rezulton. Do nek «ĉiam likas» nek sukcesa reta IP-kontrolo sufiĉas kiel konkludo.
Se vi limigas WebRTC-vojon, reprovu la bezonatajn vokojn. Malpli da adresmalkaŝo povas ankaŭ malhelpi vokon konektiĝi. Tiu kompromiso estas aparta de la demando, ĉu HTTP-prokurila finpunkto estas atingebla.