On 1/09/2015 10:42 p.m., Yuri Voinov wrote: > > Not available when IPv6 enabled on my outgoing interface. > > Note: IPv6 globally not used in my country. > The rest of your country does not matter. For *any* protocol your router should either have connectivity to your ISP, or not. It still needs to work properly in both situations. In this case Squid cannot determine the route is unavailable before the client has given up and gone away. It takes over 20sec. That tells me the ICMPv6 is not working properly at all for you. A router somewhere along the path should be at a border where v6-enabled connectivity stops. It is aware of whether there is IPv4/IPv6 connectivity to its next-hop. It should be *immediately* emitting destination-unreachable ICMP/ICMPv6 messages to the software opening the connection (ie Squid) when connectivity is absent (or down). * If you have an IPv4-only network that 'router' is the routing code built into the TCP stack of the Squid machine itself. This is what triggers in your (working?) case when you dont have any IPv6 address assigned to the machine interfaces. * If you have IPv6-enabled network, but no upstream to ISP. Then your border gateway router is responsible for the ICMP(v6) signalling. Squid is waiting for that signal or a SYN+ACK ... 20sec ... nope. There has been a myth floating around that simply DROP'ing packets is okay to "disable" stuff. That _always_ leads to problems somewhere else. Usually this hanging connection one. DROP does have its uses when fending off DoS attacks *from outside*. But for all internally generated traffic using REJECT with the right codes is far, far better. PS. ICMP(v6) are _not_ optional. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users