對(duì)于一個(gè)Web開(kāi)發(fā)者來(lái)說(shuō)，504和502問(wèn)題看上去好像很簡(jiǎn)單，每個(gè)人也可能都遇到過(guò)，但把問(wèn)題說(shuō)清楚并不那么容易，也希望這兩篇文章能夠幫助您。

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

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

問(wèn)題分析

為了把問(wèn)題說(shuō)清楚，先介紹下我單位服務(wù)部署架構(gòu)，如下圖：成都服務(wù)器托管

很多讀者看到https訪問(wèn)，猜測(cè)504問(wèn)題是不是因它而起，實(shí)際上完全沒(méi)有關(guān)系，但整個(gè)部署架構(gòu)卻因?yàn)橐肓藄sl，導(dǎo)致系統(tǒng)復(fù)雜化了。未來(lái)ssl肯定是主流，如果你這張圖的部署感興趣，可以看看我的新書《深入淺出HTTPS：從原理到實(shí)戰(zhàn)》，里面描述的很詳細(xì)，此處也算作個(gè)廣告。

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

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

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

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

4 Gateway Timeout

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

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

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

解決問(wèn)題

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

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

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

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

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

1. proxy_read_timeout 60
2. proxy_send_timeout 60

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

• 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.

介紹的很詳細(xì)了，得到這個(gè)答復(fù)我就很疑惑了，超時(shí)時(shí)間是60秒，但504在20秒的時(shí)候就產(chǎn)生了，大大的問(wèn)號(hào)懸我腦袋上，又仔細(xì)看了下官方文檔，是不是 proxy_read_timeout 參數(shù)的值寫的不嚴(yán)謹(jǐn)，官方寫的是60s，可即使寫錯(cuò)了，nginx 默認(rèn)的超時(shí)時(shí)間也是60秒;是不是nginx 版本默認(rèn)超時(shí)時(shí)間不一致?官方文檔也并沒(méi)有對(duì)該指令有特殊的說(shuō)明。

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

1. proxy_read_timeout 300
2. proxy_send_timeout 300

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

進(jìn)一步測(cè)試

由于我看不到公司代理服務(wù)器的具體配置，所以我安裝了一個(gè)代理服務(wù)器，感興趣的同學(xué)也可以進(jìn)一步了解nginx的proxy配置，如果沒(méi)有特殊的需求，配置非常簡(jiǎn)單。

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 可以是一個(gè)host、內(nèi)部域名、ip地址，不用是一個(gè)對(duì)外的域名。

如果遇到超時(shí)問(wèn)題，觀察error.log日志，會(huì)看到以下錯(cuò)誤：成都服務(wù)器托管

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"

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

總結(jié)

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

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

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

當(dāng)前題目：代理服務(wù)器和Web服務(wù)器通信中的504問(wèn)題
URL鏈接：http://vcdvsql.cn/article6/jdig.html

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

廣告

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