ALB異常狀態代碼 - Server Load Balancer

先做這5項快速自檢

在按狀態代碼深入排查前，建議先按順序檢查以下5項配置。這些是 ALB 故障最高頻的根因。

運行ALB執行個體診斷工具。在執行個體頁面，找到目標執行個體，在執行個體診斷列單擊發起診斷，可一鍵檢測執行個體配置、監聽、後端服務等常見問題。
確認監聽對應的健全狀態檢查狀態為正常。在監聽詳情頁查看後端伺服器組的健全狀態檢查狀態。如顯示異常，請參見ALB健全狀態檢查異常排查方法。
確認後端 ECS 未屏蔽 ALB 執行個體所屬交換器的網段。ALB 通過其所在交換器分配的 Local IP 與後端通訊。若後端 ECS 的 iptables 或第三方安全軟體屏蔽了 ALB 交換器網段，將導致 ALB 無法訪問後端，觸發 502/504 等異常。
確認伺服器組中後端伺服器配置的連接埠與後端服務實際監聽的連接埠一致。在 ALB 伺服器組中為每台後端伺服器配置的連接埠，必須與該伺服器上業務進程實際監聽的連接埠相同。例如伺服器組中配置為 8080，但後端服務實際監聽 80，將導致串連失敗。可在後端 ECS 執行 ss -tlnp | grep ':<連接埠> ' 或 netstat -tlnp | grep ':<連接埠> '。
HTTPS 監聽：確認認證未到期且認證綁定的網域名稱與訪問網域名稱匹配。在監聽詳情頁查看綁定的認證及有效期間。認證到期或網域名稱不匹配會觸發 SSL 握手失敗或返回異常狀態代碼。

502 Bad Gateway

HTTP 或 HTTPS 監聽接收用戶端請求後，ALB 無法正常將請求轉寄至後端伺服器，或無法從後端伺服器收到響應。

排查思路：先檢查訪問日誌中 upstream_status 欄位的值，根據該欄位的值判斷後續排查方向。

當 upstream_status = 502：ALB 透傳了後端返回的 502 狀態代碼，問題在後端服務自身。請排查後端服務，例如後端 Nginx、網關層是否反向 Proxy到了不可達的上遊。
當 upstream_status 是其他值（如 504、444、500 等）：訪問日誌中 ALB 對外返回的 status 與 upstream_status 不一致，說明 ALB 做了狀態代碼轉換。請排查後端服務為何返回該狀態代碼（查後端 Nginx、網關或應用日誌）。
當 upstream_status 為 - 或為空白：ALB 沒有收到後端的任何響應，說明請求未到達後端、或後端在響應前異常斷開。請按以下順序逐項排查：
- ALB 與後端伺服器 TCP 通訊異常。請排查後端服務狀態是否正常、服務連接埠是否正常監聽、後端 ECS 的 iptables 或第三方安全軟體是否屏蔽了 ALB 執行個體所屬交換器的網段（ALB 通過其所在交換器分配的 Local IP 與後端通訊）。可抓包查看 TCP 握手是否正常。
- 後端伺服器 Backlog 已滿。將導致新的串連請求被拒絕或丟棄。可在後端伺服器執行 netstat -s | grep -i listen，查看是否有 drop 計數。
- 後端伺服器沒有及時處理完請求。請檢查後端伺服器的日誌，並查看 CPU、記憶體等佔用率，確認是否存在效能瓶頸。
- 用戶端發送報文長度超過後端伺服器的 MTU。表現為健全狀態檢查或其他報文較短的包正常，但報文較長的包異常。建議在後端伺服器抓包分析報文長度是否符合要求。
- 後端伺服器響應的報文格式異常或含非法 HTTP 標題。建議在後端伺服器抓包，分析響應報文的格式是否規範。

400 Bad Request

請求格式異常。

後端直接返回400：建議檢查訪問日誌，如upstream_status的值為400，則很可能ALB透傳了後端狀態代碼。請排查後端服務。
HTTP請求發送至HTTPS監聽：ALB的HTTPS監聽會拒絕非HTTPS請求並返回400。請檢查用戶端是否誤將HTTP請求發送至HTTPS連接埠。
要求標頭大小超限：ALB要求每個HTTP要求標頭最大不超過32KB，超過此限制會返回400。建議調整HTTP要求標頭的長度。
請求未完整發送：HTTP請求發送完成前，用戶端關閉了串連。建議在用戶端抓包分析原因。
要求標頭格式錯誤：如Content-Length與實際請求體長度不一致。建議在用戶端抓包分析HTTP請求的格式，與正常請求進行比較。

405 Method Not Allowed

要求方法不支援。

ALB自身限制：ALB不支援TRACE要求方法。建議用其他方法替換。
後端服務限制：除TRACE外，其他要求方法能否被處理取決於後端伺服器是否支援。可直接運行curl -X METHOD http://<後端服務IP>:<服務連接埠>進行驗證，其中METHOD為用戶端使用的要求方法。

408 Request Timeout

請求逾時，ALB主動中斷連線。

用戶端資料轉送緩慢：在用戶端到ALB請求逾時時間內（預設60s），用戶端只傳輸了部分資料（如僅傳輸了HTTP Header而未傳輸HTTP Body）。建議抓包排查用戶端是否存在效能瓶頸或其他異常。
用戶端到ALB網路品質差：TCP的RTT（Round Trip Time）較大或存在丟包等網路問題。建議排查訪問日誌的request_time和tcpinfo_rtt欄位，或在用戶端進行網路診斷。
ALB執行個體頻寬限速：訪問ALB執行個體的流量過大，觸發頻寬限速和丟包。建議通過CloudMonitor排查出頻寬和丟棄串連數指標。

413 Request Entity Too Large

請求體過大。ALB對請求體（Body）的大小限制為50 GB，一般請求不會觸發此限制。

排查思路：檢查訪問日誌中 upstream_status 欄位的值，判斷413是ALB主動返回還是後端伺服器透傳。

當 upstream_status 為 - 或為空白：ALB主動返回413，表示請求體超過了ALB自身的大小限制（50 GB）。此情況較少見。請檢查用戶端發送的請求體大小是否確實超過了限制。
當 upstream_status = 413：後端伺服器返回413並由ALB透傳，此情況更常見。通常是後端Proxy 伺服器（如Nginx）配置了請求體大小限制。請排查後端服務的相關配置，例如Nginx的 client_max_body_size 參數。

414 URI Too Long

請求的URI長度超出限制，ALB或後端伺服器拒絕服務。

ALB自身限制：ALB要求請求的URI長度不超過32KB，否則返回414。建議縮短URI長度。如需傳輸大量資料，可使用POST方法，將資料放在請求體中傳輸，ALB支援最大50GB的POST請求體。
後端服務限制：如果URI沒有超過ALB限制，但後端服務有更嚴格的長度限制，則ALB會透傳後端返回的414狀態代碼。請排查後端服務。

463

僅當監聽掛載IP類型伺服器組時，才會返回463。

請求路徑存在環路。請求通過ALB時，系統會在HTTP Header中追加ALICLOUD-ALB-TRACE欄位（其值為基於規則ID產生的16位雜湊值）。若檢測到存在重複的規則ID，或ALICLOUD-ALB-TRACE欄位數量超過16個，則判定為環路，ALB將停止轉寄請求以防止網路風暴引發的資源耗盡，並返回463狀態代碼。

後端服務配置錯誤：後端服務配置有誤導致請求被重新發送回ALB而形成環路。請排查ALB的後端服務配置。
網路架構設計缺陷：例如單條請求的轉寄鏈路上存在多個Server Load Balancer執行個體。建議最佳化網路架構。

499 Client Closed Request

用戶端主動中斷連線。

用戶端到ALB網路品質差：TCP的RTT（Round Trip Time）較大或存在丟包等網路問題。建議排查訪問日誌的request_time和tcpinfo_rtt欄位，或在用戶端進行網路診斷。
ALB執行個體頻寬限速：訪問ALB執行個體的流量過大，觸發頻寬限速和丟包。建議通過CloudMonitor排查出頻寬和丟棄串連數指標。
後端處理請求時間過長：後端請求處理時間超過了用戶端的請求逾時時間。請檢查訪問日誌中的upstream_response_time欄位，其值為後端處理請求的時間。如該值普遍較高，建議排查後端服務是否存在效能瓶頸。
用戶端設定的請求逾時時間過短：用戶端未發送完請求就因為逾時關閉了串連。建議檢查訪問日誌中的request_time欄位，該欄位代表用戶端請求的總時間，參考該欄位的值設定更合理的用戶端請求逾時時間。
用戶端遇到未知問題：導致請求還未完成即提前關閉串連。建議排查用戶端是否有提前關閉串連的行為。

500 Internal Server Error

後端伺服器內部錯誤，無法執行請求。

後端直接返回500：建議檢查訪問日誌，如upstream_status為500，則很可能ALB透傳了後端狀態代碼。請排查後端服務。
後端伺服器異常關閉串連：後端伺服器在發送完響應前即異常關閉串連。請在後端伺服器抓包排查串連異常關閉的原因。

503 Service Temporarily Unavailable

伺服器暫時不可用，通常由於流量超限或後端服務不可用。

後端直接返回503：建議檢查訪問日誌，如upstream_status為503，則很可能ALB透傳了後端狀態代碼。請排查後端服務。
用戶端請求觸發ALB限速：
- 通過CloudMonitor查看每秒請求數指標。
- CloudMonitor展示分鐘級資料，可能無法反映秒級超限情況。可檢查訪問日誌，如upstream_status欄位的值為-，則請求未送達後端伺服器。
- 檢查響應資料包頭部，如包含ALB-QPS-Limited：Limited欄位，則請求觸發了ALB的限速。
用戶端直接存取ALB的IP或通過網域名稱訪問時DNS解析異常：可能導致流量集中在少數幾個IP從而超限。建議用戶端通過ALB的網域名稱訪問（參考為ALB配置CNAME解析），並確保DNS解析正常。
監聽沒有配置後端伺服器或配置的後端伺服器權重為0。

ALB Ingress 預設轉寄規則導致 503

在 ACK 叢集中安裝 ALB Ingress 組件後，組件會在 ALB 執行個體下自動建立一條預設轉寄規則及對應的伺服器組，該伺服器組初始為空白。

當請求到達 ALB 但未匹配任何已配置的 Ingress 網域名稱轉寄規則時，請求被路由到該預設轉寄規則。由於預設伺服器組為空白，ALB 無後端可轉寄，返回 503 Service Temporarily Unavailable 錯誤。

此為預期行為，無需手動刪除預設轉寄規則。如需解決，請在 ACK 叢集中配置正確的 Ingress 網域名稱轉寄規則，將業務流量路由到對應的後端伺服器組。

說明

503 與 502 的區別：503 表示伺服器組為空白、ALB 無後端可轉寄；502 表示有後端伺服器但後端服務不可用（如後端進程異常）。

萬用字元路徑配置不當導致 503

