On 23/10/2016 10:35 a.m., Amos Jeffries wrote:
On 22/10/2016 12:21 a.m., André Janna wrote:
I set up a Squid proxy that forwards all requests to 2 parent caches.
I'm using Squid version 3.5.19.
My goal is that multiple connection from a client to a server should be
forwarded to the same parent
client are not sent to the same parent cache.
How can I force Squid to always use source hash parent selection method?
Regards,
André Janna
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
Em 28/11/2015 22:46, André Janna escreveu:
I took another network trace this time both at Squid and Windows
client ends.
cache.log:
2015/11/27 11:30:55.610 kid1| SECURITY ALERT: Host header forgery
detected on local=177.43.198.106:443 remote=192.168.64.4:61802 FD 5465
flags=33 (local IP does
Citando Amos Jeffries :
So, the first place to look is not Squid I think. But why at least 6 of
those ACK packets did not make it back to the client. That needs
resolving first to esure that the TCP level is operating correctly.
Only then if the problem remains looking at Squid, the use of port
Assinatura
Em 24/11/2015 00:54, Amos Jeffries escreveu:
FYI: unless you have a specific need for 3.5 you should be fine with
the 3.4 squid3 package that is available for Jesse from Debian
backports. The alternative is going the other way and upgrading right
to the latest 3.5 snapshot (and/or 4
Assin Em 22/11/2015 16:25, Eliezer Croitoru escreveu:
Hey Andre,
There are couple things to the picture.
It's not only squid that is the "blame".
It depends on what your OS tcp stack settings are.
To verify couple things you can try to use the netstat tool.
run the command "netstat -nto" to see
Citando André Janna:
Squid is still using file descriptors 12 and 14 (and a lot of others)
for the same connections as yesterday, although the mobile devices it
was connected to have not been online in our network for at least 15
hours.
Update: Squid released file descriptors after about
Citando Amos Jeffries :
CONNECT requests with tunnels can be particularly long lived, mobiles
and their applications stay active for weeks on end with few outward
signs of what is happening inside the encrypted tunnel. The only way to
be sure the connection is finished with is when one of the c
I'm running Squid 3.5.10 on Debian Jessie and after some hours of execution
it runs out of file descriptors.
Squid is listening on port 3125, 3126 and 3127.
Port 3126 is used for intercepting, via iptables redirect, https
connections mostly from mobile devices like smartphones. On this port is
act
