#2335 closed defect (invalid)
no resolver defined to resolve localhost
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | nginx-1.21 |
Component: | nginx-core | Version: | |
Keywords: | Cc: | ||
uname -a: | Linux linux 5.3.18-150300.59.54-default #1 SMP Sat Mar 5 10:00:50 UTC 2022 (1d0fa95) x86_64 x86_64 x86_64 | ||
nginx -V: |
/usr/local/nginx/sbin $ ./nginx -V
nginx version: nginx/1.21.6 built by gcc 7.5.0 (SUSE Linux) configure arguments: |
Description (last modified by )
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
Change History (6)
comment:1 by , 3 years ago
Description: | modified (diff) |
---|
comment:2 by , 3 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:3 by , 3 years ago
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
comment:4 by , 3 years ago
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.
follow-up: 6 comment:5 by , 3 years ago
indeed
proxy_pass http://localhost:6556;
works like a charm, whereas
proxy_pass http://localhost:6556$request_uri;
produces
[error] 10208#0: *6 no resolver defined to resolve 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.
comment:6 by , 2 years ago
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.
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 theproxy_pass
directive description: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.