<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Waow.<br>I am off-topic, but Valentin I shall note you are showing a great deal of patience.<br>Without any doubt your interlocutor will be glad and thankful for it, and will demonstrate it as good as when he (quickly) becomes upset.<br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)"><br>Btw, I do not know any Captain Evidence, only Captain Obvious.<br></div><div class="gmail_extra"><div><div class="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Wed, Apr 13, 2016 at 10:05 AM, Валентин Бартенев <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday 13 April 2016 00:47:14 drookie wrote:<br>
> Is there someone besides Captain Evidence who knows the answer ? This is<br>
> actually the problem of the modern internet: half of the decent questions is<br>
> flooded out by people, who not only think they know the answer, but are<br>
> arrogant enough to insist it, and from the point of an outer observer the<br>
> topic looks "answered".<br>
><br>
[..]<br>
<br>
Ok, probably "fastcgi_next_upstream" in my answer misled you, since nginx with<br>
the "upstream" block for sure talks to other nginx instances by HTTP using<br>
"proxy_pass", then "proxy_next_upstream" would the correct answer in this<br>
case.<br>
<br>
In the configuration below:<br>
<br>
   upstream backends {<br>
       server 192.168.0.1;<br>
       server 192.168.0.2;<br>
   }<br>
<br>
   proxy_pass <a href="http://backends" rel="noreferrer" target="_blank">http://backends</a>;<br>
<br>
nginx doesn't care (and knows nothing) about the virtual hosts presented on<br>
these servers in the upstream block, and don't try to differentiate requests<br>
in terms of liveness using the host header or any other parameter.<br>
<br>
If the "192.168.0.1" will be recognized as dead by the rules that are<br>
described in the documentation, it will be considered dead for all requests<br>
for all hosts that use this upstream block.<br>
<br>
So the "member liveness" is per upstream group.<br>
<br>
What I also wanted to bring to your attention is that by default the 500<br>
response isn't recognized as a fail attempt, unless you have configured it<br>
using the proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream,<br>
or scgi_next_upstream directives (depending on the protocol).<br>
<br>
  wbr, Valentin V. Bartenev<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</blockquote></div><br></div></div>