Proxy problem after upgrade to core 155 - The proxy server is refusing connections

I am using non-transparent proxy on Green and I am using the default port 800. I have not seen any problems since I updated to Core Update 155.

I just rebooted and the Proxy Server was still running and working afterwards.

1 Like

I also have strange problems with my proxy after updating to 155. Changed the port to 8001 and that solved it, until today. changed it back to 800 and it works again. So maybe restarting the proxy fixes it and not setting a specific port nr.

I too have had the same thing happening at multiple locations. Each firewall after a reboot require a restart of the proxy or as ive tested even as little as clicking “clear cache” in the web gui resets the proxy to work on port 800.
I tested other sites which I have yet to reboot since the initial after update reboot and cache flush run fine until until they get rebooted of course, same goes for them with something as simple as clear cache, or restart proxy via the web gui.
so thats batting 1000 so far on all that updated to 155 using default port 800, 11 so far.

Please follow the guidance given in the linked post below for registering the problems you are experiencing as a bug.

1 Like

Thanks that fixed it.

I still have the problem over port 800 after updating to 156. Do you have other experiences?

idem for me.
No solution.
Only reboot Squid/Proxy

I thought the problem should be fixed with update 156

Well that would have required someone having the problem to raise a bug as was suggested in post 10 of this thread.

I have had a look in bugzilla and there is no bug entry on this topic since 12th April.

The core devs are a small team of people and they are very busy. Things that are raised as formal bugs in bugzilla will get reviewed and if confirmed as an issue with IPFire will get assigned to be fixed.


Since it is not only me with the problem I submited a bug report:

1 Like

Hi to everyone,
i’m getting this issue after upgrade to 157.

Ipfire before was 155 and everything worked fine (squid service too).

i have tried to enable log management in Proxy configuration and it works.

In my case (with 157) if that option is enabled, the proxy service start correctly with reboot.
Telnet gives me access on 800 port.

Hi Everyone, upgraded from Core154 to 158 i have the same problem that the proxy is refusing connections.
It started after Save and restart in the GUI. Log management is still ON.
I will follow the Bugzilla post.

I’ve updated to 158 and it’s worse. So far it only seems to effect the ABC News app (Australia). Clearing the cache fixes it for about half an hour then the site it connects to is unavailable.

Good evening,
it also happened to me that after the update to 158, the proxy service does not restart automatically at every restart.
I noticed that it is flagged “Suppress version information:” and there is no way to remove it, it wasn’t there before.
I noticed that to restart the web proxy, I just need to click on a button also to clear the cache.

I have another firewall with the same version of ip-fire, same hardware but if I restart it the service starts regularly

My hardware is:
Intel J1900 with 4GB Ram and 32 GB ssd and 4 lan
IPFire 2.25 (x86_64) - Core Update 158


1 Like

Hi all,

first, sorry for replying late on this.

Second, thanks to everyone who is contributing here. Running Squid on a bunch of x86_64 IPFire machines (some of them log queries, but most don’t), I did not observe this behaviour so far, hence I am still trying to figure out what is going on here.

My understanding so far is: We are dealing with Squid not staring properly on x86_64 systems only (but not all of them), doing so since Core Update 154 at least. Re-writing its configuration (i. e. toggling log settings or something similar) solves the issue in all cases.

This seems to be a different issue then, as every other user described Squid to be unresponsive to any query. Or did I misunderstood you?

This was my fault again. Introduced here, I thought it might be a good idea to enable this switch by default, as there is no legitimate reason why Squids version matters. That patch seems to be faulty though, ignoring user requests to actually show the version information. :expressionless:

EDIT: Bug #12665 has been raised for this one.

Anyway, I will dig deeper into this, spare time permitting. Will keep you updated.

Thanks, and best regards,
Peter Müller


first of all thank you for the tremendous work you are doing with IPFire.

The strange thing is that I have 4 identical hardware firewalls, but only mine, luckily the one at home, has this anomaly.

All are upgrades since at least 152 none is a new install.

They don’t all have the same plugins installed, in mine there are those visible in the attachment.

I tried to remove them and it restarted everything, but the proxy doesn’t start anyway.

Many thanks


I’m still investigating. Sometimes clearing the cache isn’t enough. Sometimes “save and restart” will work. Other times I do nothing and it seems to be working next time I check the news.

It could also be related to the occasional issue I have with “connectivity check” on ubuntu and the phones.

I believe what I’m seeing is different to the other. Sorry.

Hi Peter,

no worries. Would you mind opening up a new thread for the issue (as soon as it gets more clear), so we avoid mix-ups? :slight_smile:

Thanks in advance, and best regards,
Peter Müller

Good morning,
as for the squid service not starting, I thought about creating a bash script.
I have scheduled the script to start every minute.
If I find the squit service “running” I do nothing, otherwise I start it.
Am I doing the right thing or do I risk doing more harm than good?

This is the bash script, I put it into a /home/nobody/


# Check if squid is running
# -x flag only match processes whose name (or command line if -f is
# specified) exactly match the pattern.

if pgrep -x "squid" > /dev/null
    echo "Running"
    echo "Stopped"
    /etc/rc.d/init.d/squid start

I put this line into a fcrontab

*/1 * * * * /home/nobody/

Ok this is a work around