This is now expected, as you point out.  You can use the new rule "<-loopback>", though that only works with proxy bypass rules, not PAC scripts, unfortunately.  The rule was added to address security concerns of remote attackers hijacking localhost requests, which are normally considered secure.  I defer to eroman if we want to add a way to bypass this through local configuration or group policy.

Forgot to update the component...

If it's to address a security concern, why are PAC scripts being singled out? Someone can just as easily proxy traffic via HTTP/HTTPS proxy settings in the system. 

Proxy rules have to be enabled, and are configured locally, or via group policy - we're also mirroring Window's proxy rule behavior, which doesn't proxy localhost by default, but also has an opt-out.  PAC scripts configured through WPAD or DHCP are enabled by default on Windows, so there's no affirmative signal there that "Yes, this is a trusted script, and should be able to override the behavior for localhost URLs".

Thanks for the report!

Unfortunately this is expected fall-out from the change you correctly identified in comment #0.

Following that change, there is no longer a way to choose the proxy for localhost (or link-local) URLs via a PAC script. In this regard, Chrome now behaves like Edge and Safari, which also bypass PAC for localhost

As far as work-arounds for your use-case, there are a few imperfect translations.

(1) Use manual proxy settings rather than a PAC script. Depending on the logic in your PAC file, an exact translation may not be possible:

  --proxy-server="http://127.0.0.1:5010" --proxy-bypass-list="<-loopback>"

(2) Access the URLs via a non-localhost address. This would entail changing the URL that you are navigating from say "http://localhost/" to maybe "http://localhost.test". You could then remap "localhost.test" to resolving to 127.0.0.1 globally (/etc/hosts), or just in Chrome with:

  --host-resolver-rules='MAP localhost.test 127.0.0.1'

The downside with this approach is that from the perspective of the web platform, http://localhost.test/ will not longer have the extra privileges that http://localhost/ did (http://loclahost/ is considered a secure origin).


If going with option (1), be aware that on macOS you cannot specify <-loopback> in the network preferences (it gets normalized to "loopback>". If you want to specify a localhost bypass via system settings a minimal set of rules you can use instead is: "localhost, 127.0.0.1/8, ::1".



Assigning to me to follow-through as we get more feedback from M71. I don't have any current plans to poke holes in the policy for this use case given it is not a cross-browser idiom, but we could explore a Chrome-only solution if there is a need.

 Issue 913950  has been merged into this issue.