Help with: no resolver defined to resolve upstream-name

Ze Claudio Pastore zclaudio at bsd.com.br
Thu Aug 4 15:40:30 UTC 2016


Hello,

(Short version: what could cause nginx to try to resolve a name used as the
upstream backend configured name? Long version follows in the body of the
message).

I have a weird problem, which might be something simple I am missing, I
searched the archives and read the documentation twice and still I am
missing something.

In one site / system I have the following simple conf:

http {
...
    upstream app1-backend {
        sticky name=app1cookie hash=md5 secure httponly;
        server 192.168.0.4;
        server 192.168.1.4;
    }
...
}

server {
 ...
 location / {
  ...
  proxy_pass http://app1-backend;
  ...
 }
...
}

And it works perfectly. In a second server I have almost the same conf:

http {
...
    upstream app1-backend {
        sticky name=app1cookie hash=md5 secure httponly;
        server 192.168.1.4;
        server 192.168.0.4;
    }
...
}

server {
 ...
 location / {
  ...
  proxy_pass http://app1-backend;
  ...
 }
...
}

They are two individual nginx reverse proxies in two different data centers.

The first nginx/site works great, but on the second I get the following
error:

2016/08/03 18:09:56 [error] 94482#100729: *34 no resolver defined to
resolve app1-backend, client: 192.168.1.20, server:app1.mydomain.com,
request: "GET / HTTP/1.1"

So it looks like, for some weird reason, nginx on second site is trying to
resolve app1-backend as a host. Proof is, if I add it to /etc/hosts it
works. But obviously this is not what I want, the proxy_pass is pointed to
an upstream backend not a host.

So, first site works fine, second wants to resolve app1-backend like if it
was not an upstream block. Both sites should have the very same config, I
have compared with diff -u but I still can't figure out what's going wrong
here.

My guess this is a basic mistake but I can't see.

Any obvious diagnostics here?

Thank you very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160804/296c1efa/attachment.html>


More information about the nginx mailing list