On Wed, Dec 14, 2016 at 09:38:41PM +0300, Dmitry Sivachenko wrote: > > > On 14 Dec 2016, at 20:50, Maxim Dounin <[email protected]> wrote: > > > > Hello! > > > > On Wed, Dec 14, 2016 at 08:06:31PM +0300, Dmitry Sivachenko wrote: > > > >>> On 14 Dec 2016, at 19:59, Maxim Dounin <[email protected]> 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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
