De statusmelding zegt ‘Resolving host in proxy script’, maar een andere proxyserver lost weinig op. Dat is een nuttige aanwijzing: de browser bepaalt mogelijk nog waar het verzoek naartoe gaat.

Een PAC-bestand kan DNS-afhankelijke controles uitvoeren. Als die controles wachten op een onbereikbare resolver of steeds onnodige vragen stellen, kan het laden van de pagina stokken voordat de gekozen proxy iets ontvangt.

1. Bepaal waar de pauze zit

Stel voor één getroffen URL vast of de vertraging optreedt bij het ophalen van het PAC-bestand, bij het evalueren ervan of bij het verbinden met de teruggegeven proxy. Een leeg proxy-toegangslog past bij de eerste twee fasen; het bewijst niet dat de browser een directe route gebruikte.

Controleer daarna welke regels DNS nodig hebben. Microsofts richtlijnen voor PAC-prestaties raden aan onnodig DNS-afhankelijk werk te vermijden. Een gelijkheidscontrole van een hostnaam heeft niet dezelfde informatie nodig als het opzoeken van die hostnaam en het controleren van een subnet.

2. Verwijder onnodig DNS-werk

Bekende uitzonderingen op hostnamen kunnen vaak worden beslist vóór brede controles op basis van adressen. Los een naam alleen op wanneer het resterende beleid echt het adres nodig heeft. Bewaar het resultaat in een lokale variabele als meerdere volgende voorwaarden dezelfde waarde nodig hebben.

‘Repareer’ een traag script niet door bovenaan een onvoorwaardelijke DIRECT-return toe te voegen. Dat haalt de routingbeslissing samen met de vertraging weg.

Machinespecifieke DNS-oplossingen vereisen bewijs. Bestand delen inschakelen of het hosts-bestand van elke laptop herschrijven is een slechte eerste reactie op een traag routingscript. Controleer het gedrag van de resolver en de hostnaam op het getroffen netwerk, vooral na een netwerkwijziging, en wijzig de PAC alleen waar het werkelijke beslispad dat vereist.

Gerelateerde artikelen