upstream member liveness

B.R. reallfqq-nginx at
Wed Apr 13 10:13:36 UTC 2016

I am off-topic, but Valentin I shall note you are showing a great deal of
Without any doubt your interlocutor will be glad and thankful for it, and
will demonstrate it as good as when he (quickly) becomes upset.

Btw, I do not know any Captain Evidence, only Captain Obvious.
*B. R.*

On Wed, Apr 13, 2016 at 10:05 AM, Валентин Бартенев <vbart at> wrote:

> On Wednesday 13 April 2016 00:47:14 drookie wrote:
> > Is there someone besides Captain Evidence who knows the answer ? This is
> > actually the problem of the modern internet: half of the decent
> questions is
> > flooded out by people, who not only think they know the answer, but are
> > arrogant enough to insist it, and from the point of an outer observer the
> > topic looks "answered".
> >
> [..]
> Ok, probably "fastcgi_next_upstream" in my answer misled you, since nginx
> with
> the "upstream" block for sure talks to other nginx instances by HTTP using
> "proxy_pass", then "proxy_next_upstream" would the correct answer in this
> case.
> In the configuration below:
>    upstream backends {
>        server;
>        server;
>    }
>    proxy_pass http://backends;
> nginx doesn't care (and knows nothing) about the virtual hosts presented on
> these servers in the upstream block, and don't try to differentiate
> requests
> in terms of liveness using the host header or any other parameter.
> If the "" will be recognized as dead by the rules that are
> described in the documentation, it will be considered dead for all requests
> for all hosts that use this upstream block.
> So the "member liveness" is per upstream group.
> What I also wanted to bring to your attention is that by default the 500
> response isn't recognized as a fail attempt, unless you have configured it
> using the proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream,
> or scgi_next_upstream directives (depending on the protocol).
>   wbr, Valentin V. Bartenev
> _______________________________________________
> nginx mailing list
> nginx at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list