代理服務器和Web服務器通信中的504問題

對于一個Web開發(fā)者來說，504和502問題看上去好像很簡單，每個人也可能都遇到過，但把問題說清楚并不那么容易，也希望這兩篇文章能夠幫助您。

十年的襄城網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。營銷型網(wǎng)站的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調整襄城建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。創(chuàng)新互聯(lián)建站從事“襄城網(wǎng)站設計”,“襄城網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

兩臺設備只要通過proxy或fastcgi協(xié)議互相通信，都會遇到504問題，比如Nginx+PHP-FPM會遇到;代理服務器連接后端Web服務也會遇到。我本次遇到的場景屬于后者，重點講解代理導致的504問題。

問題分析

為了把問題說清楚，先介紹下我單位服務部署架構，如下圖：成都服務器托管


很多讀者看到https訪問，猜測504問題是不是因它而起，實際上完全沒有關系，但整個部署架構卻因為引入了ssl，導致系統(tǒng)復雜化了。未來ssl肯定是主流，如果你這張圖的部署感興趣，可以看看我的新書《深入淺出HTTPS：從原理到實戰(zhàn)》，里面描述的很詳細，此處也算作個廣告。

在本文引入這張圖的根本原因是想讓讀者能夠清晰的了解我遇到的問題，如果沒有這張圖，讀者在理解的時候會很困難。但也不要想的過于復雜，簡單理解就是nginx作為代理服務器連接后端的web服務器(apache/mod_php)。

接下來描述具體遇到問題，在瀏覽器中訪問https://mail.sina.net/x.php的時候，該接口上傳文件然后存儲到阿里云OSS上，如果傳輸?shù)奈募浅４?，?zhí)行時間將會很長，一旦到20秒到時候，必然會出現(xiàn)出現(xiàn)504錯誤，具體如下圖：成都服務器托管



順帶說一下，其他頁面和接口沒有遇到該問題，在那一刻會懷疑是不是x.php程序處理有問題(大部分人會這么理解)。

那到底上面是504錯誤呢，看下wiki的引用：成都服務器托管

4 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server

它的意思就是一個網(wǎng)關或代理服務器能夠連接后端服務器，但在讀取服務器響應的時候超時了。遇到504問題一般是后端服務的問題，比如：成都服務器托管

  • 后端進程無故退出了(可能是代碼異常，也可能是apache或nginx進程異常)，導致代理服務器接收不到后端響應。
  • 后端響應緩慢，導致代理服務器接收后端響應超時了。

解決問題

按照上述可能的兩個情況，逐一分析。

(1)x.php程序在特定的情況下，確實運行緩慢，但apache的access log在25秒左右的時候成功記錄了200訪問日志(由于php代碼執(zhí)行結束后才記錄日志，一開始可能看不到access日志，導致開始誤認為是后端程序的問題)。

(2)在x.php程序中記錄應用日志，應用日志和access log日志一樣，沒有任何異常。

這說明代碼并沒有問題(但程序執(zhí)行時間過長，有優(yōu)化的空間)，雖然在20秒產(chǎn)生504錯誤(由nginx處理)，后端代碼進程仍然繼續(xù)運行，并在25秒成功運行。

排除這個問題后，最有可能是代理服務器覺得后端響應過于緩慢，主動關閉了該連接，是不是代理服務器設置的超時時間過短?由于公司的代理服務器(ssl nginx)是由專人維護的，我看不到具體的配置，郵件詢問了同事，得到回復如下：成都服務器托管


  1. proxy_read_timeout 60
  2. proxy_send_timeout 60

首先看下 proxy_read_timeout 的官方介紹：成都服務器托管

  • Defines a timeout for reading a response from the proxied server. The timeout is set only between two successive read operations, not for the transmission of the whole response. If the proxied server does not transmit anything within this time, the connection is closed.

介紹的很詳細了，得到這個答復我就很疑惑了，超時時間是60秒，但504在20秒的時候就產(chǎn)生了，大大的問號懸我腦袋上，又仔細看了下官方文檔，是不是 proxy_read_timeout 參數(shù)的值寫的不嚴謹，官方寫的是60s，可即使寫錯了，nginx 默認的超時時間也是60秒;是不是nginx 版本默認超時時間不一致?官方文檔也并沒有對該指令有特殊的說明。

最后同事將該值修改為：成都服務器托管


  1. proxy_read_timeout 300
  2. proxy_send_timeout 300

問題最終解決了，肯定是proxy讀取超時了，但具體的配置仍然讓我疑惑。

進一步測試

由于我看不到公司代理服務器的具體配置，所以我安裝了一個代理服務器，感興趣的同學也可以進一步了解nginx的proxy配置，如果沒有特殊的需求，配置非常簡單。


  1. server {
  2. listen 443 ssl;
  3. server_name www.simplehttps.com;
  5. location / {
  6. access_log access.log main;
  7. error_log error.log;
  9. proxy_pass http://127.0.0.1:8080;
  10. proxy_read_timeout 5;
  11. }
  12. }

proxy_pass 可以是一個host、內部域名、ip地址，不用是一個對外的域名。

如果遇到超時問題，觀察error.log日志，會看到以下錯誤：成都服務器托管


  1. 2018/09/19 21:01:19 [error] 17034#0: *253 upstream timed out(110: Connectiontimed out) while reading response header fromupstream, client: *.*.*.*, server: www.simplehttps.com, request: "GET /x.php HTTP/1.1", upstream: "http://*.*.*.*:8080/x.php", host: "www.simplehttps.com"

最后我不斷調整nginx的proxy_read_timeout指令和后端x.php程序的執(zhí)行時間，也沒有遇到工作中遇到的問題(20秒和60秒之間不對稱的問題)，只能后續(xù)繼續(xù)留意了。成都網(wǎng)站建設公司

總結

1：網(wǎng)關和后端的超時時間(proxy或fastcgi)必須協(xié)調一致，在本案例中，apache/mod_php運行最長時間如果是30秒，那么nginx設置的超時時間必須大于30秒，因為必須考慮網(wǎng)絡傳輸延時時間(非網(wǎng)絡包總傳輸時間);而如果是nginx+php-fpm模式，nginx設置的超時時間相對簡單，因為大部分情況下，nginx和php-fpm部署在同一臺機器上，網(wǎng)絡延時相對較短，但必須考慮php大執(zhí)行時間和php-fpm大執(zhí)行時間，后續(xù)我會寫一篇關于php-fpm和php之間協(xié)調工作的文章。

2：針對5**錯誤，可認為都是http錯誤碼，都是服務器端的錯誤(相對于客戶端)，在遇到相關錯誤的時候，我們必須根據(jù)錯誤碼判斷可能存在的問題，然后再針對性的排查，否則排查時間會增加很多。

創(chuàng)新互聯(lián)客戶idc服務中心，提供成都服務器托管、成都服務器、成都主機托管、成都雙線服務器等業(yè)務的一站式服務。通過各地的服務中心，我們向成都用戶提供優(yōu)質廉價的產(chǎn)品以及開放、透明、穩(wěn)定、高性價比的服務，資深網(wǎng)絡工程師在機房提供7*24小時標準級技術保障。

當前題目：代理服務器和Web服務器通信中的504問題
URL鏈接：http://muchs.cn/article6/jdig.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供標簽優(yōu)化、外貿網(wǎng)站建設、域名注冊、網(wǎng)站維護、網(wǎng)頁設計公司、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

成都網(wǎng)站建設