nginx: [emerg] host not found in upstream

Praveen Kumar K S praveenssit at
Wed Dec 16 13:05:49 UTC 2020


Thanks for the explanation. I will look into the options what we have at
this point.

On Tue, Dec 15, 2020 at 3:27 AM Francis Daly <francis at> wrote:

> On Mon, Dec 14, 2020 at 06:57:50PM +0530, Praveen Kumar K S wrote:
> Hi there,
> > 1. nginx fails to start when an upstream server is down or not being
> > resolved.
> "nginx fails to start when an upstream server is down" is not the
> expected behaviour.
> "nginx fails to start when an upstream server name is not being resolved"
> is the expected behaviour.
> If you have a reproducible case of the first without the second, that
> will probably be a useful bug report.
> > 2. I can't use the ipaddress because I'm running all services in docker
> > swarm. So I can only resolve using the service names.
> That's a valid setup for your use case.
> Stock-nginx does not work in those circumstances, if the upstream service
> names do not resolve when nginx starts.
> (Also: I think that stock-nginx will not try to re-resolve the names
> while it is running; so giving it "dummy" information at startup and
> changing it later, will not work.)
> > 3. Now I get your point. When nginx starts, it should resolve all
> upstream
> > servers. Else, it will fail to start.
> Correct.
> > Now, let me explain my issue. Please let me know if this is possible.
> > 1. Today I have 3 servers defined in upstream. Lets say app1,app2,app3
> > 2. Tomorrow I might scale the app by 2 more. Lets say app4,app5
> > 3. Now I want to define that [app4,app5] in my nginx configuration
> > 4. But I thought of defining app1,2,3,4,5 upfront in nginx conf and scale
> > my app whenever required. In this case, when nginx is unable to resolve
> > app4,5, it should ignore and when I scale my app, it should load balance
> > the requests to all 5.
> Step 4 is not a thing that stock-nginx can do today.
> You could potentially define your "upstream" to only include the servers
> that resolve today; and then tomorrow change it to only include the
> servers that resolve tomorrow, and invite nginx to re-read its config
> file ("reload" rather than "restart").
> Or you could potentially define your "upstream" with all 5 names if you
> know the IP addresses that they will have when they are running, and
> let nginx load-balance across whichever services are "up" at each time.
> Maybe you can find or write an external module that can get nginx to do
> what you want?
> The documentation for "upstream" is at
> On that page, there are also mentions of some dynamic features that are
> not available in stock nginx, but which are available in a commercial
> subscription. Depending on your requirements, that may or may not be
> a useful path to investigate. The fact that "dynamic configuration"
> code exists proves that it can be written, which might be inspiration
> to re-implement it, or to take advantage of what others have already done.
> Good luck with it,
>         f
> --
> Francis Daly        francis at
> _______________________________________________
> nginx mailing list
> nginx at



*K S Praveen Kumar*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list