On 2026-04-20 12:15, Christoph Mathys wrote:
I gave it a try to examine the code. What worries me is that peerDnsRefreshStart() has hard-coded values of 180s and 3600s. I seem to always see the 3600s variant and cannot get any other behavior from squid (but 3min waiting would still be a lot).
IIRC, you can ignore those delays in peerDnsRefreshStart(). They are for periodically rechecking/resetting cache_peer addresses. They are not for initializing those addresses at start or during reconfiguration.
AFAICT, your use case is affected by peer_connect_timeout and related cache_peer options that determine TCP probe timeouts. The default 30 second timeout I mentioned in my previous response is used to compute ctimeout inside peerProbeConnect().
My planed workaround is to have some kind of monitor-service that sends SIGHUP to squid when the VPN connection changes. Squid will forget about the failed DNS lookups and immediately try to resolve the peers, and service is restored in seconds. Hope it works out!
Yes, that would be very much inline with option A in my first response (quoted below), adjusted for the fact that your users may experience problems (i.e. their connectivity may change) _after_ Squid starts. If you can reconfigure Squid using an external trigger/daemon, it may be your best option.
HTH, Alex.
A: Configure user devices to start Squid _after_ the user establishes "a VPN connection to the corporate network". I do not know whether that is possible in your environment, but, if it is, it would be a relatively clean solution that does not require Squid development.
_______________________________________________ squid-users mailing list [email protected] https://lists.squid-cache.org/listinfo/squid-users
