Почему часть трафика может идти мимо прокси: PAC, DIRECT и WebRTC
Настройка прокси в браузере не всегда является правилом для всего устройства. PAC-файл может намеренно вернуть DIRECT, отдельная программа может игнорировать системный прокси, а WebRTC использует ICE-кандидаты и собственные варианты соединения. Это не означает автоматическую утечку или поломку, но требует проверки именно тех потоков, которые важны для вашей разрешённой задачи.
Главное за минуту
- Прокси работает только для трафика, который клиент передал ему по правилу.
- PAC может выбрать PROXY, SOCKS или DIRECT для разных адресов.
- Резервное правило DIRECT повышает доступность, но допускает прямой маршрут.
- WebRTC может использовать host, server-reflexive и relay ICE-кандидаты.
- Отключение WebRTC не является универсальным решением и может сломать звонки.
Прикладной прокси не равен всему устройству
Браузер, командная утилита, мессенджер и фоновая служба могут читать разные настройки. Некоторые программы поддерживают только HTTP, другие — SOCKS5, а третьи вообще не умеют использовать прокси. Поэтому зелёный результат в одном окне подтверждает только его маршрут, но ничего не говорит о соседнем процессе.
PAC и явный DIRECT
Функция FindProxyForURL в PAC-файле решает для каждого адреса, использовать ли прокси или прямое соединение. Строка с резервом вида PROXY ...; DIRECT означает: если прокси недоступен, браузер может пойти напрямую. Это допустимая политика доступности, но она не подходит задаче, где прямой маршрут запрещён.
Исключения для локальных имён и корпоративных доменов также часто возвращают DIRECT намеренно. Проверяйте реальный PAC-ответ для нужного URL, а не только наличие адреса файла в настройках. После изменения очищайте кеш конфигурации по документации клиента и повторяйте тест в новом соединении.
Почему WebRTC отличается
WebRTC устанавливает медиасвязь через ICE и собирает кандидаты возможных путей: локальные, полученные через STUN и переданные через TURN. В зависимости от браузера и политики часть этих путей может не совпадать с обычным HTTP-прокси. Другой адрес в WebRTC-тесте поэтому требует анализа кандидата, а не мгновенного вывода о неисправности прокси.
Проверка без публикации данных
Используйте чистый профиль без лишних расширений, разрешённый контрольный сервис и заранее определённый ожидаемый маршрут. Сравните обычный HTTPS-запрос, DNS-поведение и WebRTC только если приложение действительно использует звонки или медиаканал. Скриншоты и логи очищайте от локальных адресов, имён устройств, cookies и реквизитов прокси.
Выбирайте меру по риску
Если прямой маршрут запрещён, уберите DIRECT из соответствующего правила, примените управляемую политику браузера или используйте сетевой туннель с проверяемыми маршрутами. Если WebRTC необходим, предпочтительнее настроить допустимые ICE-пути, чем отключать технологию целиком. Любое изменение проверяйте на звонках, обычных сайтах и восстановлении после сбоя.
Практический чек-лист
- 1Перечислите приложения, для которых прокси обязателен.
- 2Проверьте PAC-результат для реальных URL.
- 3Найдите правила DIRECT и документируйте их назначение.
- 4Тестируйте WebRTC только в сценариях, где он используется.
- 5Не отключайте функции без проверки влияния на приложение.
- 6Удалите адреса и секреты из снимков и журналов.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.