今天在下面的这个 NGINX 例子配置文件里里看到一个有意思的观点，就是如果后端是一个动态程序，那么 upstream 的 fail_timeout 应该设置为 0 ：

https://bogomips.org/unicorn/examples/nginx.conf

upstream app_server {
  ...
  server 192.168.0.7:8080 fail_timeout=0;
  ...
}

fail_timeout 的默认值是 10 秒，配合默认值为 1 的 max_fails 参数，意思是如果在 fail_timeout 期间后端失败了 max_fails 次，那么就将这个后端标识为不可用，在接下来的 fail_timeout 期间， NGINX 不会再将请求分配到这个后端。

如果将 fail_timeout 设置为 0 ，那么无论后端失败了多少次， NGINX 会继续把请求分发到这个后端服务器地址。

如果后端是一个动态程序，比如 Python 或者 Node.js ，那么就应该将 fail_timeout 设置为 0 ，这样即使后大带宽服务器端偶尔抛出一个 500 错误，那么也不应该暂停服务。在动态应用中，出现偶尔的 500 错误是很正常而且几乎无法避免的。如果后端因为某些更严重的原因一直出现 500 错误，那么这种问题其实也是任何 NGINX 配置都解救不了的。

fail_timeout 设置为 10 秒或者更长时间，可能对于静态的后端会更有意义。因为静态的后端通常很难出现 500 错误。如果出错了，一般也都是因为一些更麻烦的问题，比如硬盘坏了，或者内存满了之类，这种时候通过 fail_timeout 的值来暂时避免将请求发送到有问题的静态后端，是有意义的。

动态程序也可能硬盘坏了内存满了

这样的话，对动态程序难道不是增大 max_fails 更合理吗？

别钻牛角尖呀，重点是静态的后端很少出现 500 ，出现了也是硬盘满了之类的。
而动态出现 500 的可能很大，因为磁盘的原因 500 的概率相对来说很小很小。

这是一个坑点。仔细读文档才会发现。专业的 sa 如果不知道这个是个扣分点。
还有一个点就是用 http 1.1 和 connection keep-alive 可以提高效率。
nginx 默认给 upstream 是 connection: close

r很少出现 500 那这个功能不就没啥用么

既然认为后端的 500 是偶发现象可以接收，那就应该加大 max_fails 来支持这种偶发的。
否则真的连续故障了， nginx upstream 的自动剔除机制就废了

楼主这个理解是不正确的
1. 假如 upstream 只有一个 server ，那 max_fails 和 fail_timeout 都是没用的。
2. 假如 upstream 有多个 server ，那超过了 max_fails 次错误后，在 fail_timeout 时间内会摘除这个 server
如果全部 server 都失败， nginx 会清空这个状态，轮询所有服务器
就是说，无论怎么配置， nginx 都会保证 upstream 里有可用的 server

+1
多 server 的回源，偶发异常，加大 max_fails 就可以了，要保证 fail_timeout 能起到作用；
如果是单点回源，这两个参数就不用写了。
无论是纯静态还是动静混合的后端
应该用 proxy_next_upstream 和 proxy_cache_use_stale 保证静态资源的可用率

有的时候情况是这样的，后端其实还有处理能力，但是因为 fail_timeout 和 max_fails 的值不理想，而被浪费了。这也是为什么有时候后端明明还活着，但是错误日志里却出现 no live upstreams while connecting to upstream

受教，最近正好碰到类似问题。晚上回家试一下。

之前没有配置过 fail_timeout
看来之后要注意下这一点了. 我的后端还是比较有可能抛出 500 错误的.

可以再配合 proxy_next_upstream ，对抛 500 的请求再转给下一个 server 。
Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | non_idempotent | off ...;
Default:
proxy_next_upstream error timeout;
Context: http, server, location
Specifies in which cases a request should be passed to the next server:
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream

楼主的方法是错误的。
问题关键是不应该让 nginx 认为 500+的 http code 是错误。应当使用 proxy_next_upstream 来决定什么时候决定换 backend 。
The cases of error, timeout and invalid_header are always considered unsuccessful attempts, even if they are not specified in the directive. The cases of http_500, http_502, http_503 and http_504 are considered unsuccessful attempts only if they are specified in the directive. The cases of http_403 and http_404 are never considered unsuccessful attempts.
设置 fail_timeout 为 0 当某个后端阻塞 会有很多不必要的尝试 进而影响吞吐量

今天在某个生产环境中遇到了一个很难搞的 no live upstreams while connecting to upstream 错误，尝试了一下把 max_fails 和 fail_timeout 都设置为 0，貌似解决了。
之前是每次 upstream timed out 错误之后，就会跟一大串 no live upstreams while connecting to upstream （其实是因为这个时候 fail_timeout 的默认 10 秒等待），加入了这两个设置之后，现在只会有偶尔的 upstream timed out。

看了下源码，nginx 发现连接超时、读取超时、status code >= 300 就会尝试下一个 upstream，如果它成功就换它响应，如果它失败就自己返回失败。
所以对于动态服务器，确实应该禁用。