Ви відредагували PAC-файл. Чи завантажив браузер його знову?
Збереження проксі-скрипта на його сервері не доводить, що браузер замінив свою кешовану конфігурацію. Перевірте отримання, перш ніж налагоджувати нове правило.
Ви змінюєте PAC-файл з проксі A на проксі B, зберігаєте його й перезавантажуєте сайт. Сайт досі бачить проксі A. Перш ніж знову змінювати правило, перевірте, чи браузер узагалі отримав новий скрипт.
Перезавантаження сторінки й завантаження PAC — дві різні операції. Клієнт може зберігати скрипт незалежно від переглянутої сторінки. Уже встановлене з'єднання додає ще одну причину, чому наступна видима активність може не показати нового рішення про маршрутизацію.
Шукайте запит PAC
Використовуйте журнал доступу сервера конфігурації та доступну мережеву діагностику клієнта. Визначте точний PAC URL, відповідь і версію доставленого скрипта. Файл, відредагований в одному каталозі, може існувати поряд з іншим файлом, який обслуговує активний веб-хост.
Chromium документує власну поведінку кешування та повторного завантаження PAC. Інші клієнти мають свої правила. Не перетворюйте стару байку «перезапустіть браузер» на універсальний інтервал оновлення.
Зробіть порівняння осмисленим
Якщо доречний контрольований новий сеанс браузера, використайте підтримуваний механізм конфігурації та підтвердьте отримання, а не покладайтеся лише на екран налаштувань. Зважайте, що закриття вікна не завжди завершує всі процеси браузера.
Коли відомо, що новий скрипт завантажено, перегляньте його результат для пункту призначення. Лише після цього досліджуйте повторне використання з'єднання або адресу виходу проксі-сервісу. Ці пізніші етапи не можуть пояснити редагування PAC, яке клієнт так і не отримав.