Почему ваш PAC-файл выбирает не тот сетевой адаптер

Ноутбук подключён к офисному Wi-Fi, сетевой кабель вставлен, а VPN-адаптер всё ещё присутствует. Ваш PAC-файл спрашивает myIpAddress(), в какой сети он находится. Это звучит разумно, пока не придёт адрес, принадлежащий не тому адаптеру.

Недостающая деталь в том, что функция возвращает один адрес. Это не перечень всех интерфейсов, и она не обращается к веб-сайту, чтобы узнать ваш публичный IP. Частный адрес или даже резервный loopback не говорит, какой адрес выхода будет использовать запрос через прокси.

Один ответ для машины с несколькими адресами

Выбор сетевого интерфейса относится к реализации PAC. Старый совет переупорядочить адаптеры Windows может описывать конкретную версию браузера и операционной системы, но это плохое универсальное решение. Chromium документирует собственный алгоритм выбора и ограничения при нескольких сетях; другой клиент не обязан делать тот же выбор.

Начните с определения значения, которое фактически предоставил затронутый браузер, затем сравните его с проверками подсети в вашем скрипте. Сделайте это отдельно в Wi-Fi, Ethernet и одобренном VPN-подключении. Адрес, который выглядит неожиданно, всё ещё может соответствовать правилам реализации.

Сделайте решение менее зависимым от догадок

Где возможно, выбирайте прокси по имени хоста назначения, а не по предполагаемому клиентскому интерфейсу. Если обнаружение сети необходимо, используйте намеренный, документированный сигнал, который контролирует ваша организация. Обнаружение на основе DNS тоже имеет режимы отказа, поэтому определите, что происходит, когда этот сигнал недоступен.

Некоторые реализации предлагают myIpAddressEx(). Проверьте его поддержку и формат возврата, прежде чем внедрять; это не прямая замена одной строки IPv4. Наконец, независимо проверьте итоговый маршрут запроса. Правильно распознать офисную подсеть и добраться до нужного прокси — два разных результата.