1.背景

本文主要是寫的最近比較影響深刻的一次排查客戶訪問業務前端域名，報504，timeout錯誤問題的記錄，該客戶為私有化部署，給客戶部署的服務存在跨洲調用，沒有專線，澳洲調用歐洲的服務情況，可能存在網絡延遲比較大，需要排查504的具體原因，然后通過優化參數臨時解決。

2.排查步驟和思路

2.1 故障現象溝通

對于toB的客戶來說，通常在使用我們產品的時候，報錯只會反饋一個截圖，我們需要向客戶溝通或者關鍵的信息，有利于問題排查。

比如：

• 打開的什么頁面，便于自己復現
• 具體報錯的接口是哪個？
• 大概的報錯時間
• 如果有x-request-id，拿到請求id
• 具體報錯的url

2.2 梳理整個訪問請求的鏈路

我們需要了解，瀏覽器上的請求鏈路，才能更好的去排查問題，比如我遇到的這個問題，請求鏈路是這樣的。

客戶機器訪問瀏覽器域名  -> 私有端域名cdn(1)  -> 私有端 SLB(2) -> 私有端 nginx(3)-> saas端服務域名cdn (4) -> saas端 SLB (5) -> saas 端nginx(6) -> saas端業務后端服務。

每個公司的業務情況不一樣，根據自己的實際情況梳理。

2.3 查看日志

• 第一次問題排查

通過第一步故障現象的溝通，獲取的內容，然后去看鏈路上nginx(3)，即私有端nginx的日志，想確認請求是否到達了服務器，根據 x-request-id搜索到日志，時間點和path也能對上，狀態碼是504，請求時間是30s，頁面多次刷新都是30s超時。

于是檢查nginx上的配置，發現該接口location里面的后端服務器響應時間，proxy_read_timeout時間設置為30s，相當于nginx會等待30s的時間來獲得請求的響應，如果在30s內如果響應接收不完，就會報出來504 timeout。

于是，修改了將進行proxy_read_timeout時間修改為了300s，然后reload一下nginx。

• 第二次問題排查

客戶反饋訪問頁面依賴報錯504，timeout，于是繼續看nginx的日志，懷疑是不是沒生效，但是查看日志之后發現報錯狀態碼變了，是499，并且都是request_time為60s，其實就相當與客戶端的請求打到了Nginx上，Nginx把請求轉到后轉服務器A，由于nginx的proxy_connect_timeout 超時時間默認的60s，就會導致Nginx把客戶端的請求轉到服務器A的時候，就會嘗試連接60s，而客戶端的響應時間設的是30s，所以造成客戶端造成大量超時情況，Nginx報大量的499。

。然后經過查閱之后，發現需要增加參數proxy_ignore_client_abort修改為on，想看看真實情況，于是在報錯的location下增加了之后reload了nginx。

繼續觀察日志，發現日志又變了，是報504 180s。

此時開始懷疑是nginx之后的saas端nginx的的問題，然后根據 x-request-id搜索到日志，發現請求確實到了saas端，但是很明顯，日志打印出來的200，請求時長是60s。

于是根據上面的鏈路情況，懷疑到了saas端和私有端的saas端slb (5) 上，經過客戶核實，他們用的阿里云的slb，默認的最大連接請求超時時間為180s，基本上和私有端的nginx里面的日志大量出現180s超時能對應上。

于是提工單給阿里云客服，咨詢是否可以調大，結論是不可以，監聽器http和https協議的最大只能180s（其實人家是有道理的，這完全是由于我們私有端在澳洲，saas端在歐洲，跨洲訪問的結果），但是客服說可以采用tcp協議，能夠支持900s，于是新建了一個tcp協議的監聽器，連接超時時間也設置為350s（為了與nginx上的proxy_read_timeout區別開），然后把私有端的upstrem轉發的地址端口改成新的測試，客戶答復訪問正常。

• 第三次問題排查

是我太天真了，以為完全解決了，但是第二天客戶反饋，隨機性還是會出現504超時，期間讓客戶用瀏覽器無痕模式打開，清理瀏覽器緩存，依舊偶爾出現，影響客戶體驗，因此有了第三次問題排查。

依舊先去查看私有端nginx的日志，無異常，狀態碼都是200，只是請求響應時間比較長超過60s了。

查看saas端的nginx日志也是正常的。

然后就不理解了，問題出在哪里，然后讓客戶如果再次出現，就把報錯接口的copy url出來，然后手動在服務器請求url，能夠復現出來504，并且是nginx給返回的。

于是在私有端一邊手動請求，一邊tcpdump抓包，發現也是正常的tcp三次握手連接，http正常請求返回，無異常。

