WPAD is checked first, however if a response is not determined quickly enough will pick DNS.

Can you provide a network dump showing what happens when you click reapply settings?

https://dev.chromium.org/for-testers/providing-network-details

> WPAD is checked first,

I mean DHCP

please see attached, IP addresses obfuscated and dns names changed

sorry forgot to attach

Deleted: chrome-net-export-log.json 300 KB

chrome-net-export-log.json 300 KB View Download

Tested the issue on windows 7 & 10 using chrome M62 #62.0.3202.62 andfollowed steps mentioned in comment  #0.

Observed as attched in screencast.

@andrewmatheson-- Could you please check attached screencast and let us know if this is the issue or if we have missed any steps in reproduing the issue . Also help us with the expected and actual result for better understanding.

Thanks!

Deleted: 771914.mp4 277 KB

	771914.mp4 277 KB View Download

The log in comment #5 shows DHCP's PAC script as having been selected.

We will need to see a log where DNS was selected to confirm it is a timeout problem.

Does this only happen at first launch of Chrome?

Hi,

This happens randomly, can be once a day or multiple times a day.

When you click reapply settings it applies the correct proxy.

I’ve seen it as well when a machine returns from a suspended state or moves from wired to wireless and vice Versa.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

When changing networks (or returning from suspended state), the problem is probably one of time to initialize. Chrome interrogates WPAD shortly after these transitions (2 seconds), and the imposes another timeout of 2 seconds. Could be this is insufficient for your setup.

Can you simply align the DNS and DHCP based PAC advertisements? The behavior on such an environment is going to be somewhat unpredictable regardless, since not all clients even check DHCP PAC, and moreover there is no specification for how user agents prioritize them.

It could be possible to add additional listeners for network state to Chrome to try DHCP WPAD at different intervals, or try and properly detect the edges when it is ready. But honestly the code around this is already overly complicated, I am inclined to say this should be fixed in the environment instead.

Lastly note that barring network change events and failures in fetching PAC scripts, Chrome will re-test auto-detect every 12 hours (which can also explain why it seems flaky, since at each one of these re-configurations it might ping-pong between the DHCP and DNS versions of the script).

Thanks for all the data!

Thanks for getting back.

The problem is that this is a multinational Corp with multiple sites and local break outs so individualized PAC files are required for each site otherwise we have latency and availability issues