[squid-users] squid as a local proxy for kerberos authentication

[Alex Rousskov]

On 2026-03-26 09:34, Christoph Mathys wrote:
> On Wed, Mar 4, 2026 at 7:32 PM Alex Rousskov wrote:
>> The devil is in the details. In this case, I suspect that at least two
>> details are relevant:
>>
>> 1. It is important to distinguish "Squid starts trying to connect" from
>> "Squid finishes trying to connect". Squid does not support multiple
>> _concurrent_ cache_peer probes. If a cache_peer probe takes, say, 30
>> seconds, the peer will be treated as dead for those 30 seconds. Roughly
>> speaking, another probe will be started when/if there is another
>> potential need for that cache_peer after the current probe finishes.
>>
>> 2. Probes that can mark a cache_peer as "alive" are not a part of a
>> regular HTTP transaction. They are triggered by regular transactions and
>> (re)configurations, but regular transactions do not _wait_ for probes to
>> finish and do not reuse probe connections. Probing is a "background"
>> activity.
> 
> That sound pretty reasonable. Can I tweak the 30s timeout?

N.B. I used "30 seconds" as an example of how long a probe might take. 
That time accidentally matched peer_connect_timeout default.

peer_connect_timeout and related cache_peer options determine TCP probe 
timeouts. See squid.conf.documented for that directive details. The 
default for peer_connect_timeout global is 30 seconds. Please keep in 
mind that peer_connect_timeout and related cache_peer options are _not_ 
specific to peer probes; they are used for regular TCP connection 
opening attempts as well. Thus, if you decrease those timeouts, then 
regular transactions may also be affected.


> Or have
> concurrent probes run so that later requests also immediately trigger
> a probe?

No, there is no code to do that AFAICT. I doubt it should be added, and 
adding it correctly would not be easy.

Adding peer_probe_timeout, a new squid.conf directive that you can use 
to get a shorter connection establishment timeout for cache_peer probes, 
may be a good idea though! That would be a relatively simple change AFAICT.


HTH,

Alex.


> I observe the following on Mac OS:
> 
> Mac OS does not seem to sleep in the same way that an ACPI
> Suspend-to-RAM sleeps: I see constant activity when I think it should
> be sleeping. The VPN connection drops at some point during sleep or is
> even directly terminated when the Mac enters sleep. Squid and
> applications continue to run and generate log messages.
> 
> My log contains messages like the following about every hour:
> 
> 2026/03/26 04:24:35| WARNING: DNS lookup for 'proxy4.example.com' failed!
>      current cache_peer probe: proxy4.example.com
> 2026/03/26 04:51:50| comm_udp_sendto FD 10, (family=2)
> 172.31.58.13:53: (51) Network is unreachable
>      current master transaction: master1203
> 2026/03/26 04:51:50| idnsSendQuery FD 10: sendto: (51) Network is unreachable
>      current master transaction: master1203
> 
> In the morning it need to restart squid because it seems that not
> being able to resolve cache_peer is a bit of a red flag.
> 
> The same problem can happen when I close the Laptop, dropping VPN
> through mobile, and then resume working inside the office without VPN.
> 
>> Going forward, I see several paths:
>>
>> 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.
> 
> I currently delay starting squid until I can resolve a cache_peer.
> This is only effective during boot. And of course, the user does not
> always use VPN, but can also connect directly to the corporate WiFi
> when at the office. So I think it is a bit messy to try to start and
> stop squid at the right time.
> 
>> B: Add a cache_peer "aggressive-probes" option to re-probe a still-DEAD
>> peer without waiting for an HTTP request that may use that peer. This
>> should be a fairly straightforward development project. This will not
>> solve all the problems[^B2], but it should help a lot.
> 
> I already hear the users complaining about battery drain. I think
> triggering probing using a request is good enough in this case.
> 
>> C: If you really want Squid to _stall/pause_ an incoming HTTP request
>> until at least one eligible cache_peer is available, then you will need
>> to write quite a bit of complicated code (AFAICT) that would be
>> difficult to make official. The idea just goes against how Squid peer
>> selection code is structured/designed. I do not recommend this path.
> 
> I don't think anything that drastic is required. Requests can just
> fail until shortly after the VPN is connected (maybe 5-10s?).
> 
> Again, thank you very much for taking the time!
> 
> Christoph