一、情況

當前的情況為nginx作為前端反向署理，upstream為兩臺tomcat。

二、原因

由于最近項目屬于初期階段，平日加班也較量多，恰好遇到一天沒有什么問題的時間，我早早的收拾裝備開心的坐上了地鐵奔向家里。

此時，聽著音樂的我快樂的坐在地鐵上，溘然音樂戛然而止，響起了來電的鈴音。一種欠好的預感油然而生，看來是有問題了。于是乎我拿出電話看到了我們老大的名字閃此刻手機屏幕上，深呼一口吻，接起電話。就聽見我們老大說此刻客戶端何處報錯等什么什么的。由于地鐵里雜音很大，信號又不是太好，就沒細問。橫豎就是處事器端有問題，我就先應答下來。此時的我還沒有抵家，于是就說抵家了再看。于是老大就掛了電話。我就在心里追念到底說的是什么問題，惋惜回想了半天終照舊沒有聽清說了什么。

三、排錯

抵家打開電腦，登上QQ，就看到了群里client何處再反應的問題，截圖顯示部門請求處事端的資源呈現(xiàn)了request timed out的現(xiàn)象。于是我就登岸隨處事器端。首先查察各個歷程是否正常。在確定正常之后，會見頁面測試下也是正常的。由于客戶端挪用的是接口文件，欣賞器沒有步伐直接測試會見，只能通過nginx的日志查察問題。

客戶端何處測試的是https的協(xié)議，此時就查察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的時間配置。

再次測試照舊有此問題，我仔細想了一下，溘然發(fā)明這邊測試的是https，而我修改的仿佛只是http的超時時間，于是再次修改，心里暗自感動的認為這下該OK了吧。沒想到修改完之后，客戶端何處測試照舊一樣的問題。此時就有些郁悶了。

由于我及時的再監(jiān)控著靠山日志，再次發(fā)明固然報錯，華沙機房主機 荷蘭主機，可是有些區(qū)別:

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"

可以看到日志內里的錯誤碼和報錯信息產(chǎn)生了改變。憑據(jù)這個提示，應該是upstream向nginx發(fā)送了重置的請求，這是為什么呢？

網(wǎng)上搜索了一下，發(fā)明大部門說的都照舊time out的問題，有個體說是客戶端get的頭過大，可是明明這里用的是POST要領。那照舊憑據(jù)time out去查找問題看看，于是又想客戶端何處咨詢下是否配置了超時時長，客戶端何處給的是配置了10s的超時時長。這樣看來應該也不會有問題呀。10s的環(huán)境下應該是足夠處事器處理懲罰和響應了。

此時還沒有想到問題在什么處所，只能多監(jiān)控寫日志看看，于是把http的會見日志和錯誤日志以及https的會見日志和錯誤日志都以tail的方法及時的監(jiān)控著。就在這些日志監(jiān)控傍邊，溘然發(fā)明白幾點奇怪的現(xiàn)象:

3.1、http的錯誤日志也有connection time out的現(xiàn)象