proxy_pass behavior

[Maxim Dounin]

Hello!

On Thu, Mar 27, 2014 at 08:18:48PM -0400, Jim Popovitch wrote:

> On Thu, Mar 27, 2014 at 1:50 PM, Jim Popovitch <jimpop at gmail.com> wrote:
> > On Thu, Mar 27, 2014 at 1:27 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >> Hello!
> >>
> >> On Thu, Mar 27, 2014 at 01:12:18PM -0400, Jim Popovitch wrote:
> >>
> >>> On Thu, Mar 27, 2014 at 12:59 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> >>> > Hello!
> >>> >
> >>> > On Thu, Mar 27, 2014 at 12:29:03PM -0400, Jim Popovitch wrote:
> >>> >
> >>> >> Should proxy_pass retry ipv4 if ipv6 fails?   Currently (1.5.12), it
> >>> >> does not, and there is no way to force proxy_pass to always use ipv4.
> >>> >
> >>> > In no particular order:
> >>> >
> >>> > - The proxy_next_upstream is expected to retry by default.
> >>>
> >>> Yes, that works if the host name has 2 or more A  OR  2 or more AAAA
> >>> records.  proxy_next_upstream does not appear to transition to the
> >>> next protocol (i.e. from ipv4 to ipv6)
> >>
> >> It doesn't care about address family.  As long as connect() to
> >> one address fails, it will try next one.
> >
> > I will have to do some more tests, but so far 1.5.12 (debian wheezy)
> > does not appear to try the next one if the next one is a different
> > protocol family.
> 
> So here is what happens:
> 
> Nginx 1.5.12 on Debian Wheezy 7.4
> 
> ~$ host www.acadiau.ca
> www.acadiau.ca has address 131.162.201.18
> www.acadiau.ca has IPv6 address 2620:21:c000:c8:0:aca:d1a:18
> 
> ~$ grep proxy_pass /etc/nginx/sites-available/proxy
> proxy_pass https://www.acadiau.ca;
> 
> When an IPv6 client connects to the proxy, proxy_pass logs the error as
> 
> 2014/03/27 21:28:28 [alert] 24862#0: *158336 connect() failed (13:
> Permission denied) while connecting to upstream, client:
> 2604:180::82c6:fe9, server: proxy-service.tld, request: "GET /
> HTTP/1.1", upstream: "https://[2620:21:c000:c8:0:aca:d1a:18]:443/",
> host: "proxy-service.tld"
> 
> It will next try the ipv4 addr and succeed, however the reason for the

So the original claim that it "does not appear to try the next 
one" is withdrawn, right?

> "Permission denied" error appears to be the format of the URL (raw
> ipv6 addr, not hostname).  Why is it using the ipv6 addr instead of
> the hostname?

No, it's an error from connect() syscall, returned by your OS for 
some reason (likely because there is no route available, or due to 
a firewall rule).  The address is one of the upstream server nginx 
uses at the moment - it's is vital for logging if there are more 
than one address.

-- 
Maxim Dounin
http://nginx.org/