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