upstream could not be resolved...

Alexandre Snarskii snar на snar.spb.ru
Ср Дек 8 18:24:11 MSK 2010


On Wed, Dec 08, 2010 at 04:39:35PM +0300, Alexandre Snarskii wrote:
> 
> Hi!
> 
> Странная проблема вылезла: похоже, при какой-то фазе луны nginx
> не может найти upstream, заданный в конфиге и лезет за ним в DNS. 
> 
> Задача - хитрый request routing в зависимости от переменных запроса,
> поэтому запросы сначала передаются на fastcgi-скрипт, который 
> делает необходимый анализ и отдает обратно x-accel-redirect 
> на внутренний хост. 
> 
> Конфиг примерно такой: 
> 
>  http { 
>   upstream sws-pod2 {  # с точным заданием номера порта тоже пробовал
>    server a.b.c.d;
>   }

Про то, что "с точным заданием номера порта пробовал" - это я погорячился,
указания upstream sws-pod2:80 для этого недостаточно: в результате
у upstream'а name становится "sws-pod2:80", а port по прежнему остается
нулевым. В результате вторая часть следующущей проверки 
(src/http/ngx_http_upstream.c, район 570'й строки) не удается ни в случае 
просто upstream sws-pod2 ни в случае upstream sws-pod2:80: 

            if (uscf->host.len == host->len
                && ((uscf->port == 0 && u->resolved->no_port)
                     || uscf->port == u->resolved->port)
                && ngx_memcmp(uscf->host.data, host->data, host->len) == 0)
            {
                goto found;
            }

workaround: 

   location http://(.*):(.*) { 
-    proxy_pass http://$1:$2/$request_uri$is_args$args;
+    proxy_pass http://$1-$2/$request_uri$is_args$args;
   }

и задавать порт на уровне имени upstream, например upstream sws-pod2-80.


>   server { 
>    listen ...;
>    location / { 
>      fastcgi_pass 127.0.0.1:1030;
>    }
>    location ~* http://(.*):([0-9]+) { # да, знаю, криво. 
>      internal;
>      proxy_pass http://$1:$2/$request_uri$is_args$args;
>    }
>  }

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 



Подробная информация о списке рассылки nginx-ru