Hey Alex,
The main issue now is the extensive logging.
For a tiny server with a single desktop client the cache.log are expending a
*lot*.
I have a problem with discarding these logs but for this specific case where
the ttl is very low ie: lower < 30/20/10 seconds
We can expect for this to happ
Hi squid users!
Hope you are all well. I'm attempting to migrate from Squid 3.5 to 4, and in my
conf file I used to have balance_on_multiple_ip toggled on as to reduce chance
of brownouts on endpoints. I noticed this is not available in Squid 4, is it on
by default? Or is there some alternative
On 1/6/21 3:24 PM, Conner Bean wrote:
> Hope you are all well. I'm attempting to migrate from Squid 3.5 to 4,
> and in my conf file I used to have balance_on_multiple_ip toggled on
> as to reduce chance of brownouts on endpoints.
FYI: Enabling balance_on_multiple_ip does nothing in Squid v3.5.
On 1/6/21 2:49 PM, Eliezer Croitoru wrote:
> I am trying to think about the right solution for the next issue:
> SECURITY ALERT: Host header forgery detected on conn18767
> local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
> does not match any domain IP)
As you know, thi
FYI my long term plan is to extend squids internal representation of DNS results to include the TTL for each address, and set pass-thru client connection lifetimes to the TTL of the IP they are using. That will solve all the issues with pipelined traffic and expired TTLs which is a huge chunk of th
I'm testing SSL BUMP in 5.0.4 and it's working pretty well despite some
hiccups.
I am trying to think about the right solution for the next issue:
SECURITY ALERT: Host header forgery detected on conn18767
local=52.114.32.24:443 remote=192.168.189.52:65107 FD 15 flags=33 (local IP
does not match an
