upstream member liveness

[Валентин Бартенев]

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