В строке состояния написано «Resolving host in proxy script», но смена прокси-серверов почти ничего не меняет. Это полезная подсказка: возможно, браузер всё ещё решает, куда отправить запрос.

Файл PAC может выполнять проверки, зависящие от DNS. Если такие проверки ждут недоступный резолвер или раз за разом задают лишние вопросы, загрузка страницы может остановиться ещё до того, как выбранный прокси что-либо получит.

1. Определите, где возникает пауза

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

Затем проверьте, какие правила нуждаются в DNS. Рекомендации Microsoft по производительности PAC советуют избегать лишней работы, зависящей от DNS. Проверка равенства имени хоста не требует тех же сведений, что разрешение этого имени и проверка подсети.

2. Уберите лишнюю работу с DNS

Известные исключения для имён хостов часто можно решить до широких проверок по адресам. Разрешайте имя только тогда, когда оставшаяся политика действительно требует его адреса. Сохраняйте результат в локальной переменной, если нескольким последующим условиям нужно одно и то же значение.

Не «исправляйте» медленный скрипт, добавляя в начало безусловный возврат DIRECT. Это убирает решение о маршрутизации вместе с задержкой.

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

Похожие статьи