Czy proxy w przeglądarce obejmuje też WebRTC?
Zwykły test adresu IP w sieci i połączenie WebRTC mogą korzystać z różnych dróg. Komunikację czasu rzeczywistego w przeglądarce sprawdzaj osobno.
Ustawienie proxy HTTP w przeglądarce nie obejmuje automatycznie WebRTC. Zwykła strona sprawdzająca IP mierzy żądanie WWW; rozmowa może używać innych ścieżek do łączenia i wykrywania adresów.
SOCKS5 nie znosi tego rozróżnienia. Wbudowana w Chromium implementacja proxy URL SOCKS5 obsługuje TCP, a nie ogólną asocjację UDP. Możliwości protokołu są szersze niż możliwości tego interfejsu przeglądarki.
Przeglądarki mają osobne mechanizmy sterowania siecią WebRTC. Chrome udostępnia zasady obsługi IP przez API rozszerzeń prywatności, w tym disable_non_proxied_udp; Mozilla również dokumentuje ustawienia prywatności sieciowej WebRTC. Ta wartość Chrome jest zasadą API, a nie uniwersalnym polem wyboru czy gwarancją ukrycia wszystkich adresów.
Sprawdź zwykłe wyjście ruchu WWW, a potem zachowanie WebRTC w faktycznie używanej aplikacji konferencyjnej, korzystając z diagnostyki, której pola rozumiesz. Adresy lokalne, adresy przekaźników i publicznie zaobserwowane adresy opisują różne części połączenia. Zapisz przeglądarkę i warunki testu: zasady, rozszerzenia, działanie ochrony prywatności i dostępne drogi wpływają na wynik. Ani „zawsze wycieka”, ani udany test IP w sieci nie wystarczą więc jako wniosek.
Po ograniczeniu ścieżki WebRTC ponownie przetestuj potrzebne rozmowy. Mniejsze ujawnianie adresów może też uniemożliwić zestawienie rozmowy. Ten kompromis jest niezależny od tego, czy punkt końcowy proxy HTTP jest dostępny.