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 192.168.0.1;
server 192.168.0.2;
}

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 "192.168.0.1" 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@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx