為 Application Load Balancer 進行疑難排解 - Elastic Load Balancing

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

為 Application Load Balancer 進行疑難排解

以下資訊有助於您就 Application Load Balancer 的問題進行疑難排解。

使用資源對應來疑難排解健康狀態檢查

如果您的 Application Load Balancer 目標未通過健康狀態檢查,您可以使用 Elastic Load Balancing 資源對應來尋找狀態不良的目標,並根據失敗原因程式碼採取動作。

存取資源對應
  1. 前往 https://console.aws.amazon.com/ec2/ 開啟 Amazon EC2 主控台。

  2. 在導覽窗格上選擇 Load Balancers (負載平衡器)

  3. 選取負載平衡器。

  4. 選擇資源映射標籤以顯示資源的視覺效果。

瀏覽資源對應
  • 將游標暫留在資源圖標上或選取資源圖標上,以反白顯示其與其他資源之間的關

  • 選取資源圖標以檢視有關該資源的其他詳細資訊。

  • 選取動態磚中的資源名稱,以造訪該資源的詳細資訊頁面。

使用資源對應

資源對應提供兩種檢視:「觀」和「狀況不良目標對映」。預設情況下會選取「概觀」,並顯示所有負載平衡器的資源。選取狀態不良的目標對映檢視將只會顯示與「Application Load Balancer」相關聯之每個目標群組中狀況不良的目標。

注意

您必須啟用 [顯示資源詳細資料],才能檢視資源對映中的健全狀況檢查摘要和錯誤訊息。未啟用時,您必須選取每個資源以檢視其詳細資訊。

「目標群組」資料欄會顯示每個目標群組之狀況良好和狀況不良目標的摘要。這可協助判斷所有目標是否都未通過健康狀態檢查,或是只有特定目標失敗。如果目標群組中的所有目標都未通過健全狀況檢查,請檢查目標群組的組態。選取目標群組名稱,以在新標籤中開啟其詳細資訊頁面。

「目」資料欄會顯示 TargetID 和每個目標的目前健康狀況檢查狀態。當目標狀況不佳時,會顯示健全狀況檢查失敗原因代碼。當單一目標未通過健全狀況檢查時,請確認目標具有足夠的資源,並確認目標上執行的應用程式是否可用。選取目標名稱以在新索引標籤中開啟其詳細資訊頁面。

選取 [匯] 可讓您選擇將應用程式負載平衡器資源對映的目前檢視匯出為 PDF。

疑難排解狀況不良的目標
  • 健康狀況不相符:HTTP 回應不符

    • 確認在目標上執行的應用程式是否正確傳送正確的 HTTP 回應至應用程式負載平衡器的健康狀態檢查要求。

    • 或者,您也可以更新應用程式負載平衡器的健全狀況檢查要求,以符合目標上執行之應用程式的回應。

  • 健康狀況不良:請求逾時

    • 確認與目標相關聯的安全群組和網路存取控制清單 (ACL),以及「Application Load Balancer」未封鎖連線。

    • 確認目標有足夠的資源可用來接受來自 Application Load Balancer 的連線。

    • 驗證目標上執行的任何應用程式的狀態。

    • 您可以在每個目標的應用程式記錄中檢視應用程式負載平衡器的健全狀況檢查回應。如需詳細資訊,請參閱 Health 檢查原因代碼

  • 不健康: FailedHealthChecks

    • 驗證目標上執行的任何應用程式的狀態。

    • 確認目標正在接聽健全狀況檢查連接埠上的流量。

      使用 HTTPS 接聽程式時

      您可以選擇用於前端連線的安全性原則。系統會根據使用中的前端安全性原則,自動選取用於後端連線的安全性原則。

      • 如果您的 HTTPS 接聽程式使用 TLS 1.3 安全性原則進行前端連線,則ELBSecurityPolicy-TLS13-1-0-2021-06安全性原則會用於後端連線。

      • 如果您的 HTTPS 接聽程式未針對前端連線使用 TLS 1.3 安全性原則,則ELBSecurityPolicy-2016-08安全性原則會用於後端連線。

      如需詳細資訊,請參閱安全性原則

    • 確認目標是否以安全性原則指定的正確格式提供伺服器憑證和金鑰。

    • 對於 TLS 連線,請確認目標支援一或多個相符的密碼,以及 Application Load Balancer 提供的通訊協定。

已註冊目標處於非服務中狀態

如果目標進入 InService 狀態所花的時間超過預期,表示該目標可能未通過運作狀態檢查。您的目標將處於非服務中狀態,除非通過一次運作狀態檢查。如需詳細資訊,請參閱 目標群組運作狀態檢查

確認您的執行個體是否未通過運作狀態檢查,然後檢查以下問題:

安全群組不允許流量

與執行個體相關聯的安全群組,必須允許來自負載平衡器使用運作狀態檢查連接埠和運作狀態檢查通訊協定傳來的流量。您可以將規則新增到執行個體安全群組,以允許來自負載平衡器安全群組的所有流量。此外,負載平衡器的安全群組必須允許對執行個體的流量。

網路存取控制清單 (ACL) 不允許流量

與執行個體的子網路相關聯的網路 ACL 必須允許透過運作狀態檢查連接埠傳送對內流量,以及透過暫時性連接埠 (1024-65535) 傳送對外流量。與負載平衡器節點的子網路相關聯的網路 ACL 必須允許透過暫時性連接埠傳送對內流量,以及透過運作狀態檢查連接埠和暫時性連接埠傳送對外流量。

ping 路徑不存在

針對運作狀態檢查建立目標頁面,並指定其路徑做為 ping 路徑。

連線逾時

首先,驗證您可以使用目標的私有 IP 地址和運作狀態檢查通訊協定,從網路內直接連接到目標。如果無法連接,請檢查是否過度利用該執行個體,如果它太忙碌而無法回應,便將更多目標新增到您的目標群組。如果您可以連接,則在運作狀態檢查逾時期間之前,目標頁面可能都沒有回應。為運作狀態檢查選擇較簡單的目標頁面,或調整運作狀態檢查設定。

目標未傳回成功的回應代碼

在預設情況下,成功代碼是 200,但您可以在設定運作狀態檢查時選擇性地指定額外的成功代碼。確認負載平衡器預期的成功代碼,並且您的應用程式已設定為在成功時傳回這些代碼。

目標回應代碼錯誤或連線至目標時發生錯誤

確認應用程式是否回應負載平衡器的運作狀態檢查請求。某些應用程式需要額外的組態才能回應運作狀態檢查,例如需要有虛擬主機組態才能回應負載平衡器傳送的 HTTP 主機標頭。主機標頭值包含目標的私人 IP 位址,不使用預設連接埠時,接著健全狀況檢查連接埠。如果目標使用預設健全狀況檢查連接埠,則主機標頭值僅包含目標的私人 IP 位址。例如,如果目標的私有 IP 位址是10.0.0.10且其健康狀態檢查連接埠為8080,則負載平衡器在健康狀態檢查中傳送的 HTTP Host 標頭為Host: 10.0.0.10:8080。如果您的目標的私有 IP 地址是10.0.0.10並且它的健康檢查端口是80那麼負載平衡器在運行狀態檢查中發送的 HTTP Host 標頭是Host: 10.0.0.10。可能需要虛擬主機組態來回應該主機,或是預設組態,才能順利進行應用程式的運作狀態檢查。運作狀態檢查請求具有下列屬性:User-Agent 設定為 ELB-HealthChecker/2.0,訊息標頭欄位的行結束字元是 CRLF 序列,標頭會在第一個空白行終止,後面接著 CRLF。

用戶端無法連接到面向網際網路的負載平衡器

如果負載平衡器未回應請求,則請檢查下列問題:

您的面向網際網路的負載平衡器已連接到私有子網路

您必須為負載平衡器指定公有子網路。公有子網路具有適用您虛擬私有雲端 (VPC) 對網際網路閘道的路由。

安全群組或網路 ACL 不允許流量

負載平衡器的安全群組和負載平衡器子網路的任何網路 ACL,必須允許來自用戶端的傳入流量和連至接聽程式連接埠上用戶端的傳出流量。

負載平衡器不會收到傳送至自訂域的請求

如果負載平衡器未收到傳送至自訂域的請求,則請檢查下列問題:

自訂域名稱未解析為負載平衡器 IP 地址
  • 使用命令列介面確認自訂域名稱解析的目標 IP 地址。

    • Linux、macOS 或 Unix – 您可以在終端內使用 dig 命令。例如 dig example.com

    • Windows – 您可以在命令提示內使用 nslookup 命令。例如 nslookup example.com

  • 使用命令列介面確認負載平衡器 DNS 名稱解析的目標 IP 地址。

  • 比較兩種輸出的結果。IP 地址必須相符。

如果使用 Route 53 託管自訂網域,請參閱《Amazon Route 53 開發人員指南》中的我的網域在網際網路不可用

傳送至負載平衡器的 HTTPS 要求會傳回 "NET::ERR_CERT_COMMON_NAME_INVALID"

如果 HTTPS 請求從負載平衡器接收 NET::ERR_CERT_COMMON_NAME_INVALID,則請檢查下列可能的原因:

  • HTTPS 請求中使用的域名稱與在關聯 ACM 憑證之接聽程式中指定的替代名稱不相符。

  • 正在使用負載平衡器預設 DNS 名稱。預設 DNS 名稱無法用於提出 HTTPS 請求,因為無法針對 *.amazonaws.com 域請求公有憑證。

負載平衡器顯示處理時間延長

負載平衡器會根據組態以不同的方式計算處理時間。

  • 如果 AWS WAF 與您的 Application Load Balancer 相關聯,且用戶端傳送 HTTP POST 要求,則傳送 POST 要求資料的時間會反映在負載平衡器存取記錄中的request_processing_time欄位中。HTTP POST 請求預期會發生這種行為。

  • 如果 AWS WAF 與您的 Application Load Balancer 沒有關聯,而且用戶端傳送 HTTP POST 要求,則傳送 POST 要求資料的時間會反映在負載平衡器存取記錄中的target_processing_time欄位中。HTTP POST 請求預期會發生這種行為。

負載平衡器會傳送 000 的回應代碼

對於 HTTP/2 連線,如果任何標頭的壓縮長度超過 8 K 位元組,或透過一個連線提供的請求數量超過 10,000,則負載平衡器會傳送 GOAWAY 框架並關閉與 TCP FIN 的連線。

負載平衡器產生 HTTP 錯誤

以下 HTTP 錯誤是由負載平衡器產生。負載平衡器會將 HTTP 程式碼傳送到用戶端,將請求儲存到存取日誌,並遞增 HTTPCode_ELB_4XX_CountHTTPCode_ELB_5XX_Count 指標。

HTTP 400:錯誤的請求

可能原因:

  • 用戶端傳送不符合 HTTP 規格的格式錯誤請求。

  • 請求標頭超過每個請求行 16 K、每個單一標頭 16 K,或整個請求標頭 64 K 的限制。

  • 用戶端在傳送完整請求內文之前關閉了連線。

HTTP 401:未經授權

您設定了接聽程式規則來驗證使用者,但下列其中一項成立:

  • 您已將 OnUnauthenticatedRequest 設定為拒絕未經身分驗證的使用者,或是 IdP 拒絕了存取。

  • IdP 傳回的宣告大小超過負載平衡器支援的大小上限。

  • 用戶端提交了不含主機標頭的 HTTP/1.0 請求,負載平衡器無法產生重新導向 URL。

  • 請求的範圍不會傳回 ID 字符。

  • 您沒有在用戶端登入逾時到期之前完成登入程序。如需詳細資訊,請參閱 Client login timeout

HTTP 403:禁止

您已設定 AWS WAF Web 存取控制清單 (Web ACL) 來監視對 Application Load Balancer 的要求,並封鎖要求。

HTTP 405:方法不允許

用戶端使用了 TRACE 方法,該方法不受 Application Load Balancer 支援。

HTTP 408:請求逾時

用戶端在閒置逾時期間過期前不會傳送資料。傳送 TCP 持續作用無法防止此逾時。在每個閒置逾時期間經過前,先傳送至少 1 位元組的資料。視需要提高閒置逾時期間的長度。

HTTP 413:承載過大

可能原因:

  • 目標是 Lambda 函數,請求內文超過 1 MB。

  • 請求標頭超過每個請求行 16 K、每個單一標頭 16 K,或整個請求標頭 64 K 的限制。

HTTP 414:URI 過長

請求 URL 或查詢字串參數太大。

HTTP 460

負載平衡器收到來自用戶端的請求,但用戶端在閒置逾時期間經過之前關閉了與負載平衡器的連線。

檢查用戶端逾時期間是否大於負載平衡器的閒置逾時期間。確保您的目標在用戶端逾時期間經過之前向用戶端提供回應,或如果用戶端支援的話,增加用戶端逾時期間以符合負載平衡器閒置逾時。

HTTP 463

負載平衡器收到具有過多 IP 地址的 X-Forwarded-For 請求標頭。IP 地址的數量上限為 30。

HTTP 464

負載平衡器收到的傳入請求通訊協定與目標群組通訊協定的版本組態不相容。

可能原因:

  • 請求通訊協定是 HTTP/1.1,而目標群組通訊協定版本是 gRPC 或 HTTP/2。

  • 請求通訊協定是 gRPC,而目標群組通訊協定版本是 HTTP/1.1。

  • 請求通訊協定是 HTTP/2,請求不是 POST,而目標群組通訊協定版本是 gRPC。

