一、情况
当前的情况为nginx作为前端反向署理，upstream为两台tomcat。
二、原因
由于最近项目属于初期阶段，平日加班也较量多，恰好遇到一天没有什么问题的时间，我早早的收拾装备开心的坐上了地铁奔向家里。
此时，听着音乐的我快乐的坐在地铁上，溘然音乐戛然而止，响起了来电的铃音。一种欠好的预感油然而生，看来是有问题了。于是乎我拿出电话看到了我们老大的名字闪此刻手机屏幕上，深呼一口吻，接起电话。就听见我们老大说此刻客户端何处报错等什么什么的。由于地铁里杂音很大，信号又不是太好，就没细问。横竖就是处事器端有问题，我就先应答下来。此时的我还没有抵家，于是就说抵家了再看。于是老大就挂了电话。我就在心里追念到底说的是什么问题，惋惜回想了半天终照旧没有听清说了什么。
三、排错
抵家打开电脑，登上QQ，就看到了群里client何处再反应的问题，截图显示部门请求处事端的资源呈现了request timed out的现象。于是我就登岸随处事器端。首先查察各个历程是否正常。在确定正常之后，会见页面测试下也是正常的。由于客户端挪用的是接口文件，欣赏器没有步伐直接测试会见，只能通过nginx的日志查察问题。
客户端何处测试的是https的协议，此时就查察https的部门日志：
2015/08/06 19:15:29 [error] 17709#0: *1380648 upstream timed out (110: Connection timed out) while sending request to upstream, client: xxx, server: www.xxxx.com, request: "POST /xxx/pub/xxx.do HTTP/1.1", upstream: "http://xxxx:8082/xxx.do", host: "www.xxxx.com:443"
2015/08/06 19:16:11 [error] 17709#0: *1380648 upstream timed out (110: Connection timed out) while sending request to upstream, client: xxx, server: www.xxxx.com, request: "POST /xxx/pub/xxx.do HTTP/1.1", upstream: "http://xxxx:8082/xxx.do", host: "www.xxxx.com:443"
2015/08/06 19:17:29 [error] 17709#0: *1380648 upstream timed out (110: Connection timed out) while sending request to upstream, client: xxx, server: www.xxxx.com, request: "POST /xxx/pub/xxx.do HTTP/1.1", upstream: "http://xxxx:8082/xxx.do", host: "www.xxxx.com:443"
2015/08/06 19:29:29 [error] 17709#0: *1380648 upstream timed out (110: Connection timed out) while sending request to upstream, client: xxx, server: www.xxxx.com, request: "POST /xxx/pub/xxx.do HTTP/1.1", upstream: "http://xxxx:8082/xxx.do", host: "www.xxxx.com:443"
日志名目就雷同上面的这些类容，看到这些，我就想到大概是nginx的proxy的一些超时时间的问题，于是就修改了time out的时间配置。
再次测试照旧有此问题，我仔细想了一下，溘然发明这边测试的是https，而我修改的仿佛只是http的超时时间，于是再次修改，心里暗自感动的认为这下该OK了吧。没想到修改完之后，客户端何处测试照旧一样的问题。此时就有些郁闷了。
由于我及时的再监控着靠山日志，再次发明固然报错，华沙机房主机 荷兰主机，可是有些区别:
2015/08/06 19:47:31 [error] 17708#0: *1381368 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: www.xxx.com, request: "POST /xxx/xxx/xxxx.do HTTP/1.1", upstream: "http://xxx.xxx.xxx:8082/xxx/home/xxx.do", host: "
2015/08/06 19:50:11 [error] 12300#0: *1381368 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: www.xxx.com, request: "POST /xxx/xxx/xxxx.do HTTP/1.1", upstream: "http://xxx.xxx.xxx:8082/xxx/home/xxx.do", host: "www.xxx.com:443"
2015/08/06 19:55:04 [error] 132648#0: *1381368 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: www.xxx.com, request: "POST /xxx/xxx/xxxx.do HTTP/1.1", upstream: "http://xxx.xxx.xxx:8082/xxx/home/xxx.do", host: "www.xxx.com:443"
可以看到日志内里的错误码和报错信息产生了改变。凭据这个提示，应该是upstream向nginx发送了重置的请求，这是为什么呢？
网上搜索了一下，发明大部门说的都照旧time out的问题，有个体说是客户端get的头过大，可是明明这里用的是POST要领。那照旧凭据time out去查找问题看看，于是又想客户端何处咨询下是否配置了超时时长，客户端何处给的是配置了10s的超时时长。这样看来应该也不会有问题呀。10s的环境下应该是足够处事器处理惩罚和响应了。
此时还没有想到问题在什么处所，只能多监控写日志看看，于是把http的会见日志和错误日志以及https的会见日志和错误日志都以tail的方法及时的监控着。就在这些日志监控傍边，溘然发明白几点奇怪的现象:
3.1、http的错误日志也有connection time out的现象
