Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Firefox still looking for proxy after changing system proxy to None in Linux

  • 12 cavab
  • 2 have this problem
  • 2 views
  • Last reply by Tonnes

more options

I work in an environment where I'm always switching between networks, one with a proxy and one without. I have a script that sets up the system proxy on my CentOS 7 workstation (Gnome 3.14.4) to either None or the URL of the PAC file. In specific situations, that happen frequently to me, Firefox (v.52.2 64-bit ESR) will remember the PAC settings and will give an "Unable to find the proxy server" error until I log out of the Gnome session and log back in with the system proxy set to none.

Steps to reproduce: 1. Connect to a network that has an automatic proxy configuration (PAC file). 2. Configure Firefox to use the system proxy. 2. Log in to Gnome and start Firefox. It will read the PAC file and start to do its thing. 3. Close Firefox and switch networks to one without a proxy server. I do this with gsettings commands in a shell script and verify the configuration in the Network app. 4. Start Firefox back up. It will fail to load up any pages, showing the proxy error instead. The only way to get it working again is to either set the proxy server in Firefox to None or log out of Gnome or log back in.

In my testing, when I set up the system proxy but I wasn't connected to the network to pull the PAC file, Firefox worked fine. Once the PAC file is read, however, Firefox will remember it until either a manual configuration or re-login.

FYI, I also have Chrome running on the same workstation and it doesn't exhibit this problem so I'm sure it's something in Firefox.

Thanks in advance.

I work in an environment where I'm always switching between networks, one with a proxy and one without. I have a script that sets up the system proxy on my CentOS 7 workstation (Gnome 3.14.4) to either None or the URL of the PAC file. In specific situations, that happen frequently to me, Firefox (v.52.2 64-bit ESR) will remember the PAC settings and will give an "Unable to find the proxy server" error until I log out of the Gnome session and log back in with the system proxy set to none. Steps to reproduce: 1. Connect to a network that has an automatic proxy configuration (PAC file). 2. Configure Firefox to use the system proxy. 2. Log in to Gnome and start Firefox. It will read the PAC file and start to do its thing. 3. Close Firefox and switch networks to one without a proxy server. I do this with gsettings commands in a shell script and verify the configuration in the Network app. 4. Start Firefox back up. It will fail to load up any pages, showing the proxy error instead. The only way to get it working again is to either set the proxy server in Firefox to None or log out of Gnome or log back in. In my testing, when I set up the system proxy but I wasn't connected to the network to pull the PAC file, Firefox worked fine. Once the PAC file is read, however, Firefox will remember it until either a manual configuration or re-login. FYI, I also have Chrome running on the same workstation and it doesn't exhibit this problem so I'm sure it's something in Firefox. Thanks in advance.

All Replies (12)

more options

It looks like you are using the Proxy Switcher add-on, so my first question would be: does the same thing happen when uninstalling that add-on, or when starting Firefox in Safe Mode (=ignoring all add-ons)? And, if you change settings using the gsettings commands, why would you need the add-on anyway, perhaps for switching manually?

It would make sense to assume Firefox does not pick up the changes made by the script but uses some cached settings instead, either from itself or from the add-on, so you should check the latter first. You may be able to add the -purgecaches option to start Firefox in order to pinpoint if this is caused by Firefox and work around it (source).

Additionally, this page shows several configuration options related to proxies (such as network.http.proxy.pipelining) that may cause the issue.

Could you report back?

more options

You can also try to toggle Work Offline mode off/on to see if that has effect. For a PAC file there is a Reload button in "Options/Preferences -> Advanced -> Network -> Settings"

more options

Tonnes said

It looks like you are using the Proxy Switcher add-on, so my first question would be: does the same thing happen when uninstalling that add-on, or when starting Firefox in Safe Mode (=ignoring all add-ons)? And, if you change settings using the gsettings commands, why would you need the add-on anyway, perhaps for switching manually? It would make sense to assume Firefox does not pick up the changes made by the script but uses some cached settings instead, either from itself or from the add-on, so you should check the latter first. You may be able to add the -purgecaches option to start Firefox in order to pinpoint if this is caused by Firefox and work around it (source). Additionally, this page shows several configuration options related to proxies (such as network.http.proxy.pipelining) that may cause the issue. Could you report back?

Actually I installed the add-on today after getting fed up with the situation. I'll check the other items and get back to you.

more options

cor-el said

You can also try to toggle Work Offline mode off/on to see if that has effect. For a PAC file there is a Reload button in "Options/Preferences -> Advanced -> Network -> Settings"