HTTP 500:內部伺服器錯誤

可能原因:

  • 您已設定 AWS WAF Web 存取控制清單 (Web ACL),執行 Web ACL 規則時發生錯誤。

  • 負載平衡器無法與 IdP 字符端點或 IdP 使用者資訊端點通訊。

    • 確認 IdP 的 DNS 是否可公開解析。

    • 驗證您的負載平衡器的安全群組和您的 VPC 的網路 ACL 允許對這些端點的傳出存取。

    • 驗證您的 VPC 具有網際網路存取。如果您有面對內部的負載平衡器,請使用 NAT 閘道來啟用網際網路存取。

  • 從 IdP 收到的使用者宣告大小大於 11KB。

HTTP 501:未導入

負載平衡器收到的 Transfer-Encoding 標頭具有不支援的值。Transfer-Encoding 的支援值為 chunkedidentity​。或者,您可以使用 Content-Encoding 標頭。​

HTTP 502:無效的閘道

可能原因:

  • 在嘗試建立連線之前,負載平衡器從目標接收 TCP RST。

  • 在嘗試建立連線之前,負載平衡器從目標收到意外的回應,例如「ICMP 目的地無法連線 (主機無法連線)」。檢查是否允許從負載平衡器子網路對目標連接埠上之目標的流量。

  • 當負載平衡器有對目標的未完成請求時,目標關閉了具有 TCP RST 或 TCP FIN 的連線。檢查目標的持續作用持續期間是否短於負載平衡器的閒置逾時值。

  • 目標回應的格式錯誤或包含無效的 HTTP 標頭。

  • 目標回應標頭超過整個回應標頭 32 K 的限制。

  • 由已取消註冊目標處理的請求取消註冊延遲期間已經過。增加延遲期間,使得耗時操作可以完成。

  • 目標是 Lambda 函數,回應內文超過 1 MB。

  • 目標是一個 Lambda 函數,它沒有在到達設定的逾時之前回應。

  • 目標是傳回錯誤的 Lambda 函數,或是受 Lambda 服務限流的函數。

  • 負載平衡器在連線至目標時遇到 SSL 交握錯誤。

如需詳細資訊,請參閱如何疑難排解 Sup AWS port 知識中心中的 Application Load Balancer HTTP 502 錯誤

HTTP 503:服務無法使用

負載平衡器的目標群組沒有已註冊的目標。

HTTP 504:閘道逾時

可能原因:

  • 負載平衡器無法在連線逾時過期 (10 秒) 之前建立對目標的連線。

  • 負載平衡器建立了對目標的連線,但目標未在閒置逾時期間經過之前回應。

  • 子網路的網路 ACL 不允許從目標到暫時性連接埠 (1024-65535) 上負載平衡器節點的流量。

  • 目標傳回的內容長度標頭大於實體主體。負載平衡器等候遺失的位元組時逾時。

  • 目標是 Lambda 函數,且 Lambda 服務未在連線逾時期間經過之前回應。

  • 連線至目標時,負載平衡器遇到 SSL 交握逾時 (10 秒)。

HTTP 505:不支援的版本

負載平衡器收到非預期的 HTTP 版本請求。例如,負載平衡器建立了 HTTP/1 連線,但收到 HTTP/2 請求。

儲存空間不足

重新導向網址太長。

HTTP 561:未經授權

您設定了接聽程式規則來驗證使用者,但 IdP 在驗證使用者時傳回錯誤碼。檢查您的存取日誌,以獲取相關的錯誤原因代碼

目標產生了 HTTP 錯誤

負載平衡器將來自目標的有效 HTTP 回應轉送至用戶端,包括 HTTP 錯誤。目標產生的 HTTP 錯誤會記錄在 HTTPCode_Target_4XX_CountHTTPCode_Target_5XX_Count 指標中。

AWS Certificate Manager 憑證無法使用

決定在應用程式負載平衡器搭配使用 HTTPS 接聽程式時, AWS Certificate Manager 需要您在發行憑證之前驗證網域擁有權。如果在設定期間遺漏此步驟,則憑證會保持在 Pending Validation 狀態,且在驗證之前無法使用。

  • 如果使用電子郵件驗證,請參閱《AWS Certificate Manager 使用者指南》中的電子郵件驗證

  • 如果使用 DNS 驗證,請參閱《AWS Certificate Manager 使用者指南》中的 DNS 驗證

不支援多行標頭

Application Load Balancer 不支援多行標頭,包括 message/http 媒體類型標頭。如果收到多行標頭,Application Load Balancer 會在將其傳遞至目標之前附加冒號字元 ":"。