![在 Nginx 反向代理中配置 `max_fails` 的最安全方法](https://linux22.com/image/793012/%E5%9C%A8%20Nginx%20%E5%8F%8D%E5%90%91%E4%BB%A3%E7%90%86%E4%B8%AD%E9%85%8D%E7%BD%AE%20%60max_fails%60%20%E7%9A%84%E6%9C%80%E5%AE%89%E5%85%A8%E6%96%B9%E6%B3%95.png)
我们使用 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 更改其默认值的一个理由?