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

[Christoph Mathys]

Hello Alex,

Thank you very much for your reply!

On Wed, Mar 4, 2026 at 7:32 PM Alex Rousskov
<rousskov at measurement-factory.com> wrote:
>
> On 2026-03-04 10:01, Christoph Mathys wrote:
> > I've noticed that Squid doesn't handle situations well when it cannot
> > resolve or connect to cache_peers.
>
> Please note that we do not know how you define "well" in this context.

Sure. My goal is that the user does not need to restart squid due to
network changes. Its OK to get 500 or whatever when no cache_peers are
available or while squid is probing peers. But it should "self-heal"
within seconds after receiving a request if possible.

> 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? Or have
concurrent probes run so that later requests also immediately trigger
a probe?

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