L’impostazione del proxy HTTP del browser non copre automaticamente WebRTC. Una normale pagina di verifica IP misura una richiesta web; una chiamata può usare percorsi distinti per la connessione e la scoperta degli indirizzi.

SOCKS5 non elimina questa distinzione. L’implementazione del proxy URL SOCKS5 integrata in Chromium supporta TCP, non un’associazione UDP generica. Le capacità del protocollo sono più ampie di quelle di questa interfaccia del browser.

I browser offrono controlli di rete separati per WebRTC. Chrome espone una policy di gestione degli IP tramite l’API delle estensioni per la privacy, compreso disable_non_proxied_udp; anche Mozilla documenta impostazioni di privacy di rete per WebRTC. Questo valore di Chrome è una policy API, non una casella universale né una garanzia di nascondere ogni indirizzo.

Controlla la normale uscita web, poi esamina il comportamento WebRTC nell’applicazione di conferenza che usi davvero, con uno strumento diagnostico di cui comprendi i campi. Indirizzi locali, di relay e pubblici osservati descrivono parti diverse di una connessione. Annota browser e condizioni di prova: policy, estensioni, comportamento della privacy e percorsi disponibili influiscono sul risultato. Né “perde sempre indirizzi” né una verifica IP web riuscita bastano quindi per concludere.

Se limiti un percorso WebRTC, riprova le chiamate che ti servono. Ridurre l’esposizione degli indirizzi può anche impedire la connessione di una chiamata. Questo compromesso è distinto dalla disponibilità di un endpoint proxy HTTP.

Articoli correlati