I frequently move my laptop (OSX) between different wifi areas, but my home base has an ethernet connection and relies on my organisation's proxy.pac file. When reconnecting after a stint on the road, I often get a problem where pages simply don't load in Chrome or Firefox. They just eventually time out. I think this is related to the fact that the proxy requires username and password - perhaps it just discards unauthenticated requests or something.

I discovered by trial and error that in FireFox, if I go to the proxy settings, and press "reload" on the proxy configuration, then the problem goes away. Eventually Chrome will pop up the proxy authentication dialog, but it can be hard to see (usually comes up in the wrong Spaces window, sometimes disappears straight away, can be buried under other application windows etc).

So my question is: how can I tell Chrome to reload the proxy.pac file, since that works for Firefox? (I thought I had solved the problem by saving the proxy.pac file locally, but apparently not).

  • I'd also be interested to hear of diagnostic tools that would help understand what's going on. Oct 6 '11 at 0:34
  • It looks like the actual cause of the problem might be this: code.google.com/p/chromium/issues/detail?id=85529 Chrome is rejecting a perfectly decent proxy, probably because the proxy is rejecting certain non-standard requests (like the google profile sync in the bug report). Oct 17 '11 at 1:23

Welcome to the world of fun that is Proxy Auto-Configuration files (and indeed Google Chrome)!

You haven't seen anything, yet. Include more than just Chrome and Firefox in the mixture of WWW browsers, and one is in for a world of difficulty. (I recently tried to diagnose why a PAC file was causing RealPlayer to lose the ability to resolve any domain names at all.)

Useful diagnosis tools, where "useful" incorporates "I've used them myself to diagnose problems.", include Chrome's JavaScript console and debug logging function. I diagnosed a syntax error in a fairly large PAC file with that, once. The Chromium "Net Internals" proxy configuration reporting page (whose URL SuperUser doesn't allow as a hyperlink), and its initialization reporting counterpart (likewise), are also useful:


Yes, it is quite difficult to persuade Chrome to re-load a PAC file afresh. Chrome has had a fairly troubled history when it comes to proxy settings. One way to do it that is fairly reliable is to completely turn off all proxy settings in the system settings dialogue (and save that change, of course), wait for a minute, then turn them back on again. But in the past (with earlier versions) I have had to completely exit and restart Chrome. In part this is because Chrome works by polling for changes to the system settings every 10 or so seconds in the background when it is otherwise idle.

In Chrome's bug database you'll find that the request to allow run-time switchable Chrome-specific proxy settings like other WWW browsers have, which relates to your problem, languished for three years and was closed as "We won't fix this.", although there's now supposedly an extension (and a set of command-line options that are, of course, not run-time switchable).

As you've observed, Firefox has a simple "Reload" button. As you can see by reading the three years of bug discussion, this is an area where people are quite unhappy about how feature-poor and quirky Chrome is compared to Firefox.

Note that this might not be the root cause of your underlying problem, but since you haven't asked about that, let alone provided anywhere near enough details of it, I'm not going to address it. ☺

  • Wow, great answer. And correct, I wasn't asking about any underlying problem. Fixing the symptoms would fix my problem. Given how interchangeable browsers are these days, it's a very surprising experience when one browser is happily connecting to any site, and the other spins its wheels - both with identical proxy settings. This gives me something to work with. Oct 14 '11 at 5:57
  • Ah-ha! One interesting thing from proxyservice.config: my (required) proxy was marked as "bad". I'm guessing Chrome tried to access it while the network connection was in a state of flux, then marked it as bad when it failed. So then it tries to access the web with no proxy - which my network won't allow. Fortunately there is a button clear the table of "bad" proxies, so there is a way out. Oct 17 '11 at 1:01
  • Thanks for those two diagnostic screens. Chrome and proxies were a PITA to diagnose. Much easier now.
    – mr-euro
    Jan 11 '12 at 13:24

In Chrome 29.x, there is now a URL chrome://net-internals/#proxy which has a "Re-apply settings" button.

It reloads the proxy settings, e.g. from a PAC script.

The documentation also lists command line options to override the proxy settings.

  • Interesting. It's been a while since I had the situation originally described, so I can't really test, but it sounds plausible. Aug 29 '13 at 5:45
  • 1
    I can confirm that it does reload the proxy settings. Thank you :). Mar 10 '15 at 11:24
  • This worked for me as well. May 28 '15 at 21:43

Closing and opening Chrome might do it, but Chrome uses the system proxy so perhaps not.

If I were you, I would open up the proxy.pac, and see what it is doing, then set up a proxy profile that you would enable at work and disable otherwise, that matches the proxy.pac.

You could use something like proxy switcher to manage it.

  • Thanks, I'm giving that strategy a go at the moment. It's actually a pretty complex file, but seems to boil down to "don't use the proxy for the following 100+ domains". Oct 6 '11 at 0:58
  • Ah yeah, so all the internal stuff, don't use a proxy. You could be a bit selective if you don't use services on all the 100+ domains. Just add excemptions for the ones you need.
    – Paul
    Oct 6 '11 at 1:01
  • Actually I got that wrong. It does use the proxy for lots of domain. The default behaviour appears to be: return "PROXY ; DIRECT"; (tab character before the semicolon). I don't get it. Oct 6 '11 at 1:07
  • There should be something after the word "PROXY" and before the semi-colon. This is a list of proxy server normally, and are supposed to be accessed in sequence if any are uncontactable. The last in the list is "DIRECT" which means, you can't get to any preceding proxies, then try going direct to the website.
    – Paul
    Oct 6 '11 at 1:18
  • whoops, looks like I temporarily mangled the file, deleting the actual proxy location from that line. Meanwhile it looks like I sort of have a way to force Chrome to reload the proxy settings, by clearing that box, saving settings, then filling it in again...but still not sure it's reliable. Oct 6 '11 at 1:21

Ran into this doing some local development, saw it was due to am extension being installed by corp that was managing the proxy. Incognito mode bypasses and I could connect to my local web server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.