Настройка 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-прокси.

Похожие статьи