Чаму ваш PAC-файл выбірае не той сеткавы адаптар
У ноўтбука можа быць некалькі лакальных адрасоў. Правіла PAC на аснове myIpAddress() можа вызначыць не той інтэрфейс, які вы чакалі.
Ноўтбук падключаны да офіснага Wi-Fi, сеткавы кабель усталяваны, а VPN-адаптар усё яшчэ прысутнічае. Ваш PAC-файл пытае myIpAddress(), у якой сетцы ён знаходзіцца. Гэта здаецца разумным, пакуль ён не атрымае адрас, які належыць не таму адаптару.
Адсутная дэталь у тым, што функцыя вяртае адзін адрас. Гэта не пералік усіх інтэрфейсаў, і яна не звяртаецца да вэб-сайта, каб вызначыць ваш публічны IP. Прыватны адрас або нават запасны loopback не паведамляе, які адрас выхаду выкарыстае запыт праз проксі.
Адзін адказ для машыны з некалькімі адрасамі
Выбар сеткавага інтэрфейсу належыць рэалізацыі PAC. Старыя парады перапарадкоўваць адаптары Windows могуць апісваць пэўную версію браўзера і аперацыйнай сістэмы, але гэта дрэннае ўніверсальнае рашэнне. Chromium дакументуе ўласны алгарытм выбару і абмежаванні для шматхамавых сістэм; іншы кліент не абавязаны рабіць той жа выбар.
Пачніце з вызначэння значэння, якое фактычна падаў пацярпелы браўзер, затым параўнайце яго з праверкамі падсеткі ў вашым скрыпце. Зрабіце гэта асобна для Wi-Fi, Ethernet і ўзгодненага VPN-злучэння. Адрас, які выглядае нечаканым, усё яшчэ можа адпавядаць правілам рэалізацыі.
Зрабіце рашэнне менш залежным ад здагадак
Дзе магчыма, выбірайце проксі па імені хоста прызначэння, а не па меркаваным кліенцкім інтэрфейсе. Калі вызначэнне сеткі неабходна, выкарыстоўвайце наўмысны, дакументаваны сігнал, які кантралюе ваша арганізацыя. Вызначэнне на аснове DNS таксама мае рэжымы збою, таму вызначце, што адбудзецца, калі гэты сігнал недаступны.
Некаторыя рэалізацыі прапануюць myIpAddressEx(). Праверце яго падтрымку і фармат вяртання, перш чым прымаць; гэта не прамая замена для аднаго радка IPv4. Нарэшце, праверце маршрут запыту самастойна. Правільнае вызначэнне офіснай падсеткі і дасягненне патрэбнага проксі — дзве асобныя вынікі.