Vasgehaak op “Resolving Host in Proxy Script”? Kyk na die PAC-lêer

Die statusboodskap sê “Resolving host in proxy script,” maar om proxbedieners te verander maak min verskil. Dit is 'n nuttige leidraad: die blaaier is dalk steeds besig om te besluit waarheen om die versoek te stuur.

'n PAC-lêer kan DNS-afhanklike kontroles uitvoer. As daardie kontroles wag op 'n onbereikbare resolver of herhaaldelik onnodige vrae vra, kan bladsylaai pouse voordat die gekose proxy enigiets ontvang.

1. Bepaal waar die pouse is

Vir een geaffekteerde URL, bepaal of die vertraging plaasvind tydens die haal van die PAC-lêer, die evaluering daarvan, of die verbinding aan die teruggekeerde proxy. 'n Leë proxy-toegangslog stem ooreen met die eerste twee fases; dit bewys nie dat die blaaier 'n direkte roete gebruik het nie.

Ondersoek dan watter reëls DNS nodig het. Microsoft se PAC-prestasieriglyne beveel aan om onnodige DNS-afhanklike werk te vermy. 'n Gelykheidskontrole van gasheername benodig nie dieselfde inligting as om daardie gasheernaam op te los en 'n subnet te kontroleer nie.

2. Verwyder onnodige DNS-werk

Bekende gasheernaam-uitsonderings kan dikwels voor breë adresgebaseerde kontroles besluit word. Los 'n naam slegs op wanneer die oorblywende beleid werklik sy adres benodig. Hou die resultaat in 'n plaaslike veranderlike as verskeie daaropvolgende voorwaardes dieselfde waarde nodig het.

Moenie 'n stadige skrip “regmaak” deur 'n onvoorwaardelike DIRECT-terugkeer boaan te voeg nie. Dit verwyder die roetebesluit saam met die vertraging.

Masjien-spesifieke DNS-werkarounds het bewyse nodig. Om lêerdeling te aktiveer of elke skootrekenaar se hosts-lêer te herskryf is 'n swak eerste reaksie op 'n stadige roeteskrip. Kontroleer die resolver en gasheernaamgedrag op die geaffekteerde netwerk, veral ná 'n netwerkverandering, en verander die PAC slegs waar sy werklike besluitpad dit vereis.