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 mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru