Вы адрэдагавалі файл PAC. Ці браўзер загрузіў яго зноў?
Захаванне проксі-скрыпта на яго серверы не даказвае, што браўзер замяніў сваю кэшаваную канфігурацыю. Праверце атрыманне, перш чым адладжваць новае правіла.
Вы змяняеце файл PAC з проксі A на проксі B, захоўваеце яго і перазагружаеце сайт. Сайт па-ранейшаму бачыць проксі A. Перш чым зноў змяняць правіла, праверце, ці браўзер наогул атрымаў новы скрыпт.
Перазагрузка старонкі і загрузка PAC — розныя аперацыі. Кліент можа захоўваць скрыпт незалежна ад старонкі, якую праглядаюць. Ужо ўсталяванае злучэнне дадае яшчэ адну прычыну, па якой наступная бачная актыўнасць можа не паказваць свежае рашэнне аб маршрутызацыі.
Шукайце запыт PAC
Выкарыстоўвайце журнал доступу сервера канфігурацыі і даступную сеткавую дыягностыку кліента. Вызначце дакладны URL PAC, адказ і версію дастаўленага скрыпта. Файл, адрэдагаваны ў адной папцы, можа суіснаваць з іншым файлам, які абслугоўвае актыўны вэб-хост.
Chromium дакументуе ўласныя паводзіны кэшавання і паўторнай загрузкі PAC. Іншыя кліенты маюць свае правілы. Пазбягайце ператварэння старога анекдота «перазапусціце браўзер» ва ўніверсальны інтэрвал абнаўлення.
Зрабіце параўнанне змястоўным
Калі кантраляваная свежая сесія браўзера мэтазгодная, выкарыстоўвайце падтрымліваемы механізм канфігурацыі і пацвердзіце атрыманне, а не спадзявайцеся толькі на экран налад. Улічвайце, што закрыццё акна не заўсёды спыняе ўсе працэсы браўзера.
Калі вядома, што новы скрыпт загружаны, праверце яго вынік для пункту прызначэння. Толькі пасля гэтага даследуйце паўторнае выкарыстанне злучэння або адрас выхаду проксі-службы. Гэтыя познія этапы не могуць патлумачыць праўку PAC, якую кліент так і не атрымаў.