This started happening after my company pushed Chrome 68 update (we were using Chrome 65 until then) almost a year back. If I start Chrome up, it runs all well for a while (ranging from 5 minutes to a few hours). Then Chrome stops responding. It won't load any pages. Funny thing is, after that if I try to access Safari, even that stops responding until I restart the system. If I switch back to the Chrome 65, everything starts to work fine.

This is happening with all Chrome versions that have been released ater Chrome 65. I have seen this issue on both High Sierra and Mojave.

My company uses a PAC file for automatic proxy configuration.

  • 1
    Did you reach out to your company's network support yet? Is this a problem only you have, or do coworkers experience the same?
    – nohillside
    Commented Mar 10, 2019 at 15:13
  • Without knowing the contents of the PAC file and the setup of your company's network firewall and filtering setup, it's hard to diagnose. Are you doing specific work for the company through a web portal to services provided by your company, just general web browsing, or a mix of the two? Do you have several portal windows open continually? Is there any correlation you can think of between what you are doing in the browser, and when things come to a grinding halt?
    – IconDaemon
    Commented Mar 10, 2019 at 15:13
  • @nohillside I did. And they don't have a solution yet (Well, the solution is use Chrome 65). And yes, it's happening for all co-workers. Commented Mar 10, 2019 at 18:01
  • You might get better answers or ideas on Google's support site for Chrome.
    – nohillside
    Commented Mar 10, 2019 at 18:08
  • @IconDaemon All that PAC file has are rules to whether return PROXY with proxy server details or DIRECT depending on the hostname that is being tried to access. And it's a mix of everything. We use both intranet and internet sites. I haven't found any pattern as to when it comes to a grinding halt. Commented Mar 10, 2019 at 18:09

1 Answer 1


Google Chrome has stopped supporting PAC files for proxy configuration. The decision is definitive, as explained in this issue comment:

[...] marking this as WontFix to indicate that the deprecation will stick -- we will not be supporting file:// URLs when the Network Service is enabled, and will be deprecating support completely in the future.

The current usage is primarily from file:// URL in system proxy settings, which is an incorrect interpretation of the settings on macOS and Windows.

Instead of file:// URL in system proxy settings, one can set a PAC script from local sources using Chrome's internal proxy settings. The emphasis moving forward will be on exposing a common set of capabilities through Chrome's settings rather than inconsistent capabilities from system proxy settings.

The biggest limitation is that there is currently no UI for managing Chrome's proxy settings (noted in Issue 937413). So one must install a Chrome extension to modify these settings if not using the system proxy settings.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .