​proxy_next_upstream和nginx upstream的排錯邏輯可能導緻的問題

proxy_next_upstream和nginx upstream的排錯邏輯可能導緻的問題

     upstream  kjh {                                                                                                                                      

             server   172.17.3.131:8081 max_fails=2 fail_timeout=30s;                

             server   172.17.3.132:8081 max_fails=2 fail_timeout=30s;                

                  }

   server                                                                          

     {                                                                                

             listen  80;                                                              

             server_name  report.kjh.com ;

             proxy_redirect off;                                                          

             location / {  

1.

proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;

在nginx配置反向代理時，此配置對客戶體驗影響較大，當用戶端請求一個不存在的檔案，導緻較長時間才能傳回請求失敗,雖然在真實的環境中有一定的備援作用，如不善用弊大于利！

文法： proxy_next_upstream [error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off]

确定在何種情況下請求将轉發到下一個伺服器。轉發請求隻發生在沒有資料傳遞到用戶端的過程中。

2.

關于max_fails參數的了解：根據上面的解釋，max_fails預設為1，fail_timeout預設為10秒，也就是說，預設情況下後端伺服器在10秒鐘之内可以容許有一次的失敗，如果超過1次則視為該伺服器有問題，将該伺服器标記為不可用。等待10秒後再将請求發給該伺服器，以此類推進行後端伺服器的健康檢查。但如果我将max_fails設定為0，則代表不對後端伺服器進行健康檢查，這樣一來fail_timeout參數也就沒什麼意義了。那若後端伺服器真的出現問題怎麼辦呢？上文也說了，可以借助proxy_connect_timeout和proxy_read_timeout進行控制。

3.死循環

當設定proxy_next_upstream http_404，并且upstream裡配置是max_fails=0，則通路到不存在檔案時，将會有死循環現象，nginx負載明顯升高，kill -HUP程序消逝很慢。同樣的，proxy_next_upstream如果設定為其它值，例如http_503、invalid_header等也會有同樣問題，但預設的error timeout不會出問題。

4.502 bad gateway

nginx的檢測後端機制相對嚴格，預設的，某個後端一個失敗的請求，就會令此後端暫停10秒。一般而言，不會有太多失敗的請求，而且也不太可能所有機器在10秒内同時出問題；但世事總是難料，nginx->nginx的架構，常因背景伺服器檔案有錯（通常是ssi），報出莫名其妙的錯誤，導緻代理挂起此後端，然後proxy_next_upstream又将此請求導向下一台伺服器，是以在10秒内，所有伺服器都将被挂起……

解決此問題，最直接的辦法是将max_fails設為0，關閉nginx屏蔽後端的功能，雖然有可能會造成死循環，但死循環還不至于很快停止服務，隻是負載較高，至少可以挺一陣子。後端的錯誤如影響太大，還是要及時解決。

5.timeout