nginx響應超時，報錯：upstream timed out (110: Connection timed out) while reading response header from upstr

• 問題描述：
  • [error] 29605#0: *1 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 125.118.102.87, server: www.amai1.com, request: "GET /account/signin HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "www.amai1.com"
  • 日誌文件生成的錯誤信息有必定的時間延遲
  • 報錯信息：
  • 請求日誌（同一時間點有多個請求）
• 解決方法：
• 根據報錯信息查看網上的大部分的緣由是：nginx proxy的超時時間過短等nginx配置的優化等，可是修改了以後，依然報一樣的錯誤
• 根據請求日誌的信息：
  • 上述能夠看到在同一個時間點出現了兩個請求，而且一個成功，一個失敗，而且訪問日誌有不少499響應碼的請求。而499響應碼是說/* 499, client has closed connection */.就是說客戶端主動關閉了鏈接，或者nginx兩次提交post間隔過快也會出現此問題。

      一、客戶端主動關閉鏈接，是由於過了設置的超時時長就會關閉鏈接。這個又回到了10s的超時時長和頻繁的發生time out現象的問題上了。

      二、提交POST請求過快，nginx會認爲屬於不安全的請求，便主動拒絕鏈接。這個有多是客戶端那邊不間斷的測試數據致使，對於這種狀況，能夠對nginx的配置文件進行配置如下參數來進行不主動關閉。proxy_ignore_client_abort on;（不安全的方式），可是問題依然未解決


• 最後發現是redis服務器過時了，尷尬了一批，從新續期後，系統恢復了，搞定。
• 試了一下，數據庫服務器鏈接失敗,session服務器過時一樣會報上面的錯誤，因此之後報這樣的錯，能夠看一下是不是數據庫，session，redis服務器是否過時
• 參考文檔：http://blog.51cto.com/chenpipi/1682450