一次nginx引起的线上502故障

今天突然接到某PM的求救，说微信支付到应用的请求一直返回502，于是初步了解完情况后，就进入了问题排查阶段。

nginx verison 1.10.2

1，查看Nginx error.log，异常信息为

upstream prematurely closed connection while reading response header from upstream
从上游读取响应头时，上游提前关闭连接

根据日志信息初步判断为nginx在等待tomcat响应时，关闭了连接。导致此问题出现的原因，初步猜测为请求超时或返回响应体过载！

2，排查应用是否正常，验证方式：浏览器直接访问验证。结果：【正常】

3，排查Nginx到应用服务器目标端口网略是否正常，验证方式：从Nginx服务器telnet 应用服务器ip和端口。结果：【正常】

通过这两步排查，排除了应用故障及网络故障。那么开始验证是否是请求超时！

4，修改Nginx nginx.conf ，在对应的映射位置加入如下参数：

#表示与后端服务器连接的超时时间，即发起握手等候响应的超时时间。一般建议不要超过75s，默认时间60s。
 proxy_connect_timeout 90;
 #表示后端服务器的数据回传时间，即在规定时间之内后端服务器必须传完所有的数据，否则，Nginx将断开这个连接。默认时间60s。 
proxy_send_timeout 90; 
#设置Nginx从代理的后端服务器获取信息的时间，表示连接建立成功后，Nginx等待后端服务器的响应时间，其实是Nginx已经进入后端的排队之中等候处理的时间。默认时间60s。 
proxy_read_timeout 90;

再重启执行 nginx -s reload 后，依然不行不管用，感觉到之前的猜测有一点打脸，顿时心里一万只羊驼跑过。不过还好，咱还有第二个猜测啊，那就是返回响应体过载。最后的一根稻草，给点面子呀~！

于是乎，在nginx.conf 的添加如下参数：

#设置缓冲区大小，默认该缓冲区大小等于指令proxy_buffers设置的大小。
 proxy_buffer_size 4k; 
#设置缓冲区的数量和大小。Nginx从代理的后端服务器获取的响应信息，会放置到缓冲区。 
proxy_buffers 4 32k; 
#用于设置系统很忙时可以使用的 proxy_buffers 大小， 官方推荐的大小为 proxy_buffers*2。 
proxy_busy_buffers_size 64k;

重启完nginx后，啪啪打脸~！难道是修改的值不够大？于是把每个数值都乘以100倍~！果然！不！管！用！此时已经怀疑人生了！

emmm，上网查资料，90%的跟老夫的猜测都是一致的！解决方案也是一致的。为毛到我这不好使呢？omg！wtf！

在经过3个小时的绝望后，就去吃饭了。没想到吧，哈哈，哥不陪你玩了（开玩笑）！吃完饭后，突然意识到一个问题，就是！吃饱了脑子就好使了！说正题，tomcat默认采用的协议为 HTTP/1.1,而nginx默认用的是 HTTP/1.0。而HTTP/1.0是不支持keepalive,这样就不能保持活跃连接了啊~！

在酒足饭饱后的第三次猜测，会不会再次打脸呢？答案是肯定是好用的。

答案揭晓时刻：

proxy_http_version 1.1; 
proxy_set_header Connection "";

Nginx默认使用HTTP1.0从后端获取响应返还给客户端，但是HTTP/1.0不支持keepalive，因此需要配置proxy_http_version 1.1，proxy_set_header Connection默认close：通知后端服务器主动关闭连接，这样会导致任何一个客户端的请求都在后端服务器上产生了一个TIME-WAIT状态的连接。

问题成功解决！突然发现羊驼也是很可爱的！