Чому ваш PAC-файл вибирає не той мережевий адаптер

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

Відсутня деталь полягає в тому, що функція повертає одну адресу. Це не перелік усіх інтерфейсів, і вона не звертається до вебсайту, щоб дізнатися вашу публічну IP. Приватна адреса або навіть резервний loopback не повідомляє, яку адресу виходу використає запит через проксі.

Одна відповідь для машини з кількома адресами

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

Почніть із визначення значення, яке фактично надав уражений браузер, а потім порівняйте його з перевірками підмережі у вашому скрипті. Зробіть це окремо в Wi-Fi, Ethernet і схваленому VPN-з'єднанні. Адреса, яка виглядає несподівано, все ще може відповідати правилам реалізації.

Зробіть рішення менш залежним від здогадів

Де можливо, вибирайте проксі за іменем хоста призначення, а не за передбачуваним клієнтським інтерфейсом. Якщо виявлення мережі необхідне, використовуйте навмисний, задокументований сигнал, який контролює ваша організація. Виявлення на основі DNS також має режими збою, тому визначте, що відбувається, коли цей сигнал недоступний.

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