On Wed, Dec 14, 2016 at 09:38:41PM +0300, Dmitry Sivachenko wrote:
>
> > On 14 Dec 2016, at 20:50, Maxim Dounin <mdounin@mdounin.ru> wrote:
> >
> > Hello!
> >
> > On Wed, Dec 14, 2016 at 08:06:31PM +0300, Dmitry Sivachenko wrote:
> >
> >>> On 14 Dec 2016, at 19:59, Maxim Dounin <mdounin@mdounin.ru> wrote:
> >>>
> >>> Если в конфиге действительно proxy_pass на имя - то при чём тут
> >>> resolver? Первыми будет использоваться IPv4-адреса из-за порядка
> >>> сохранения записей, который случается в ngx_inet_resolve_host().
> >>>
> >>> Однако как и в случае resolver'а - порядок ни на что не влияет,
> >>> кроме, может быть, отдельных краевых эффектов, т.к. все полученные
> >>> адреса будут использоватся и запросы между ними будут
> >>> балансироваться по round-robin.
> >>
> >> Допустим, что nginx работает на ipv6-only сервере, а some.ip (аргумент proxy_pass) -- имеет и A, и AAAA.
> >> Я не хочу чтобы nginx вообще пытался устанавливать соединение к ipv4-адресу.
> >
> > Если у вас ipv6-only сервер - так и будет, т.к. nginx использует
> > getaddrinfo() с флагом AI_ADDRCONFIG, и неподдерживаемые адреса
> > система просто не вернёт nginx'у.
>
>
> В моем случае на машине настроены ipv4-over-ipv6 туннели, так что реально ipv4-адреса на интерфейсе есть, но роутинг работает только для ipv6.
>
> Раз используется getaddrinfo(), то эта функция как раз возвращает адреса в нужном порядке (учитывает ip6addrctl_policy).
>
> Так что кажется что проблема лишь в
> ----------
> Первыми будет использоваться IPv4-адреса из-за порядка
> сохранения записей, который случается в ngx_inet_resolve_host().
> ----------
>
> Если сохранять порядок, возвращаемый getaddrinfo(), то будет то поведение, которое нужно.

Как уже написал Максим ранее, эти адреса используются в режиме
round-robin, поэтому все они рано или поздно будут попробованы.
Вот зеркальная ситуация с unroutable IPv6:

1-й запрос:
2016/12/15 09:10:07 [error] 35029#0: *1 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://88.198.44.17:12345/", host: "127.1:8000"
2016/12/15 09:10:07 [error] 35029#0: *1 connect() to [2a01:4f8:a0:1064::2]:12345 failed (65: No route to host) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:12345/", host: "127.1:8000"
[...]

2-й запрос:
2016/12/15 09:10:21 [error] 35029#0: *4 connect() to [2a01:4f8:a0:1064::2]:12345 failed (65: No route to host) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://[2a01:4f8:a0:1064::2]:12345/", host: "127.1:8000"
2016/12/15 09:10:23 [error] 35029#0: *4 kevent() reported that connect() failed (61: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", upstream: "http://88.198.44.17:12345/", host: "127.1:8000"
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru