I’ve written about Browser Proxy Configuration a few times over the years, and I’m delighted that Chromium has accurate & up-to-date documentation for its proxy support.
One thing I’d like to call out is that Microsoft Edge’s new Chromium foundation introduces a convenient new debugging feature for debugging the behavior of Proxy AutoConfiguration (PAC) scripts.
To use it, simply add alert() calls to your PAC script, like so:
alert("!!!!!!!!! PAC script start parse !!!!!!!!");
function FindProxyForURL(url, host) {
alert("Got request for (" + url+ " with host: " + host + ")");
return "PROXY 127.0.0.1:8888";
}
alert("!!!!!!!!! PAC script done parse !!!!!!!!");
Then, collect a NetLog trace from the browser:
msedge.exe --log-net-log=C:\temp\logFull.json --net-log-capture-mode=IncludeSocketBytes
…and reproduce the problem.
Save the NetLog JSON file and reload it into the NetLog viewer. Search in the Events tab for PAC_JAVASCRIPT_ALERT
events:

Even without adding new alert()
calls, you can also look for HTTP_STREAM_JOB_CONTROLLER_PROXY_SERVER_RESOLVED
events to see what proxy the proxy resolution process determined should be used.
One current limitation of the current logging is that if the V8 Proxy Resolver process…

… crashes (e.g. because Citrix injected a DLL into it), there’s no mention of that crash in the NetLog; it will just show DIRECT
. Until the logging is enhanced, users can hit SHIFT+ESC
to launch the browser’s task manager and check to see whether the utility process is alive.
Try using the System Resolver
In some cases (e.g. when using DirectAccess), you might want to try using Windows’ proxy resolution code rather than the code within Chromium.
The --winhttp-proxy-resolver
command line argument will direct Chrome/Edge to call out to Windows’ WinHTTP Proxy Service for PAC processing.
Differences in WPAD/PAC Processing
- The WinHTTP Proxy Service caches proxy authentication credentials (in CredMan) and automatically reuses them across apps and browser launches; Chromium does not.
- The WinHTTP Proxy Service caches WPAD determination across process launches. Chromium does not and will need to redetect the proxy each time the browser reopens.
- Internet Explorer/WinINET/Edge Legacy call the PAC script’s FindProxyForURLEx function (introduced to unlock IPv6 support), if present, and FindProxyForURL if not.
- Chrome/Edge/Firefox only call the FindProxyForURL function and do not call the Ex version.
- Internet Explorer/WinINET/Edge Legacy expose a getClientVersion API that is not defined in other PAC environments.
- Chrome/Edge may return different results than IE/WinINET/EdgeLegacy from the myIpAddress function when connected to a VPN.
- Edge 79+/Chrome do not allow loading a PAC script from a file:// URI. (IE allowed this long ago, but it hasn’t been supported in a long time). If you want to try testing a PAC script locally in Chromium-based browsers, you can encode the whole script into a DATA URL and use that. IE/Edge Legacy do not support this mechanism.
Notes for Other Browsers
- Prior to Windows 8, IE showed PAC alert() notices in a modal dialog box. It no longer does so and alert() is a no-op.
- Firefox shows alert() messages in the Browser Console (hit Ctrl+Shift+J); note that Firefox’s Browser Console is not the Web Console where web pages’ console.log statements are shown.
-Eric
Timely article, working on a PAC revamp at the moment.
I used to debug with Alert on Internet Explorer and it was… super unpleasant, as it produced a modal “OK” dialog box at each step.
Will the technique above produce popup messages on non-Chrome browsers, or do browsers mostly suppress this type of alerting from PACs now?
I think modals are largely gone here at this point. Firefox dumps PAC alert strings to the console, and Win8 stopped showing the alerts for IE. https://stackoverflow.com/questions/1033867/debugging-autoproxy-pac-javascript-with-alert