A few notes - The SNI configuration will have no effect on this scenario. Here is a diagram of the what happens when using an explicit proxy -
https://www.planttext.com/?text=LP11IyD048NlyoiUwLLBqPvoa6giA9P4I3n8o66JRDE5TLSckuR-UuS42xqCotnlthoTtHWKX_XjYLGNF2Fv73NZST0k950ZegBEky3U8gbO7O-cGwdvL_ECmqYYDE6Cv5ctHhcvsyzFegXm-o0QfCYAFDzd5QPfMYzuxNb8jzjx8X7Kgu6rTet85oeZLVQ1yYkVkVJ5BCNTPeFYdMXW7tyGedFQedwonlLuyJmfxeqRccLrlMfjrCr_0ciaAbxtXqD1pWSDDiCf22dpDvmqwnkqCK0GHic2zeph7yz1BgQNd5V6SewUQ2TLZle7 ATS never sees the "Client HELLO" as such, it's just bytes it forwards to the upstream, and therefore never sees the SNI. SNI based configuration is only useful if ATS is an implicit proxy. Testing locally, your scenario works fine for me on master. I will try to set up to test 9.0.1. Further testing was able to mimic your error by selecting a port that is not in service on debian.org. Sadly, it appears that ATS only goes so far as to send a SYN to the upstream - if that is successful it responds with "200 OK". If the upstream doesn't like that SYN (in my case, because there is nothing listening on that port) then it sends a RESET but only after the user agent has sent its Client HELLO. ATS then closes the connection to the user agent (because of the RESET) with the result being the same as your reported error. >From what I can tell,"130.89.148.77" is a valid address for a Debian server in Europe, so that seems reasonable. The mystery here is why ATS apparently sends a packet with a zero port. That shouldn't even make it past the next router, but perhaps that is what is sending the RESET. I don't see that locally even using the same "CONNECT" request.
