proxy_upstream_next while no live upstreams

Wu Bingzheng wubingzheng at 163.com
Wed May 10 14:27:16 UTC 2017


Thanks for the answer.

Maybe you miss something in Question 2. The server 192.168.0.5 never fails.
I think nginx should not return 502 if there is at least one server never fails.
Exactly speaking, the server never fails in the last 1 hour and the fail_timeout is the default 10 second.




>> Question 2: (not related with Question 1)
>> In my production environment, 192.168.0.5 is UP, and 192.168.0.6 
>> is DOWN.
>> There are few access logs with $upstream_addr as "192.168.0.6, 
>> test", and $status as 502.
>> There were no error logs of connecting/reading 192.168.0.5 fails 
>> which mean this server is UP, so I think the request should try 
>> 192.168.0.5 after 192.168.0.6.
>> But it does not try 192.168.0.5, and just log "no live upstream" 
>> and return 502.
>> The logs like this are very few, and I can not re-produce this 
>> or debug it.
>> I just ask it here in case someone else know the problem.
>
>See above, this is exactly what is expected to happen when a 
>request to upstream server fails.  The 502 / "no live upstream" 
>you are seeing is a result of all servers considered unavailable.  
>There are only few such errors as you are using nginx 1.8.1, which 
>quickly resets failure counters of all servers in such situation.  
>With recent nginx versions, 502 errors will be returned till 
>fail_timeout expiration.
>
>If you want nginx to completely ignore errors on the only working 
>upstream server in your environment, consider using "server ... 
>max_fails=0".  Alternatively, consider using fail_timeout which is 
>appropriate for your environment.
>
>-- 
>Maxim Dounin
>http://nginx.org/
>_______________________________________________
>nginx mailing list
>nginx at nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170510/45b197cb/attachment.html>


More information about the nginx mailing list