When you use the system proxy setting, there is no reload. Remember, I'm not setting up Firefox with the proxy settings.

more options

Tonnes said

Additionally, this page shows several configuration options related to proxies (such as network.http.proxy.pipelining) that may cause the issue. Could you report back?

Tried with and without proxy pipelining. Same problem.

more options

I suggest you try this:

  1. Open Internet connection settings in the OS, set it to use the pac file
  2. Open Firefox, set to use system proxy settings, and to use session restore, and load one or more pages
  3. Switch the OS’es connection settings to None (no proxy)
  4. Reload one or more pages in Firefox

Does the change get picked up immediately? It does for me in Windows, which tells Firefox actually follows them as it should.

Then try the same, but relaunch Firefox after step 3. Do the pages load with an error? Assuming yes (this is your issue), but what happens when refreshing the page using F5, and perhaps (when needed) when pressing Ctrl+F5 (=bypassing cache)?

On my system, I see pages as loaded by the pac script previously, but pressing F5 reloads them properly. This indicates it just loads cached pages at startup.

The way to avoid that is to toggle browser.cache.disk.enable to false. Can you try that? It may also be required to do the same for browser.cache.memory.enable.

more options

Tonnes said

I suggest you try this:
  1. Open Internet connection settings in the OS, set it to use the pac file
  2. Open Firefox, set to use system proxy settings, and to use session restore, and load one or more pages
  3. Switch the OS’es connection settings to None (no proxy)
  4. Reload one or more pages in Firefox
Does the change get picked up immediately? It does for me in Windows, which tells Firefox actually follows them as it should.

If I refresh a page with Ctrl-F5, I get "Unable to find the proxy server," meaning that FF isn't reloading the information from Gnome (or is getting back the wrong information).

Then try the same, but relaunch Firefox after step 3. Do the pages load with an error? Assuming yes (this is your issue), but what happens when refreshing the page using F5, and perhaps (when needed) when pressing Ctrl+F5 (=bypassing cache)?

Same result as above.

What's troubling is that even restarting FF doesn't help, only changing the browser setting to "None" or re-login to Gnome.

The same set of tests with Chrome work correctly but I'm not required nor have the desire to use it. FF is my daily driver, has been since v.1.0, and I'd like to keep it that way.

Thanks for your help but it seems this is a Linux specific problem.

more options

sregev said

Tonnes said
I suggest you try this:
  1. Open Internet connection settings in the OS, set it to use the pac file
  2. Open Firefox, set to use system proxy settings, and to use session restore, and load one or more pages
  3. Switch the OS’es connection settings to None (no proxy)
  4. Reload one or more pages in Firefox
Does the change get picked up immediately? It does for me in Windows, which tells Firefox actually follows them as it should.

If I refresh a page with Ctrl-F5, I get "Unable to find the proxy server," meaning that FF isn't reloading the information from Gnome (or is getting back the wrong information).

That’s interesting. Sorry for asking again, but this is important info. Are you saying that when only changing the connection setting in the OS’s connection dialog in step 3 - so not by your script - does not affect Firefox at all, i.e. reloading a page in step 4 without leaving Firefox - either by F5 or ctrl+F5 - makes it still wants to connect to the proxy? Additionally and if so, does the exact same thing happen with the 2 cache related prefs set to false in this scenario?

I find it hard to believe that this would be Linux-only issue, though there have been bugs with regard to Gnome and proxies in the past so I can imagine the proxy mechanism to work in a slightly different way for Gnome, also when looking at some previous bugs such as this one. By the way, is there any proxy authentication involved?

I must say I tested with Firefox Nightly AND my proxy (pointed to in the system’s pac file) was still accessible, but the same happened when testing in FF 54 release and when changing the pac script to use an inaccessible proxy as part of step 3. Interestingly perhaps, when only changing the pac file to use an inaccessible proxy, Firefox requires a restart or change in its preferences (e.g. to None and back, as if it could use a Reload button too) in order to discover the proxy is not accessible, so then it acts like at your end. But then again, it does respect an OS’es connection settings change in Windows(7) right away. It seems obvious that does not happen for you, i.e. it still uses cached settings as defined by the pac file.

Could you please answer the above questions, and also have a look at this bug reported recently to see if you think this is the issue described? The behavior described there appears to be very similar and despite being filed for Mac and 53, it could very well affect Linux too and have been an issue before.

What I think is also interesting is the bug confirmation for Windows 10 and 7, but it could be because the OS’s pac setting itself may not have been changed, only the network connection itself.

