WPAD Resolves, but the Browser Gets a 404
Automatic proxy discovery can find the right server and still request a PAC file from the wrong virtual host or path.
The name wpad resolves to the expected machine. That is encouraging, but it is only the beginning. The browser still has to request a file from that machine and receive the PAC script.
A useful clue can be found in the web server's access log: the client requested /wpad.dat and received HTTP 404. A manually opened PAC URL can use a different hostname. Even when both names reach the same server, they may select different virtual hosts.
Follow the request the client made
Check the exact URL selected by discovery, the HTTP Host value, the path, and the response. Opening a convenient PAC URL in an ordinary browser tab does not establish that automatic discovery requested that URL.
If short and fully qualified names are both expected, configure the intended web host to handle those names deliberately. Confirm that /wpad.dat maps to the correct file, rather than to a default document root or an unrelated application.
Serve a script, not an error page
Verify the response body as well as its status. A sign-in page, branded error document, or redirect can look plausible when viewed manually but is not the PAC script the resolver expects. Chromium documents strict PAC-download requirements, including an HTTP 200 response.
Only after delivery succeeds does it make sense to debug FindProxyForURL(). Changing its hostname rules cannot repair a 404 that prevented the browser from obtaining it.
Also distinguish a PAC web server from the forward proxy named inside its script. They may share a machine, but an access-log entry on one service is not evidence that the other service handled the user's destination request.