[squid-users] Squid 5.2 Peer parent TCP connection to x.x.x.x/x failed

[Alex Rousskov]

On 11/2/21 12:28 PM, David Touzeau wrote:
> Ok, we will investigate on the Parent Proxy but it seems that when squid
> child claim about TCP failed, it understand that the peer is dead

Yes, that is the side effect of the deficiency I was talking about --
Squid inability to recognize that specific error response from the
(indirect) parent Squid as something completely unrelated to the TCP
connection to the next hop (and to the responding parent Squid ability
to serve traffic in general). There are quite a few things that could be
improved here for your and similar use cases.

Alex.


> Le 02/11/2021 à 16:17, Alex Rousskov a écrit :
>> On 11/2/21 10:40 AM, David Touzeau wrote:
>>> 2021/11/01 16:50:48.787 kid1| 93,3| Http::Tunneler::handleReadyRead(conn9812727 local=127.0.0.1:23408 remote=127.0.0.1:2320 FIRSTUP_PARENT)
>>> 2021/11/01 16:50:48.787 kid1| 74,5| parse: status-line: proto HTTP/1.1
>>> 2021/11/01 16:50:48.787 kid1| 74,5| parse: status-line: status-code 503
>>> 2021/11/01 16:50:48.787 kid1| 74,5| parse: status-line: reason-phrase Service Unavailable
>>> Server: squid
>>> Date: Mon, 01 Nov 2021 15:50:48 GMT
>>> X-Squid-Error: ERR_CONNECT_FAIL 110
>>> 2021/11/01 16:50:48.787 kid1| 83,3| bailOnResponseError: unsupported CONNECT response status code
>>> 2021/11/01 16:50:48.787 kid1| TCP connection to 127.0.0.1/2320 failed
>> A parent[^1] proxy is a Squid proxy that cannot connect to the server in
>> question. That Squid proxy responds with an HTTP 503 Error to your Squid
>> CONNECT request. Your Squid logs the "TCP connection to ... failed"
>> error that you were wondering about.
>>
>> This sequence highlights a deficiency in Squid CONNECT error handling
>> code (and possibly cache_peer configuration abilities). Ideally, Squid
>> should recognize Squid error responses coming from a parent HTTP proxy
>> and avoid complaining about remote Squid-origin errors as if they are
>> local Squid-parent errors. IIRC, some folks still insist on Squid
>> complaining about the latter "within hierarchy" errors, but the former
>> "external Squid-origin" errors are definitely not supposed to be
>> reported to admins via level-0/1 messages in cache.log.
>>
>>
>> HTH,
>>
>> Alex.
>>
>> [^1]: Direct or indirect parent -- I could not tell quickly but you
>> should be able to tell by looking at addresses, configurations, and/or
>> access logs. My bet is that it is an indirect parent if you are still
>> using a load balancer between Squids.
>>
>>
>>
>>> Le 01/11/2021 à 15:53, Alex Rousskov a écrit :
>>>> On 11/1/21 7:55 AM, David Touzeau wrote:
>>>>
>>>>> The Squid uses the loopback as a parent.
>>>>>
>>>>> The same problem occurs:
>>>>> 06:19:47 kid1| TCP connection to 127.0.0.1/2320 failed
>>>>> 06:15:13 kid1| TCP connection to 127.0.0.1/2320 failed
>>>>> 06:14:41 kid1| TCP connection to 127.0.0.1/2320 failed
>>>>> 06:14:38 kid1| TCP connection to 127.0.0.1/2320 failed
>>>>> 06:13:15 kid1| TCP connection to 127.0.0.1/2320 failed
>>>>> 06:11:23 kid1| TCP connection to 127.0.0.1/2320 failed
>>>>> cache_peer 127.0.0.1 parent 2320 0 name=Peer11 no-query default
>>>>> connect-timeout=3 connect-fail-limit=5 no-tproxy
>>>> It is impossible to tell for sure what is going on because Squid does
>>>> not (unfortunately; yet) report the exact reason behind these connection
>>>> establishment failures or even the context in which a failure has
>>>> occurred. You may be able to tell more by collecting/analyzing packet
>>>> captures. Developers may be able to tell more if you share, say, ALL,5
>>>> debugging logs that show what led to the failure report.
>>>>
>>>> Alex.
>