On 2026-03-04 10:01, Christoph Mathys wrote:
Hello everyone,
I'm considering installing Squid on user devices to authenticate
against corporate proxies using Kerberos. This approach allows me to
set http_proxy=localhost:3128 for various tools, enabling transparent
authentication.
When it works, it works quite well!
However, before corporate proxies can be reached or resolved, users
need to establish a VPN connection to the corporate network.
Understood.
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.
I'm wondering if the retry behavior
can be tweaked so that Squid retries connecting to cache_peers
whenever a new request is received, or after a short delay (e.g., when
a user realizes the VPN isn't up, connects, and then refreshes with
F5).
That behavior is already implemented AFAICT. I realize that what you
observe does not match what you want to see, but it seems to match what
you describe in the above paragraph. The associated [peerProbeIsBusy()
and caller] code can be interpreted as literally matching your "upon new
request or after a short delay" description!..
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.
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.
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.
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.
HTH,
Alex.
[^B2]: Ideally, you also do not want to make Squid service available to
user requests until cache_peers are successfully probed. Any requests
should immediately fail (because Squid is not listening for them) while
Squid is still probing. I may even have code that accomplishes something
very similar, but it is currently stuck in the Squid Project backlog.
I wanted to ask here first before diving into the code or implementing
a workaround.
Currently, my workaround is to manually restart Squid when it decides
that no cache_peers are available (IIRC, returning http 500).
I'm on macOS, and since this is a corporate setup, my options are
somewhat limited.
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
