我们使用 nginx 作为反向代理，在 2 个应用服务器之间进行负载平衡。这些应用服务器在块中定义upstream如下：
upstream app_backends {
server 1.1.1.1:8080 max_fails=1 fail_timeout=120s;
server 1.1.1.2:8080 max_fails=1 fail_timeout=120s;
}
我们曾发生过一次严重的中断，当时一个客户端发送了一个带有大型 cookie 标头的请求，uwsgi应用程序因此而阻塞并提前关闭了连接。这导致 nginx 在该后端上标记故障，然后立即将请求发送到第二个后端，后者也会以完全相同的方式阻塞。然后 nginx 会将两个后端都标记为停机，并且在502接下来的两分钟内仅响应来自所有客户端的请求。
一旦我们了解了问题所在，我们通过设置 就轻松解决了问题max_fails=0。这导致有问题的客户端（带有较大的 cookie 标头）获取502，但所有其他客户端都可以继续使用该应用程序而不会出现问题。但这当然意味着 nginx 不会为我们的后端提供任何针对故障的保护。
实际上，我们在许多不同的应用程序中都具有相同的配置，并且我试图了解我们的设置中最安全的通用配置是什么。
nginx 中这两个设置的默认值是max_fails=1和fail_timeout=10。我们的问题显然因 而加剧fail_timeout=120s，但即使是10s，每当这个带有大 cookie 头的特定客户端发出请求时，这仍然会导致我们的应用程序完全瘫痪 10 秒。
响应请求时出现单个错误（可能是像我们这样的特殊情况）导致整个后端脱机，这似乎是一种糟糕的模式？尤其是当我们不知道同一个错误是否会平等地适用于所有后端时，就像在这种情况下一样？
我想问的是：对于我们的max_fails=0所有应用程序来说，使用这样的配置通常比使用实际的 nginx 默认值更安全吗max_fails=1 fail_timeout=10s？如果是这样，这是否可能是 nginx 更改其默认值的一个理由？