Заседнали на „Resolving Host in Proxy Script“? Погледнете PAC файла

Съобщението за състояние казва „Resolving host in proxy script“, но смяната на прокси сървъри почти не променя нищо. Това е полезна улика: браузърът може все още да решава накъде да изпрати заявката.

PAC файлът може да извършва проверки, зависещи от DNS. Ако тези проверки чакат недостъпен resolver или многократно задават ненужни въпроси, зареждането на страницата може да спре, преди избраният прокси да получи каквото и да е.

1. Открийте къде е паузата

За един засегнат URL установете дали забавянето настъпва при изтегляне на PAC файла, при оценяването му или при свързване с върнатия прокси. Празен лог за достъп през прокси е съвместим с първите два етапа; той не доказва, че браузърът е използвал директен маршрут.

След това проверете кои правила изискват DNS. Указанията на Microsoft за производителност на PAC препоръчват избягване на ненужна работа, зависима от DNS. Проверката за равенство на име на хост не се нуждае от същата информация като разрешаването на това име и проверка на подмрежа.

2. Премахнете ненужната работа с DNS

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

Не „поправяйте“ бавен скрипт, като добавите безусловно връщане DIRECT в началото. Това премахва решението за маршрутизиране заедно със забавянето.

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