但是在請求返回的數據上，發現了一個端倪，server并不是nginx，我們的nginx因為修改過名字，叫Sws，所以剛才請求的時候nginx 504 timeout，不是我們業務側返回的，然后就懷疑到了請求鏈路上私有端 SLB(2) 上，于是找客戶確認，訪問的域名雖然走了cdn加速，但是會回源到這個slb上，然后監聽器的連接超時時間設置的的確是60s，然后客戶修改成180s，之后兩天沒有出現過超時的問題了。

3.排查過程中的知識點

3.1 在nginx中 499狀態碼的定義和處理方法

• 查看Nginx源碼

當客戶端主動關閉鏈接時，http狀態代碼中沒有可以表示該狀態的，但在nginx又需要記錄，所以自定義了一個499這個狀態來表示。

*
* HTTP does notdefine the code for the case when a client closed
* the connectionwhile we are processing its request so we introduce
* own code to logsuch situation when a client has closed the connection
* before we even tryto send the HTTP header to it
* 
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST 499

所以顯然，客戶端端主動關閉請求或者客戶端網絡斷掉時，于是nginx就記錄了499狀態，并且斷開了和后面服務端的連接（這樣可能導致服務端返回數據時，因為連接斷開而報錯）。

• 解決499問題
• 查看服務端為什么響應這么慢，是否需要優化，或者調大客戶端方的連接超時時間，不那么快斷開
• proxy_ignore_client_abort參數調整。

這個參數表示忽略客戶端終止情況，默認為off關閉狀態，當客戶端網絡中斷請求時，nginx 服務器中斷其對后端服務器的請求，并立即記錄 499 日志。

設置為 on 開啟，則nginx會忽略客戶端中斷，并一直等著代理服務執行返回，記錄后端返回的請求的狀態。

location =/api { 
            proxy_ignore_client_abort   on; 
            proxy_pass  http://service_backends;
        }

這個參數的意思是：在客戶端主動關閉連接后， nginx 與分發服務器的連接是否保持連接。如果參數設置了on，則客戶端如果斷開連接，nginx也不會斷開與后端服務端的連接，nginx會等待后端處理完(或者超時)，然后記錄「后端的返回信息」到日志。所以，如果后端返回 200，就記錄 200 ；如果后端放回 5XX ，那么就記錄 5XX 。如果超時(默認60s，可以用 proxy_read_timeout 設置)，Nginx 會主動斷開連接，記錄 504。

注意：開啟后nginx只會在讀取超時時關閉連接，默認為60s，可能出現請求連接擠壓的情況，所以默認情況下是關閉。如果開啟必須設置好proxy_read_timeout超時時間，并且nginx最好別做反向代理以外的事情。

這個方案只是解決了兩個問題：（1）nginx上499的錯誤（2）服務端因為連接斷開報Broken pipe的錯誤。

所以最好的方法還是優化服務端。

3.2 nginx中的時間解釋

這個時間有沒有取決于nginx的日志格式log_format里是否配置

• request_time:指的就是從接收用戶請求的第一個字節到發送完響應數據的時間，即$request_time 包括接收客戶端請求數據的時間、后端程序響應的時間、發送響應數據給客戶端的時間。(request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client 。)
• up_resp_time/upstream_response_time:指nginx從后端獲取結果的處理時間，從nginx和后端建立連接開始，到關閉連接為止，連接的后端地址為upstream_addr值。(keeps times of responses obtained from upstream servers; times are kept in seconds with a milliseconds resolution. Several response times are separated by commas and colons like addresses in the $upstream_addr variable)。
• up_addr/upstream_addr:后端服務地址。
• request_time時間肯定是要比up_resp_time要大的。

3.3 nginx中proxy相關的參數解釋

proxy_connect_timeout :后端服務器連接的超時時間_發起握手等候響應超時時間(代理連接超時)默認60s

proxy_read_timeout:它決定了nginx會等待多長時間來獲得請求的響應(代理接收超時)默認值60s

proxy_send_timeout :后端服務器數據回傳時間_就是在規定時間之內后端服務器必須傳完所有的數據(代理發送超時)默認值60s

4.總結

• 當前修改配置參數實際上屬于非標準操作，本文只是提供一個自己在排查過程的思路方向，每個問題的情況和背景不一樣，需要各自結合實際情況來調整。
• 該問題主要還是跨洲訪問，沒有走專線，網絡這邊不穩定會導致在請求的時候出現超時問題，然后根據具體的問題現在通過調整配置來臨時解決這個問題，讓客戶能正常使用，客戶是上帝。
• 不要畏懼問題，所有的問題總能找到原因，不能一味的歸結到是網絡的問題，重啟大法來解決，我們其實可以定位得更細，需要知其然知其所以然。