ALB 轉寄規則的路徑匹配類型為精準匹配及萬用字元時，萬用字元 * 匹配任意長度的字串。路徑 /zhpt/* 匹配以 /zhpt/ 開頭的路徑（如 /zhpt/test），但不包含基礎路徑 /zhpt 本身。因此，當規則僅配置了 /zhpt/* 時，訪問 /zhpt 不會命中該規則，請求落入預設轉寄動作。若預設伺服器組為空白，則返回 503 Service Temporarily Unavailable。關於路徑匹配規則的更多資訊，請參見轉寄規則配置樣本與網域名稱路徑匹配規則。

解決方案：根據實際需要匹配的路徑範圍，選擇以下方式之一：

若只需匹配基礎路徑 /zhpt，將規則路徑由 /zhpt/* 改為 /zhpt。
若需同時匹配基礎路徑 /zhpt 及其子路徑 /zhpt/*，請分別配置兩條轉寄規則（/zhpt 和 /zhpt/*），並注意規則編號順序。
若需更靈活的路徑匹配，將匹配類型改為正則匹配，並按正則文法編寫路徑運算式（例如使用 ^/zhpt(/.*)?$ 同時匹配 /zhpt 及其子路徑）。Regex需使用 ^ 和 $ 進行首尾錨定，避免誤匹配 /zhptxxx 等非預期路徑。

504 Gateway Timeout

後端伺服器響應逾時。

後端直接返回504：建議檢查訪問日誌，如upstream_status為504，則很可能ALB透傳了後端狀態代碼。請排查後端服務。
ALB與後端伺服器建立連線逾時：逾時時間預設為5秒且無法修改。建議抓包排查後端伺服器響應逾時的原因。
後端伺服器響應逾時：串連請求逾時時間預設為60秒。可查看CloudMonitor的UpstreamResponseTime和訪問日誌的upstream_response_time來確定後端伺服器是否響應逾時。

HTTPS 監聽 TLS 握手失敗排查

ALB HTTPS 監聽在 TLS 握手階段收到 Handshake Failure (40) 錯誤，通常由以下三種原因引起。可按順序逐一排查。

原因一：SNI 與認證網域名稱不匹配

用戶端 TLS Client Hello 中攜帶的 SNI（Server Name Indication）ServerName 欄位值，與 ALB 監聽綁定的認證網域名稱不匹配，ALB 無法選擇合適的認證完成握手。

排查步驟：

使用 Wireshark 抓取用戶端發出的 TLS Client Hello 包，查看 Extension: server_name 欄位中 Server Name 的實際值。
在 ALB 控制台進入目標 HTTPS 監聽，單擊認證管理，查看綁定的預設伺服器憑證及其綁定網域名稱（例如 alb-test.example.com）。
對比 SNI ServerName 與認證綁定網域名稱是否一致。如不一致，請確認用戶端請求的 Host 頭是否正確，或在監聽上綁定與用戶端 SNI 匹配的認證。

原因二：用戶端與 ALB 加密套件無交集

用戶端 Client Hello 中支援的加密套件列表，與 ALB 監聽TLS 安全性原則中配置的加密套件列表沒有交集，握手階段無法協商出雙方均支援的套件。

排查步驟：

執行以下命令，查看 TLS 握手協商過程並擷取服務端下發的套件資訊；也可通過 Wireshark 抓包擷取用戶端 Client Hello 中支援的完整加密套件列表：
```
openssl s_client -connect <ALB網域名稱>:443
```
在 ALB 控制台進入目標 HTTPS 監聽詳情，查看當前配置的TLS 安全性原則名稱（例如 tls_cipher_policy_1_0）。單擊策略名稱稱後的查看全部加密套件，查看該策略支援的完整套件列表（tls_cipher_policy_1_0 支援 TLS v1.0/v1.1/v1.2，共 19 個套件：6 個 ECDSA 類、6 個 RSA 類、7 個非 ECDHE 類）。
對比用戶端支援的加密套件與安全性原則中的套件列表，確認是否存在交集。如無交集，可在 ALB 控制台將 HTTPS 監聽的安全性原則更換為與用戶端相容的策略，或在用戶端側添加與當前安全性原則相容的加密套件。

原因三：認證簽名演算法與加密套件類型不符

TLS 安全性原則包含要求 ECDSA 簽名演算法的加密套件，但 HTTPS 監聽上僅配置了 RSA 認證，導致這些 ECDSA 類套件無法參與協商，可能造成握手失敗。

排查步驟：

在 ALB 控制台進入目標 HTTPS 監聽詳情，找到SSL 憑證地區，查看當前綁定的認證名稱、ID 及綁定網域名稱。該地區不直接顯示簽名演算法類型。
單擊認證 ID 連結，跳轉至 SSL 憑證管理主控台，查看該認證的簽名演算法類型（RSA 或 ECDSA）。
回到監聽詳情頁，確認當前TLS 安全性原則所含套件類型。若安全性原則包含 ECDSA 類套件（例如 tls_cipher_policy_1_0 含 6 個 ECDSA 類套件），但監聽僅配置了 RSA 認證，則需在監聽上補充綁定對應類型的 ECC 認證（ECDSA 演算法認證）。