Chrome 72+ seems to no longer accept --proxy-pac-url

I have an shortcut on several Windows PCs that points to Chrome with --proxy-pac-url.

Full Target: field in shortcut properties looks like this:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --proxy-pac-url=file://C:/Local/Drive/Path/To/proxy.pac

One PC is always on and didn't restart Chrome in a long time. It still runs Chrome 71. On this PC .pac still works and I can access dynamically proxified resources. On the rest, where Chrome was updated to 72 and restarted it no longer works - Chrome tries to access resource directly and fails. Additionally, I can't debug it, since chrome://net-internals/#proxy shows is empty of any info save for re-apply/clear buttons.

So, what broke, how can I debug this and how to make a specific instance of Chrome run with specific .pac once again? Without always swapping options by hand, of course.

Oleg V. Volkov

Posted 2019-02-14T00:40:54.363

Reputation: 597

Answers

Chrome 72-75:

As suggested in this bug report, you can disable 'Enable Network Service' in chrome://flags to go back to the old behaviour that supports file:// pac files. Starting Chrome from the command-line with --disable-features=NetworkService has the same effect.

Chrome 76:

It seems that the 'Network Service' option has been removed from chrome://flags (see the code commit).

You can still run Chrome with --disable-features=NetworkService (ref) (e.g. /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-features=NetworkService on a Mac), and it seems to read the PAC file ok, though there might be some issues (because lots of related code seems to have been deleted already - see this issue - I guess YMMV, and this won't be a long-term solution.

As suggested in the bug report, you are probably better either installing a browser plugin that lets you define PAC settings, or use an http(s) PAC file.

paulcm

Posted 2019-02-14T00:40:54.363

Reputation: 146

1Note that even --disable-features=NetworkService is only a temporary fix; from the linked bug, "we will not be supporting file:// URLs when the Network Service is enabled, and will be deprecating support completely in the future." – Conrad Meyer – 2019-10-01T23:21:06.877

Chrome removed almost all functionality of net-internals for some reason and it sounds like they removed the pac flag that you were using.

chromium docs link to this site that still lists the flag as valid.

https://peter.sh/experiments/chromium-command-line-switches/

Spyderz

Posted 2019-02-14T00:40:54.363

Reputation: 71

Here's the related Chromium issue where file:// PAC files were removed: https://bugs.chromium.org/p/chromium/issues/detail?id=839566&q=pac&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

– paulcm – 2019-02-18T12:45:20.177

6Also, as suggested in the bug, you can also disable 'Enable Network Service' in chrome://flags to go back to the old behaviour that supports file:// pac files, though that will also be removed in future. Starting Chrome like /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-features=NetworkService has the same effect. – paulcm – 2019-02-18T14:05:24.917

2@paulcm that should be an answer. – Oleg V. Volkov – 2019-02-18T15:32:56.357

Unfortunately, Chrome plans to remove --disable-features=NetworkService and support for file:/// PAC URLs entirely in the future.

Here's the upstream bug (and specifically the comment marking WONTFIX): https://bugs.chromium.org/p/chromium/issues/detail?id=839566#c40

The solution that should work on Chrome 76+, without requiring an httpd, is to take the .zip file attached to that comment, unpack it somewhere permanent, and modify the bundled my_pac_script.js to be a symlink to your previous file:///... PAC file. Then install the extension in Chrome. It will load the PAC configuration when Chrome is started.

Conrad Meyer

Posted 2019-02-14T00:40:54.363

Reputation: 126