Stuck on “Resolving Host in Proxy Script”? Look at the PAC File

The status message says “Resolving host in proxy script,” yet changing proxy servers makes little difference. That is a useful clue: the browser may still be deciding where to send the request.

A PAC file can perform DNS-dependent checks. If those checks wait for an unreachable resolver or repeatedly ask unnecessary questions, page loading can pause before the selected proxy receives anything.

1. Locate the pause

For one affected URL, establish whether the delay occurs while fetching the PAC file, evaluating it, or connecting to the returned proxy. An empty proxy access log is consistent with the first two stages; it does not prove that the browser used a direct route.

Then inspect which rules need DNS. Microsoft's PAC performance guidance recommends avoiding unnecessary DNS-dependent work. A hostname equality check does not need the same information as resolving that hostname and checking a subnet.

2. Remove unnecessary DNS work

Known hostname exceptions can often be decided before broad address-based checks. Resolve a name only when the remaining policy actually requires its address. Keep the result in a local variable if several subsequent conditions need the same value.

Do not “fix” a slow script by adding an unconditional DIRECT return at the top. That removes the routing decision along with the delay.

Machine-specific DNS workarounds need evidence. Enabling file sharing or rewriting every laptop's hosts file is a poor first response to a slow routing script. Check the resolver and hostname behavior on the affected network, especially after a network change, and change the PAC only where its actual decision path calls for it.