no resolver defined to resolve localhost

[stefankaerst.web.de@…]

I just downloaded nginx-1.21.6.tar.gz and tried a proxy pass configuration to "localhost"

the error.log contains

[error] 10208#0: *6 no resolver defined to resolve localhost

IMHO this is a bug because localhost can be resolved by the OS resolver. see below
2nd, the error message text ist misleading, because I do not have to configure a DNS server within nginx because the OS is responsible to provide DNS service. no one configures DNS server in e.g. haproxy,squid,a....e,varnish ;)

"localhost" is no hostname that belongs to any global DNS zone, so it makes no sense to even put it into a DNS zone.
every major OS has "localhost" entries in /etc/hosts or other files accordingly to make this name available. therefore "localhost" is available without DNS whatsoever and even without a working network configuration e.g. offline. (as long as nsswitch works correctly)
I'm using GNU/Linux openSUSE 15.3 if that is any of interest.

using the local resolver (without DNS server):

/usr/local/nginx/sbin $ getaddrinfo localhost
family:10 socktype: 1 protocol:  6 addr:::1(28)
family: 2 socktype: 1 protocol:  6 addr:127.0.0.1(16)
/usr/local/nginx/sbin $ 

/usr/local/nginx/sbin $ getent ahosts localhost
::1             STREAM localhost
::1             DGRAM  
::1             RAW    
127.0.0.1       STREAM 
127.0.0.1       DGRAM  
127.0.0.1       RAW    
/usr/local/nginx/sbin $

mayby linked to #2259, but nginx could resolve localhost at the start or reload

[Maxim Dounin]

The no resolver defined to resolve ... error means that per the configuration provided nginx has to resolve the name at runtime — that is, during processing a request. This happens when ​proxy_pass is used with variables, so the full URI is only available during request processing, after variables are evaluated. Quoting the proxy_pass directive description:

Parameter value can contain variables. In this case, if an address is specified as a
domain name, the name is searched among the described server groups, and, if not
found, is determined using a resolver.

The localhost name is not special, and if it's not otherwise present in the configuration, nginx will have to use a resolver to resolve it.

The most trivial (and likely also beneficial from the performance point of view) fix would be to avoid using variables in proxy_pass. These are not needed except in complex configurations where you actually want nginx to use a resolver.

[stefankaerst.web.de@…]

hi Maxim, thanks for your fast reply.
may I add something..

I guess localhost is no variable here. this is the config I used

location /localhost {

proxy_pass ht tp://localhost:6556$request_uri;

}

anyway. I tried the resolver directive just out of curiosity, like this:

#resolver fritz.box:53;
resolver localhost:53;

location /remotehost {

proxy_pass ht tp://section61.fritz.box$request_uri;

}
location /etchostshost {

proxy_pass ht tp://etchostshost$request_uri;

}

after starting a bind9 DNS server on my maschine all proxy_pass targets except those from /etc/hosts are working.

I dunno how nginx uses "resolver" directive internally but it was able to solve the chicken and egg problem ;)

GL&HF!

PS: I had to insert spaces into http otherwise trac.nginx.org won't let me paste this config

[Maxim Dounin]

As soon as there are any variables in the proxy_pass parameter, nginx postpones parsing till the variables can be substitutes. As such, with your configuration it has to resolve names during request processing, and therefore needs a resolver.

Note that the $request_uri part is useless in the configuration. It would be enough to write just a domain name, for example:

location /localhost {
    proxy_pass http://localhost:6556;
}

This will not require any variable evaluation at runtime, and will not require a resolver.

[stefankaerst.web.de@…]

indeed

proxy_pass http://localhost:6556;

works like a charm, whereas

proxy_pass http://localhost:6556$request_uri;

produces
[error] 20094#0: *24 no resolver defined to resolve localhost, client: 127.0.0.1, server: localhost

so the error message still is misleading. it should be something like "no, you cannot use variables here!" or "nginx cannot fill $request_uri here", because localhost and any other hosts (even from /etc/hosts) will be resolved without a resolver explicitly configured.

why does nginx tell me it needs a [dns]resolver if it has a problem with the variable?

I'm pretty sure nginx can fill variables outside a proxy_pass block, so what does this error message tell me? it cannot mean a [dns]resolver obviously.
why does a "resolver" keyword in the config make a proxy_pass with $request_uri work without error? maybe the resolver keyword should be renamed to variable_resolver instead. this all makes no sense to me. sry!

thanks for your support anyway. I'm pretty sure thousands of sysadmins stumble accross this "error" message and start to google it too.

[nara3m]

I agree with Stefan's comment. Error log message is misleading. I support Stefan's suggestion to replace error message to "no, you cannot use variables here!" or "nginx cannot fill $request_uri here"

Replying to stefankaerst.web.de@…:

indeed

proxy_pass http://localhost:6556;

works like a charm, whereas

proxy_pass http://localhost:6556$request_uri;

produces
[error] 20094#0: *24 no resolver defined to resolve localhost, client: 127.0.0.1, server: localhost

so the error message still is misleading. it should be something like "no, you cannot use variables here!" or "nginx cannot fill $request_uri here", because localhost and any other hosts (even from /etc/hosts) will be resolved without a resolver explicitly configured.

why does nginx tell me it needs a [dns]resolver if it has a problem with the variable?

I'm pretty sure nginx can fill variables outside a proxy_pass block, so what does this error message tell me? it cannot mean a [dns]resolver obviously.
why does a "resolver" keyword in the config make a proxy_pass with $request_uri work without error? maybe the resolver keyword should be renamed to variable_resolver instead. this all makes no sense to me. sry!

thanks for your support anyway. I'm pretty sure thousands of sysadmins stumble accross this "error" message and start to google it too.