Statusmeddelandet säger ”Resolving host in proxy script”, men att byta proxyserver gör liten skillnad. Det är en användbar ledtråd: webbläsaren kanske fortfarande avgör vart begäran ska skickas.

En PAC-fil kan utföra DNS-beroende kontroller. Om dessa kontroller väntar på en otillgänglig resolver eller gång på gång ställer onödiga frågor kan sidladdningen stanna innan den valda proxyn tar emot något.

1. Hitta pausen

För en drabbad URL, fastställ om fördröjningen uppstår när PAC-filen hämtas, när den utvärderas eller när anslutningen till den returnerade proxyn görs. En tom proxy-åtkomstlogg stämmer med de två första stegen; den bevisar inte att webbläsaren använde en direkt väg.

Undersök sedan vilka regler som behöver DNS. Microsofts riktlinjer för PAC-prestanda rekommenderar att onödigt DNS-beroende arbete undviks. En likhetskontroll av värdnamn behöver inte samma information som att slå upp värdnamnet och kontrollera ett subnät.

2. Ta bort onödigt DNS-arbete

Kända undantag för värdnamn kan ofta avgöras före breda adressbaserade kontroller. Slå bara upp ett namn när den återstående policyn verkligen behöver dess adress. Spara resultatet i en lokal variabel om flera följande villkor behöver samma värde.

”Reparera” inte ett långsamt skript genom att lägga till en ovillkorlig DIRECT-retur högst upp. Det tar bort routingbeslutet tillsammans med fördröjningen.

Maskinspecifika DNS-lösningar kräver bevis. Att aktivera fildelning eller skriva om hosts-filen på varje bärbar dator är en dålig första reaktion på ett långsamt routningsskript. Kontrollera resolver- och värdnamnsbeteende i det drabbade nätverket, särskilt efter en nätverksändring, och ändra PAC:en bara där dess faktiska beslutsväg kräver det.

Relaterade artiklar