背景及简要分析

前几天一次故障定位的时候发现，后端服务(java)在从故障中恢复之后，会出现大量499，且会持续较长时间无法自行恢复。
根本原因是服务容量问题，处理太慢导致客户端等不了了，主动断开。不过分析一下直接原因大概有这几点：

1. nginx超时配置的比客户端长，导致客户端都499超时了，nginx还没超时。
2. nginx的重试机制和max_fails机制配置不当，在一定程度上加剧了后端的恶性循环。

在学习了解了nginx相关机制、参数的时候，和同事在 proxy_next_upstream 和 max_fails 这两个参数之间产生了分歧。

• 从文档的这两句来看，我认为 max_fails 和 proxy_next_upstream 是强相关的，关闭了后者，前者会失效。
• 同事则认为，这两者无关，即使关掉了重试也不会影响fails摘节点。

各执己见的情况下，自然就是上配置测试了。

nginx相关配置、参数

proxy_next_upstream

max_fails

proxy_connect_timeout

Syntax: proxy_connect_timeout time;
Default: proxy_connect_timeout 60s;
Context: http, server, location

Defines a timeout for establishing a connection with a proxied server. It should be noted that this timeout cannot usually exceed 75 seconds.
http://nginx.org/en/docs/http...

本次的大量499问题就是这个连接超时配置不当的锅。
之前配置为3秒，也就是说如果一个上游服务有问题时，客户端必须等3秒以上。这还只是建立连接的时间。
从日志中推测，客户端的超时时间应该在3-6秒之间（应该是5s）【由于客户端不是app所以和一般的客户端超时不同】

nginx和服务如果都是内网的、同IDC，建立连接很快(ms级别)，这个参数不必设置的太大。个人认为应该在500ms以下。当然，如果后端服务是外网的则另当别论了。
个人认为，服务端的超时时间应当是比客户端短的，这样在服务端某个节点有问题的时候，nginx还有时间去重试下一台。

proxy_[send/read]_timeout

测试过程

nginx版本: tengin 2.2.0
nginx参数：

结论