With regard to the reported version: do you know of a previous Firefox version that did not suffer the issue, and are you willing to test any older Firefox version by using a zip build for instance (in order to do test quickly without reinstalls)? Of course you are also welcome to add your comment in the bug and vote for it if you think it’s applicable.

more options

Sorry for the delay, here are the answers to your questions.

Tonnes said

Are you saying that when only changing the connection setting in the OS’s connection dialog in step 3 - so not by your script - does not affect Firefox at all, i.e. reloading a page in step 4 without leaving Firefox - either by F5 or ctrl+F5 - makes it still wants to connect to the proxy? Additionally and if so, does the exact same thing happen with the 2 cache related prefs set to false in this scenario?

That's what I'm saying. Firefox will continue to try to use the proxy until I log out of Gnome and log back in.

By the way, is there any proxy authentication involved?

No proxy authentication.

and also have a look at this bug reported recently to see if you think this is the issue described? The behavior described there appears to be very similar and despite being filed for Mac and 53, it could very well affect Linux too and have been an issue before.

This bug is very similar but restarting Firefox caused it to re-read the system proxy setting and that fixed it. In my case, restarting Firefox does not help. Only logging out of Gnome and logging back in forced Firefox to use the correct setting.

With regard to the reported version: do you know of a previous Firefox version that did not suffer the issue, and are you willing to test any older Firefox version by using a zip build for instance (in order to do test quickly without reinstalls)?

I haven't tried older versions under CentOS but I'd like to get to the bottom of the issue.

To add more confusion to the mix, I performed the same tests in a fully updated Ubuntu 16.04.2, with the same Firefox version, and the problem did not occur. But remember that under CentOS, Chrome doesn't exhibit this problem at all. So it might also be a problem in Gnome as well as Firefox, something that I suspected initially since logging out and back in caused Firefox to use the correct setting.

more options

Thanks for your feedback.

I’m not a real expert on this, but understand Firefox should use the Gnome proxy settings whereas other (command line) applications may look for environment variables, or at least other ones. Now I don’t know how your script works, but perhaps it modifies CentOS’s proxy settings, but just not the (or all) Gnome settings/variables that should be inherited from them? Logging out and back to Gnome may cause Gnome to re-read these higher privileged CentOS settings. That would also explain why the Ubuntu setup does not suffer the issue.

This thought came up when reading this, this, this (look for "issue", pointing to an old bug), this (note "Gnome3") and this page.

So in short: perhaps you need to modify your script a bit so that one or more variables used by Gnome are adapted as well, not just the ones for CentOS? I can’t tell which files and variables to modify/add exactly but assume you can find out. It should be as easy as checking which ones have changed after a new login and make the script do the same.

more options

Thanks for the suggestion. My script already makes all the relevant changes to the environment, yum, git, applications, you name it. That's why I put it in a script. The fact that Firefox is the only application that has trouble with the system configuration when changing proxy settings makes me think that the problem is the browser and not the environment.

With all due respect to Windows, it behaves nothing like Linux, which vary between distributions. Is there any way someone familiar with the way Firefox accesses the system proxy settings in Linux can chime in with their suggestions?

more options

I trust your script to be OK then. One thing that I’m not sure of is whether Firefox "caches" proxy settings or its required variables returned by "Use system proxy settings", even though it is set to use them and so expected to follow connection changes instantly. But knowing the issue does not occur in Gnome on Ubuntu for you, I doubt if this is a general Linux issue or related to CentOS, or some distro.

Perhaps you could add your comment to the bug, slightly describing your specific issue or by pointing to this question?

Remember that bug is not filed for Windows - Mac and Linux apparently differ slightly with regard to behavior (according to the bug), and a commenter experiences this using a VPN, though not with CentOS, and regardless of a Firefox restart "fixing" this either on Windows or Mac. Some developers may see your issue as a separate one, but I think this could be fixed by that bug in general, i.e. for any setup or OS. If not, at least some discussion would come up and a specific and related bug could be filed from there.

Come to think of it now, I presume you also tested with Firefox set to use the pac file by itself instead of via the OS, and altering the script? And the same for manual proxy settings perhaps? You could also check what the Reload button does for the first option. I understand this is not how you would like your setup/script to be, but it would be for testing only to see where this fails, so it can be useful info for developers in a bug too.

Finally, don’t forget to test for reproduction of the issue without any add-ons (as opposed to disabling them only manually or by Safe Mode), and to make sure there is no user.js file involved. There have been reports of add-ons that do not get disabled entirely (see here), so the best would be to create a separate profile for it without any modifications and add-ons.