服務(wù)器出現(xiàn)504 Gateway Time-out的解決方法！

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

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

那到底上面是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)關(guān)或代理服務(wù)器能夠連接后端服務(wù)器，但在讀取服務(wù)器響應(yīng)的時候超時了。遇到504問題一般是后端服務(wù)的問題，比如：

后端進(jìn)程無故退出了(可能是代碼異常，也可能是apache或nginx進(jìn)程異常)，導(dǎo)致代理服務(wù)器接收不到后端響應(yīng)。

后端響應(yīng)緩慢，導(dǎo)致代理服務(wù)器接收后端響應(yīng)超時了。

服務(wù)器出現(xiàn)504 Gateway Time-out的解決方法!

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

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

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

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

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

proxy_read_timeout 60

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.

最后將該值修改為：

proxy_read_timeout 300

proxy_send_timeout 300

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

進(jìn)一步測試

感興趣的同學(xué)也可以進(jìn)一步了解nginx的proxy配置，如果沒有特殊的需求，配置非常簡單。

server {

listen 443 ssl;

server_name www.simplehttps.com;

location / {

access_log access.log main;

error_log error.log;

proxy_pass http://127.0.0.1:8080;

proxy_read_timeout 5;

}

}

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

如果遇到超時問題，觀察error.log日志，會看到以下錯誤：

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

最后經(jīng)過不斷調(diào)整nginx的proxy_read_timeout指令和后端x.php程序的執(zhí)行時間，也沒有遇到工作中遇到的問題(20秒和60秒之間不對稱的問題)，只能后續(xù)繼續(xù)留意了。

騰佑小編總結(jié)

1：網(wǎng)關(guān)和后端的超時時間(proxy或fastcgi)必須協(xié)調(diào)一致，在本案例中，apache/mod_php運(yùn)行最長時間如果是30秒，那么nginx設(shè)置的超時時間必須大于30秒，因?yàn)楸仨毧紤]網(wǎng)絡(luò)傳輸延時時間(非網(wǎng)絡(luò)包總傳輸時間);而如果是nginx+php-fpm模式，nginx設(shè)置的超時時間相對簡單，因?yàn)榇蟛糠智闆r下，nginx和php-fpm部署在同一臺機(jī)器上，網(wǎng)絡(luò)延時相對較短，但必須考慮php最大執(zhí)行時間和php-fpm最大執(zhí)行時間，

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