​proxy_next_upstream和nginx upstream的排错逻辑可能导致的问题

proxy_next_upstream和nginx upstream的排错逻辑可能导致的问题
upstream kjh {
server 172.17.3.131:8081 max_fails=2 fail_timeout=30s;
server 172.17.3.132:8081 max_fails=2 fail_timeout=30s;
}
server
{
listen 80;
server_name report.kjh.com ;
proxy_redirect off;
location / {
1.
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
在nginx配置反向代理时，此配置对客户体验影响较大，当客户端请求一个不存在的文件，导致较长时间才能返回请求失败,虽然在真实的环境中有一定的冗余作用，如不善用弊大于利！
语法： proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]
确定在何种情况下请求将转发到下一个服务器。转发请求只发生在没有数据传递到客户端的过程中。
2.
关于max_fails参数的理解：根据上面的解释，max_fails默认为1，fail_timeout默认为10秒，也就是说，默认情况下后端服务器在10秒钟之内可以容许有一次的失败，如果超过1次则视为该服务器有问题，将该服务器标记为不可用。等待10秒后再将请求发给该服务器，以此类推进行后端服务器的健康检查。但如果我将max_fails设置为0，则代表不对后端服务器进行健康检查，这样一来fail_timeout参数也就没什么意义了。那若后端服务器真的出现问题怎么办呢？上文也说了，可以借助proxy_connect_timeout和proxy_read_timeout进行控制。
3.死循环

当设定proxy_next_upstream http_404，并且upstream里配置是max_fails=0，则访问到不存在文件时，将会有死循环现象，nginx负载明显升高，kill -HUP进程消逝很慢。同样的，proxy_next_upstream如果设定为其它值，例如http_503、invalid_header等也会有同样问题，但默认的error timeout不会出问题。

4.502 bad gateway

nginx的检测后端机制相对严格，默认的，某个后端一个失败的请求，就会令此后端暂停10秒。一般而言，不会有太多失败的请求，而且也不太可能所有机器在10秒内同时出问题；但世事总是难料，nginx->nginx的架构，常因后台服务器文件有错（通常是ssi），报出莫名其妙的错误，导致代理挂起此后端，然后proxy_next_upstream又将此请求导向下一台服务器，因此在10秒内，所有服务器都将被挂起……

解决此问题，最直接的办法是将max_fails设为0，关闭nginx屏蔽后端的功能，虽然有可能会造成死循环，但死循环还不至于很快停止服务，只是负载较高，至少可以挺一阵子。后端的错误如影响太大，还是要及时解决。

5.timeout

如果设定了max_fails=0，则某后端出了故障造成访问超时时不会被屏蔽，进而访问到此后端的请求都要等到超时才会跳到下一个后端，虽然请求最终还是成功了，但用户体验会变得很差。解决此问题的办法就是将超时时间调得很短，大概3-15秒，只要在用户（老板）能接受的范围内即可。