Застрягли на «Resolving Host in Proxy Script»? Погляньте на файл PAC

У рядку стану написано «Resolving host in proxy script», але зміна проксі-серверів майже нічого не змінює. Це корисна підказка: можливо, браузер досі вирішує, куди надіслати запит.

Файл PAC може виконувати перевірки, що залежать від DNS. Якщо такі перевірки чекають на недоступний резолвер або раз за разом ставлять зайві запитання, завантаження сторінки може зупинитися ще до того, як вибраний проксі щось отримає.

1. Визначте, де виникає пауза

Для одного ураженого URL з'ясуйте, чи виникає затримка під час отримання файлу PAC, під час його обчислення чи під час підключення до поверненого проксі. Порожній журнал доступу проксі узгоджується з першими двома етапами; він не доводить, що браузер використав прямий маршрут.

Потім перевірте, які правила потребують DNS. Рекомендації Microsoft щодо продуктивності PAC радять уникати зайвої роботи, що залежить від DNS. Перевірка рівності імені хоста не потребує тих самих даних, що й розв'язання цього імені та перевірка підмережі.

2. Приберіть зайву роботу з DNS

Відомі винятки для імен хостів часто можна вирішити до широких перевірок за адресами. Розв'язуйте ім'я лише тоді, коли решта політики справді потребує його адреси. Зберігайте результат у локальній змінній, якщо кільком наступним умовам потрібне те саме значення.

Не «виправляйте» повільний скрипт, додаючи на початку безумовне повернення DIRECT. Це прибирає рішення про маршрутизацію разом із затримкою.

Рішення для DNS, прив'язані до конкретної машини, потребують доказів. Вмикання спільного доступу до файлів або переписування файлу hosts на кожному ноутбуці — погана перша реакція на повільний скрипт маршрутизації. Перевірте поведінку резолвера та імені хоста в ураженій мережі, особливо після зміни мережі, і змінюйте PAC лише там, де цього потребує його реальний шлях прийняття рішень.