Hello!

On Wed, Dec 08, 2010 at 06:24:11PM +0300, Alexandre Snarskii wrote:

> 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;
> }

Upstream с портом может появиться только при неявном задании через
proxy_pass http://upstream:port/; в конфиге. В честно описанных
upstream-блоках порт - это свойство конкретного server'а в нём (и
для разных серверов они могут быть разные).

Использование upstream-блоков в качестве банальной замены
resolver'у - не предполагается.

> 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.

Да, так будет работать.

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru