Ці ахоплівае проксі браўзера таксама WebRTC?
Звычайная праверка вэб-IP і злучэнне WebRTC могуць ісці рознымі шляхамі. Сувязь браўзера ў рэальным часе правярайце асобна.
Налада HTTP-проксі ў браўзеры не ахоплівае WebRTC аўтаматычна. Звычайная старонка праверкі IP вымярае вэб-запыт; выклік можа выкарыстоўваць асобныя шляхі для злучэння і выяўлення адрасоў.
SOCKS5 не скасоўвае гэтай розніцы. Убудаваная ў Chromium рэалізацыя URL-проксі SOCKS5 падтрымлівае TCP, а не ўніверсальную UDP-асацыяцыю. Магчымасці пратакола шырэйшыя за гэты інтэрфейс браўзера.
Браўзеры даюць асобныя сеткавыя сродкі кіравання WebRTC. Chrome прапануе палітыку апрацоўкі IP праз API пашырэнняў прыватнасці, у тым ліку disable_non_proxied_udp; Mozilla таксама дакументуе налады сеткавай прыватнасці WebRTC. Гэта значэнне Chrome — палітыка API, а не ўніверсальны сцяжок ці гарантыя схавання ўсіх адрасоў.
Праверце звычайны вэб-выхад, а потым паводзіны WebRTC ў праграме для канферэнцый, якой сапраўды карыстаецеся, з дыягностыкай, палі якой разумееце. Лакальныя адрасы, адрасы рэтранслятараў і публічна назіраныя адрасы апісваюць розныя часткі злучэння. Запішыце браўзер і ўмовы тэсту: палітыкі, пашырэнні, паводзіны абароны прыватнасці і даступныя шляхі ўплываюць на вынік. Таму ні «заўсёды ўцякае», ні паспяховая праверка вэб-IP не з’яўляюцца дастатковай высновай.
Калі абмяжоўваеце шлях WebRTC, паўторна праверце патрэбныя выклікі. Меншае раскрыццё адрасоў можа таксама перашкодзіць злучэнню выкліку. Гэты кампраміс асобны ад таго, ці даступны пункт HTTP-проксі.