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排查出頻寬和丟棄串連數指標。

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。

504 Gateway Timeout

後端伺服器響應逾時。

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