No resolver defined to resolve php

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status #1256

no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status #1256

Comments

There seems to be an error with the DNS resolver every now and then, when using nginx-proxy together with docker-letsencrypt-nginx-proxy-companion . Nginx will say this:

2019/03/21 15:48:15 [warn] 9#9: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: "/etc/nginx/certs/*******.com.crt" 

And the https node will stay offline (status 502). I deploy again, and then it goes fine.

Unfortunately this is not easily reproducible. It seems to happen randomly. Sometimes everything works as expected, and sometimes I need to deploy two or three times before this error disappears and the upstream node will become available.

I have initially reported this at nginx-proxy/acme-companion#524

Today I received this from a different app on deploy:

2019/03/27 18:06:43 [warn] 8#8: no resolver defined to resolve ocsp.int-x3.letsencrypt.org while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org, certificate: "/etc/nginx/certs/.crt" 2019/03/27 18:06:46 [error] 8#8: *1 connect() failed (113: No route to host) while connecting to upstream, client: , server: , request: "GET / HTTP/2.0", upstream: "", host: "" 

I am not sure the second message is always there.

Here is the abridged docker-compose.yml for the latter:

version: "3.5" services: dashboard: image: redsandro/dashboard container_name: rs-dashboard depends_on: - nginx - nginx-gen - nginx-letsencrypt networks: - proxy environment: VIRTUAL_HOST: dashboard.example.com VIRTUAL_PORT: 8080 LETSENCRYPT_HOST: dashboard.example.com LETSENCRYPT_EMAIL: email@example.com api: image: redsandro/api container_name: rs-api depends_on: - db networks: - proxy ports: - '25:25' environment: VIRTUAL_HOST: api.example.com VIRTUAL_PORT: 9080 LETSENCRYPT_HOST: api.example.com LETSENCRYPT_EMAIL: email@example.com db: image: mongo:4.0 container_name: rs-db restart: always nginx: image: nginx container_name: nginx restart: always networks: - proxy ports: - 80:80 - 443:443 volumes: - conf.d:/etc/nginx/conf.d - vhost.d:/etc/nginx/vhost.d - html:/usr/share/nginx/html - certs:/etc/nginx/certs nginx-gen: image: jwilder/docker-gen container_name: nginx-gen command: -notify-sighup nginx -watch -wait 5s:30s /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf restart: always networks: - proxy volumes: - conf.d:/etc/nginx/conf.d - vhost.d:/etc/nginx/vhost.d - html:/usr/share/nginx/html - certs:/etc/nginx/certs - ./nginx.tmpl:/etc/docker-gen/templates/nginx.tmpl:ro - /var/run/docker.sock:/tmp/docker.sock:ro nginx-letsencrypt: image: jrcs/letsencrypt-nginx-proxy-companion container_name: nginx-letsencrypt restart: unless-stopped volumes: - conf.d:/etc/nginx/conf.d - vhost.d:/etc/nginx/vhost.d - html:/usr/share/nginx/html - certs:/etc/nginx/certs - /var/run/docker.sock:/var/run/docker.sock:ro environment: NGINX_DOCKER_GEN_CONTAINER: nginx-gen NGINX_PROXY_CONTAINER: nginx networks: proxy: external: name: proxy volumes: conf.d: vhost.d: html: certs:

The text was updated successfully, but these errors were encountered:

Источник

How do I proxy nginx correct? [closed]

Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow.

// EDIT: it is my local development server I have PHP built-in server running on port 8000 for host somehost.dev . I want nginx to proxy somehost.dev from 80 port to 8000. My config:

[error] 30106#0: *1 no resolver defined to resolve somehost.dev, client: 127.0.0.1, server: *.dev, request: "GET /favicon.ico HTTP/1.1", host: "somehost.dev", referrer: "http://somehost.dev/admin" 

Be careful. Warning: This web server was designed to aid application development. It may also be useful for testing purposes or for application demonstrations that are run in controlled environments. It is not intended to be a full-featured web server. It should not be used on a public network. In other words, this is almost certainly a bad idea.

If you know what you do, then have you tried Googling the error you got? Literally the first result for a search of ‘no resolver defined to resolve’ tells you you might need to set a resolver

1 Answer 1

Add resolver 127.0.0.1; to your config, replacing 127.0.0.1 with your DNS server(s) in your setup if you are not running DNS locally.

Nginx Resolver Info:

Syntax: resolver address . [valid=time] [ipv6=on|off]; Default: — Context: http, server, location 

Configures name servers used to resolve names of upstream servers into addresses, for example:

An address can be specified as a domain name or IP address, and an optional port (1.3.1, 1.2.2). If port is not specified, the port 53 is used. Name servers are queried in a round-robin fashion.

Before version 1.1.7, only a single name server could be configured. Specifying name servers using IPv6 addresses is supported starting from versions 1.3.1 and 1.2.2.

By default, nginx will look up both IPv4 and IPv6 addresses while resolving. If looking up of IPv6 addresses is not desired, the ipv6=off parameter can be specified.

Resolving of names into IPv6 addresses is supported starting from version 1.5.8.

By default, nginx caches answers using the TTL value of a response. An optional valid parameter allows overriding it:

resolver 127.0.0.1 [::1]:5353 valid=30s; 

Before version 1.1.9, tuning of caching time was not possible, and nginx always cached answers for the duration of 5 minutes.

Syntax: resolver_timeout time; Default: resolver_timeout 30s; Context: http, server, location 

Sets a timeout for name resolution, for example:

Источник

no resolver defined to resolve localhost

Description (last modified by stefankaerst.web.de@… )

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

[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 stefankaerst.web.de@… , 17 months ago

comment:2 by Maxim Dounin , 17 months ago

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.

comment:3 by stefankaerst.web.de@… , 17 months 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

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 😉

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

comment:4 by Maxim Dounin , 16 months 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:

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

follow-up: 6 comment:5 by stefankaerst.web.de@… , 16 months ago

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.

in reply to: 5 comment:6 by nara3m , 15 months 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»

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.

Download in other formats:

Источник