Lots of "NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE" error messages in the Squid log

Hello everyone,

I’ve noticed a lot of “NONE_NONE/000 0 - error:transaction-end-before-headers - HIER_NONE” errors in Squid’s log for the last few days.

I realised that there were strange requests on the IP address of the firewall used for the Wifi network ( …on port 3128.

And since that…I have a lot more errors ¨error:transaction-end-before-headers¨ :thinking:

I’m trying to figure out what the problem is but I can’t :frowning:

I have 2 identical ipfire in terms of config and version (core 173) on 2 different sites and it seems that one of the sites is more impacted than the other.
I’m trying to figure out what the problem is but I can’t.

I saw that someone else had this problem
…apriori…the problem was related to content filtering.
I don’t use content filtering and yet I have the same problem :frowning:

How do I go about debugging/fixing this problem ?

I saw that you can add these 2 lines in the squid config

acl hasRequest has request
access_log daemon:/var/log/squid/access.log hasRequest

…which I did in the file “/var/ipfire/proxy/advanced/acl/include.acl” but it doesn’t seem to fix the problem.


(My config: ASUSTeK COMPUTER INC. ‐ P9D-C Series | IPFire 2.27 - Core Update 173 | Intel(R) Core™ i3-4130T CPU @ 2.90GHz x2)

error:transaction-end-before-headers should mean that a connection opened by a machine in your network is dropped before Squid could relay the web page to it. To me it seems there is some rare but not unique circumstance when this is triggered in IPFire. Could be a bug somewhere but it looks like difficult to define the exact circumstances that triggers it.

Thanks @cfusco for your reply :+1:

The proxy is set to “transparent” on our network which implies that all web traffic is intercepted by Squid.
What I find strange is that in the proxy logs, very few web pages visited appear and a lot of error “error:transaction-end-before-headers” :pensive:

If there was a problem accessing the web pages we would realise it quite quickly !…because we are some users (>40-60) / days use our network (wifi and LAN).

If the proxy intercepts connections on port 80 and 443 then why do I see very few websites that appear in the logs ?

Do you know another way to trace proxy connection from Windows or Linux Client Workstation ?


A transparent proxy will work only on port 80. All the connections on port 443 will go to the proxy only if the web browsers are configured accordingly. The way to deal with the clients is to set up a wpad and DHCP for automatic proxy detection (which does not work 100% of the time), but ultimately you will need a rule in the firewall dropping all connections to port 443 not directed at the proxy. Basically, you will block access to the web to your clients, until they configure their browsers to use the proxy.

I have already set up the dhcp to publish WPAD but indeed it does not have a solution that works 100% :frowning:
We are a training centre and so we have a lot of passage. I wanted to filter the Wifi with the proxy but I think it’s not a good idea because I realise in use that many computers but also phones or tablets do not go through the proxy.

Putting a rule at the Firewall level to force the use of the proxy will not make things easier because not everyone knows how to set up a proxy on their phone or computer. This will generate a lot of assistance to students and will become tedious to manage.
In addition, once outside our premises they may forget how they set up the proxy and we may be overwhelmed with requests for assistance.

Forcing the use of the proxy is possible for machines on the LAN because the proxy can be deployed through GPOs or other but complicated for the Wifi network.

Also i use external DNS filter (OpenDNS service) in order to complete the protection scheme but this does not allow me to see the internal network machines that have made unauthorised requests. Filtering at OpenDNS only indicates our external IP address as a source in the reports, not the addresses within our network :wink: