對於配置負載平衡之後,訪問網站出現500 Internal Server Error, 502 Bad Gateway, 504 Gateway Timeout等錯誤,有可能由多種原因導致,例如電訊廠商攔截,用戶端異常行為導致雲盾封堵,負載平衡配置錯誤或者健康檢查失敗,後端ECS Web應用訪問問題。

本文檔列舉了此類問題的可能原因、解決方案以及排查步驟。

  1. 可能原因以及解決方案
  2. 排查步驟
  3. 提交工單

可能原因以及解決方案

  1. 源站網域名稱沒有備案或者網域名稱沒有在高防或者安全網路中配置七層轉寄規則

    解決方案:請將網域名稱備案。如果負載平衡在高防或者安全網路,配置對應的網域名稱規則。

  2. 用戶端源IP地址被雲盾攔截

    測試其他ISP電訊廠商的用戶端是否有相同問題,如果僅僅是某個固定電訊廠商網路的用戶端訪問有問題,一般是電訊廠商封堵導致。

    解決方案:通過工單反饋阿里雲售後支援抓包確認是否有封堵行為,如果確認,請聯繫電訊廠商解決該問題。

  3. 後端ECS安全防護軟體阻擋

    100.64.0.0/10(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)是負載平衡伺服器IP段,主要用於健康檢查和轉寄請求,如安裝安全軟體或者系統內部防火牆,可以將此IP添加白名單,避免出現500或502錯誤。

    解決方案:配置殺毒、防火牆軟體白名單,或者卸載此類軟體快速測試。

  4. 後端ECS Linux核心參數配置錯誤

    對於後端ECS為Linux系統,改成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
  5. 後端ECS效能瓶頸

    例如CPU高,外網頻寬跑滿均可能導致訪問異常。

    解決方案:檢查後端ECS效能,解決效能瓶頸問題,如果是整體系統容量不夠,可以通過擴容後端ECS 的數量消除問題。

  6. 健康檢查失敗導致負載平衡出現502錯誤

    關於健康檢查失敗,參考健康檢查異常排查進行排查。

    此外,未開啟負載平衡的健康檢查,同時伺服器中Web服務無法正常處理HTTP請求,比如Web服務未運行,也會出現502錯誤。

  7. 健康檢查正常但Web應用報502錯誤

    502 Bad Gateway錯誤提示表明負載平衡可以將來自用戶端的請求轉寄到後端伺服器中,但是伺服器中Web應用處理異常拋出該提示,所以排錯的方向是針對伺服器中Web應用的配置以及運行情況進行分析。例如Web應用處理HTTP請求的時間超過了負載平衡的timeout時間。在七層HTTP模式下,後端對PHP請求的處理時間超過proxy_read_timeout 60秒,此時會出現負載平衡拋出的504 Gateway Time-out。對於四層監聽,逾時時間為900秒。

    解決方案:確保Web服務以及依賴正常運行,檢查PHP請求處理情況,優化後端PHP請求處理。下面以Nginx+php-fpm為例進行分析說明:

    1. 處理PHP請求的進程數達到上限。

      當前伺服器中PHP請求總數已經達到了php-fpm中max_children設定的上限,如果後續有新的PHP請求到達伺服器中,這種情況下通常會有502與504錯誤隨機出現:

      • 如果已有的請求被馬上處理完成,新請求被繼續處理,一切正常;
      • 如果已有的PHP請求處理較慢,新的PHP一直處於等待狀態,直至超過Nginx的 fastcgi_read_timeout的值,就會出現504 Gateway timeout的錯誤;
      • 如果已有的PHP請求處理較慢,新的PHP處於等待狀態,超過了Nginx的request_terminate_timeout的值,就會出現502 Bad Gateway的錯誤。
    2. 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”
    3. 健康檢查針對的是靜態頁面,實際處理動態請求的進程異常,比如php-fpm未啟動運行。
  8. HTTP頭部過大

    過大的Head頭資訊也可能導致負載平衡無法正確處理相關資料,進而引發502錯誤。

    解決方案:減少通過 Head 頭傳遞的資料量或者換成TCP監聽。

  9. 業務訪問邏輯問題

    確保不存在負載平衡後端ECS執行個體在伺服器內部通過負載平衡公網IP地址訪問SLB的情況。該情況下,後端商務服務器通過負載平衡地址訪問自身所監控的通信埠後,根據負載平衡調度策略的不同,可能會將相應的請求調度到自身伺服器上。導致出現自己訪問自己的情況,造成死迴圈,進而導致相應的請求出現500或502錯誤。

    解決方案:確保負載平衡場景應用正確,避免後端ECS伺服器需要訪問負載平衡公網IP地址的情況。

排查步驟

  • 檢查500/502/504錯誤截圖,判斷是負載平衡問題,高防/安全網路設定問題,還是後端ECS配置問題。
  • 如果有高防/安全網路,請確認高防或者安全網路的七層轉寄配置正確。
  • 請確認是所有用戶端都有問題,還僅僅是部分用戶端有問題。如果僅僅是部分用戶端問題,排查是否該用戶端被雲盾阻擋,或者是否是負載平衡網域名稱或者IP被ISP電訊廠商攔截。
  • 檢查負載平衡狀態,是否有後端ECS健康檢查失敗的情況,如果有健康檢查失敗,解決健康檢查失敗問題。
  • 在用戶端用hosts檔案將負載平衡的服務地址綁定到後端伺服器的IP地址上,確認是否是後端問題。如果5XX錯誤間斷髮生,很可能是後端某一台ECS伺服器的配置問題。
  • 嘗試將七層負載平衡切換為四層負載均,查看問題是否會複現。
  • 檢查後端ECS伺服器是否存在CPU、記憶體、磁碟或網路等效能瓶頸。
  • 如果確認是後端伺服器問題,請檢查後端ECS Web伺服器日誌是否有相關錯誤,Web服務是否正常運行,確認Web訪問邏輯是否有問題,卸載伺服器上殺毒軟體重啟測試。
  • 檢查後端ECS Linux作業系統的TCP核心參數是否配置正確。


提交工單

請根據上述排查步驟中的指導逐條排查,詳細記錄排查測試結果。提交工單時,請您提供上述資訊以便售後支援儘快協助您解決問題。

如問題還未解決,請聯繫售後支援人員。