問題描述
配置Server Load Balancer之後，訪問網站出現“500 Internal Server Error”、“502 Bad Gateway”和“504 Gateway Timeout”等錯誤時，可能由多種原因導致，例如電訊廠商攔截、用戶端異常行為導致Apsara Stack Security封堵、負載平衡配置錯誤、健全狀態檢查失敗或者後端ECS執行個體Web應用訪問問題。本文列舉了此類問題的對應問題原因的解決方案，若沒有解決問題，可以參見排查步驟定位並解決問題。
問題原因
本問列舉此類問題原因如下所示。
解決方案
對應問題原因的解決方案
來源站點網域名稱沒有備案或者網域名稱沒有在高防中配置七層轉寄規則
如果來源站點網域名稱沒有備案，請將來源站點網域名稱備案，詳情請參見備案。如果網域名稱配置了高防，請配置對應的網域名稱規則，詳情請參見規則。
用戶端IP地址被Apsara Stack Security攔截
將用戶端IP地址添加至IP白名單，請參見IP白名單，排除Apsara Stack Security的影響。
用戶端IP地址被電訊廠商攔截
測試其他ISP電訊廠商的用戶端是否有此問題，如果僅僅是某個固定電訊廠商網路的用戶端訪問有問題，一般是該電訊廠商攔截導致。可以抓包查看是否被電訊廠商攔截或提交工單聯絡阿里雲支援人員排查。如果被電訊廠商攔截，則需要聯絡電訊廠商解決該問題。
後端ECS安全防護軟體攔截
100.64.0.0/10（100.64.0.0/10是阿里雲保留地址，其他使用者無法分配到該網段內，不會存在安全風險）是負載平衡伺服器IP段，主要用於健全狀態檢查和轉寄請求。如果安裝安全軟體或者開啟系統內部防火牆，可以將此IP位址區段加入白名單，或者卸載此類軟體，避免出現500或502狀態代碼。本小節以Linux系統的Iptables為例進行示範。
登入問題後端伺服器，執行以下命令，查看filter表的所有規則。
iptables -nL系統顯示類似如下，說明後端伺服器禁止Server Load Balancer內網位址區段請求。
可以參考以下命令，刪除此規則。
說明如果Iptables可以關閉，執行/etc/init.d/iptables stop命令關閉即可。
sudo iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP執行以下命令，確認沒有禁止Server Load Balancer內網位址區段請求。
sudo iptables -nL
後端ECS執行個體Linux核心參數配置錯誤
當後端ECS執行個體為Linux系統時，負載勻衡SLB由HTTP協議改成TCP協議時，需要注意關閉系統核心參數中rp_filter相關設定。將/etc/sysctl.conf系統設定檔的以下三個參數的值設定為0，然後執行sysctl -p命令即可。
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0後端ECS執行個體效能瓶頸
檢查後端ECS的CPU和外網頻寬等參數，這些績效參數都可能導致訪問異常。如果是ECS執行個體整體系統效能不足，可以通過擴容後端ECS執行個體消除此問題。
健全狀態檢查失敗導致負載平衡出現502狀態代碼
當出現健全狀態檢查失敗時，請參見健全狀態檢查異常排查。此外，若未開啟Server Load Balancer的健全狀態檢查，同時伺服器中Web服務無法正常處理HTTP請求，比如Web服務未運行，也會出現502狀態代碼。
健全狀態檢查正常但Web應用報502狀態代碼
502狀態代碼錯誤提示表明負載平衡可以將來自用戶端的請求轉寄到後端伺服器，但是由於伺服器中Web應用處理異常，導致出現該提示，所以排錯的方向是針對伺服器中Web應用的配置以及運行情況進行分析。例如Web應用處理HTTP請求的時間超過了負載平衡的逾時時間。
在七層（HTTP/HTTPS）監聽配置中，串連請求逾時時間預設值為60秒，若後端ECS執行個體對PHP請求的處理時間超過60秒，此時Server Load Balancer會返回504狀態代碼。對於四層（TCP/UDP）監聽來說，由於串連請求逾時時間預設值為900秒，相對來說不容易出現後端ECS執行個體對PHP請求的處理時間超過900秒的情況。
確認Web服務及其依賴服務正常運行，檢查PHP請求處理情況，最佳化後端PHP請求處理。以Nginx和PHP-FPM為例進行分析說明。
處理PHP請求的進程數達到上限。
當前伺服器中的PHP請求總數已經達到了PHP-FPM中max_children設定的上限，如果後續有新的PHP請求到達伺服器，通常Server Load Balancer會隨機返回502或504狀態代碼。
如果已有的PHP請求被處理完成，新請求被繼續處理，則一切正常。
如果已有的PHP請求處理較慢，新的PHP請求處於等待狀態，直至超過Nginx的fastcgi_read_timeout值，則會出現504狀態代碼。
如果已有的PHP請求處理較慢，新的PHP請求處於等待狀態，直至超過Nginx的request_terminate_timeout值，則會出現502狀態代碼。
PHP指令碼執行時間逾時，即如果PHP-FPM處理PHP指令碼的時間長度超過了Nginx中request_terminate_timeout設定的值，則會出現502狀態代碼，同時在Nginx日誌中可以查看到類似以下錯誤記錄。
[error] 1760#0: *251777 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX.XXX.XXX.XXX, server: localhost, request: “GET /timeoutmore.php HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000”健全狀態檢查針對的是靜態頁面，因此當健全狀態檢查正常時，由於實際處理動態請求的進程異常，例如PHP-FPM未啟動運行，則會導致返回報錯。
業務訪問邏輯問題
請確認Server Load Balancer四層監聽的後端ECS執行個體，在業務層面不存在通過SLB執行個體IP地址訪問SLB執行個體的情況。因為在該情況下，後端執行個體通過負載平衡地址訪問自身所監控的連接埠後，根據負載平衡調度策略的不同，可能會將相應的請求調度到自身執行個體上。導致出現自己訪問自己的情況，造成死迴圈，進而導致出現500或502狀態代碼。
排查步驟
若以上內容沒有解決問題，可以參考以下排查步驟定位並解決問題。
請確認是所有用戶端訪問出現問題，還是部分用戶端有問題。如果僅是部分用戶端問題，排查該用戶端是否被Apsara Stack Security阻擋，負載平衡網域名稱或者IP是否被ISP電訊廠商攔截。
查看500、502和504狀態代碼頁面，判斷是負載平衡問題、高防配置問題還是後端ECS配置問題。
高防配置問題：如果配置了高防，請確認高防的七層轉寄配置正確。
負載平衡問題：
檢查負載平衡狀態，查看是否存在健全狀態檢查失敗的情況，如果有健全狀態檢查失敗的情況，請參見健全狀態檢查失敗。
嘗試將七層監聽切換為四層監聽，查看問題是否會複現。
後端ECS配置問題：如果5XX狀態代碼間斷髮生，很可能是後端某一台ECS執行個體的配置問題。在用戶端的hosts檔案中，將網域名稱解析至後端ECS的IP地址上進行訪問，檢查是否是後端ECS問題。
如果確認是後端ECS問題，請檢查後端ECS執行個體的Web應用日誌是否有相關錯誤，Web服務是否正常運行，確認Web訪問邏輯是否有問題，卸載伺服器上殺毒軟體重啟測試。
檢查後端ECS執行個體是否存在CPU、記憶體、磁碟或網路等效能瓶頸。
如果ECS執行個體是Linux作業系統，檢查後端ECS執行個體TCP核心參數配置是否正確。
具體的排查思路以下圖所示。
適用於
Server Load Balancer。