我這裡的兩台後端web服務器，他們的主頁文件均為一個test.php程序，該程序分別sleep了2秒和5秒，等於和超過了proxy_read_timeout的時間，[max_fails=0] 即關閉後端服務器健康檢查。[proxy_next_upstream error timeout] 說明碰到錯誤或超時的情況切到下一個後端服務器。 如此設置後利用curl命令對nginx發起連接請求，看nginx會作何反應。

（1）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer}www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 02:43:08 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

4.008:0.002:4.007

說明：

連續請求3次後得到的http返回結果是一樣的，均為504 Gateway Time-out 錯誤。 這種情況只有在後端服務器都有問題的時才會出現這個錯誤，很顯然我這裡的proxy_read_timeout設置的時間太短，後端程序還沒來得及把程序執行完，nginx就迫不及待的將請求甩給upstream定義的另一台服務器上了，當發現另外一台服務器同樣2秒沒有返回後，nginx這回沒有服務器可用，只有返回504 Gateway Time-out 。 這也是為什麼最後的time_total時間是4秒。 （經查看兩台web服務器的訪問日誌得知，均有一條訪問記錄，且返回代碼為200，說明nginx確實來過，但沒有等到執行完成就匆匆的離去了）如果我有3台服務器，在保證任何不變的情況下，time_total時間一定會是6秒，因為nginx會一個接一個的將3台服務器都走一遍。

————————————————– ————————————————– ——————-

好了，確認是我proxy_read_timeout設置時間太短後，我將它的值設置為3秒，再通過curl命令訪問：

（2）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 03:07:58 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

5.042:0.005:5.042

說明：通過3次連續請求，得到的結果是一樣的，RS:Web1 也就是說我這三次的請求都甩到了web1上。 但我web1中的程序只需要2秒後就可以返回結果，但為什麼我通過nginx代理後時間總是我的程序執行時間+proxy_read_timeout時間呢？

————————————————– ————————————————– ——————-

繼續將proxy_read_timeout設置為4s

（3）curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 03:15:25 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

6.004:0.000:6.004

三次請求後結果也是一樣，這次花的時間更長了，但確實是程序執行時間+proxy_read_timeout 時間。 但為什麼每次都需要6秒呢？ 按照upstream中定義的權重應該是平分請求的，最起碼應該有2秒的時候。 經過分析得知：最終返回給用戶請求的是web1，那麼當再次請求的時候一定會分給web2，由於web2是sleep 5秒的，因此經過proxy_read_timeout的時間（4s）後會跳到web1，結果還是web1返回的請求，所花時間就是nginx在web2等待的時間+web1執行的時間，以此類推下一次nginx自然的還會分給web2……。 如果有更多的後端web，則判斷下一個請求服務器可以看當前返回給最終用戶的是那台服務器，然後根據upstream中定義的順序向下查詢（權重一樣的情況）

（1）上面的三次測試分別將proxy_read_timeout的值設置為2s、3s、4s的情況進行的。 最終的測試結果也都在後面做了解釋與說明。 由於我關閉了後端服務器的健康檢查（max_fails=0）因此判斷後端服務器情況的唯一依據便是proxy_read_timeout參數，如果這個參數設置得過小，但後端程序的執行或多或少會超過這個時間的話，這種情況nginx的效率是非常低的。

（2）上面的測試都是後端服務器正常但執行超時的情況下nginx根據proxy_read_timeout和proxy_next_upstream的值來選擇下一個服務器，那如果我後端服務器直接報錯的情況呢？ 可以想到如果報錯信息在proxy_next_upstream 中有定義的話nginx還會跳到下一台服務器。 否則直接將保存信息返回給nginx從而最終呈獻給用戶

開啟了後端服務器健康檢查
proxy_read_timeout 2s （下面會隨著測試變更）
Web1程序仍然sleep 2s
修改了Web2程序，讓他直接返回500錯誤

（1）連續測試三次結果如下：

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:48 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

2.005:0.001:2.005

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 502 Bad Gateway
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:50 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 173
Connection: keep-alive

0.001:0.001:0.001

curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 504 Gateway Time-out
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:01:57 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 183
Connection: keep-alive

2.005:0.001:2.005

說明：

第1次請求所用時間是2秒，web1執行超時，web2返回了500錯誤，upstream沒有更多的後端，因此nginx直接把504扔出來了，同時標記web2，web1不可用。 查看後端2台web服務器的訪問日誌，均有nginx代理的訪問記錄。
第2次請求時間很短，報502錯誤，說明沒有可用的後端服務器接受請求。 查看後端兩台web服務器訪問日誌，沒有任何變化，說明這兩台服務器被nginx標記為不可用，沒有把請求轉向後端，直接返回用戶502錯誤
第3次請求同第1次

（2）修改proxy_read_timeout 3s 連續訪問6次後結果以及2台web服務器的日誌情況
curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} www.test.com/test.php
HTTP/1.1 200 OK
Server: nginx/0.7.65
Date: Tue, 18 May 2010 07:30:15 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.1.6
RS: Web1

2.003:0.001:2.002

訪問日誌

Web1
[18/May/2010:15:30:00
[18/May/2010:15:30:03
[18/May/2010:15:30:05
[18/May/2010:15:30:08
[18/May/2010:15:30:11
[18/May/2010:15:30:13

Web2

[18/May/2010:15:30:00
[18/May/2010:15:30:11

說明：

由訪問日誌可知：
第1次請求是被分到web2上的，由於它返回了500錯誤，因此請求被轉到web1，並標記web2不可用。
第2次至第4次均將請求給了web1，第四次請求完畢後距第一請求已經過去了8秒。
第5次請求時已經是fail_timeout參數默認的10s也就是標記web2不可用的時間已經過去了，因此在第5次訪問實際上和第一次情況是一樣的。

（1）proxy_next_upstream參數很有用，他可以避免很多錯誤
（2）max_fails參數在繁忙的大型系統中建議設置為3，如果沒有幾個後端服務器的話保持默認即可。
（3）proxy_read_timeout要根據自身程序而定，不要過大，也不要太小。 如果是php程序，請參照php.ini中的max_execution_time選項值。