Server Load Balancer：ALB常見問題

ALB是否有具體的執行個體規格？

ALB無需選擇執行個體規格。ALB升級執行個體可通過VIP自動彈性能力，達到單一實例100萬QPS的效能。ALB執行個體的效能詳情，請參見執行個體效能指標。

ALB IPv4執行個體和雙棧執行個體是否支援互轉？

不支援。

僅支援建立IPv4執行個體或者雙棧執行個體。

ALB執行個體的VIP是否支援禁止Ping？

• 已升級ALB執行個體支援通過安全性群組管理訪問流量，可在執行個體所屬安全性群組中配置入方向拒絕ICMP規則。

• 對於未升級ALB執行個體，支援將其綁定的EIP接入互連網邊界防火牆，並配置入方向拒絕ICMP策略。

如何提升ALB的公網頻寬？

未加入共用頻寬時，單ALB執行個體（雙可用性區域）預設公網頻寬峰值為400 Mbps。

ALB的公網流量能否使用共用流量包進行抵扣？

• ALB執行個體通過Elastic IP Address（Elastic IP Address，簡稱EIP）提供公網能力時，EIP產生的公網流量支援使用通用流量包進行抵扣。

• ALB執行個體通過任播Elastic IP Address（ Anycast Elastic IP Address，簡稱Anycast EIP）提供公網能力時，Anycast EIP產生的公網流量不支援使用通用流量包進行抵扣。

ALB支援綁定哪些類型的EIP？

私網ALB支援綁定Elastic IP Address嗎？

支援。

如果您需要給私網ALB綁定Elastic IP Address，可以通過變更執行個體網路類型的方式，將私網ALB變更為公網ALB。具體操作，請參考變更ALB執行個體的網路類型。

私網類型轉換為公網類型時會綁定Elastic IP Address，產生公網網路費用。更多資訊，請參見Elastic IP Address計費。

ALB的EIP如何更換為精品EIP？

您可以通過變更ALB執行個體的網路類型的方式進行更換：

1. 將ALB執行個體由公網類型轉換為私網類型，以解除綁定ALB執行個體的EIP。

2. 再將ALB執行個體由私網類型轉換為公網類型，轉換時，請選擇已建立的2個精品線路EIP。

為什麼ALB綁定的EIP流量負載不均衡

可能有以下原因：

• 業務網域名稱未按規範解析至ALB的DNS名稱，而是解析到了ALB綁定的單個EIP上。

• ALB前端部署了WAF或DDoS高防等七層代理，其回源演算法（如IPHash）導致流量無法在多個EIP間均勻分布。

• 部分用戶端緩衝了DNS解析後的A記錄，導致大量請求持續落到同一個EIP上。

ALB DNS摘除注意事項？

ALB升級執行個體預設支援DNS摘除與DNS恢複操作。

DNS摘除操作完成後，該可用性區域VIP的可用性探測停止，同時將從ALB網域名稱解析中移除該可用性區域下的VIP或EIP（包含IPv4和IPv6），不支援僅移除IPv4或IPv6的VIP地址。

使用ALB後，後端ECS公網流量為什麼仍然很高？

經ALB轉寄到後端ECS的流量走VPC內網，不佔用ECS公網頻寬。如果ECS公網流量仍然很高，通常有兩類原因：

• 入方向流量未經過ALB：網域名稱仍解析到ECS公網IP，或用戶端直接通過ECS公網IP訪問，導致流量未經ALB轉寄。

• ECS自身的出方向請求：ECS上啟動並執行程式主動發起外部請求（如軟體更新、日誌上傳、調用外部API等），產生公網出流量。

排查方法：

1. 確認業務網域名稱是否已解析到ALB地址，而非ECS公網IP。

2. 檢查ECS安全性群組入方向規則，確認是否仍對公網開放了業務連接埠。

3. 在ECS上使用 iftop 或 nethogs 定位佔用公網頻寬的進程和目標地址。

ALB是否支援流量鏡像功能？

支援，更多資訊，請參見使用ALB流量鏡像功能實現模擬壓測。

為什麼ALB執行個體達不到監聽轉寄規則中設定的QPS限速峰值？

• 原理：因為負載平衡系統通過叢集部署的方式為Server Load Balancer執行個體提供服務，所有外部的訪問請求都將平均分散到這些負載平衡系統伺服器上進行轉寄。所以，在轉寄規則中設定的QPS峰值將被平均設定在多台系統伺服器上。

  單個系統伺服器的QPS上限計算方法為：單個系統伺服器QPS峰值=設定的總QPS/（N-1）。N為轉寄分組中系統伺服器的個數。例如您在控制台上設定轉寄規則的QPS限速是1000 QPS，若系統伺服器個數為8，那麼單個系統伺服器的最大QPS為1000/(8-1)=142 QPS。

• 原因：在使用少量長串連的業務情境下，轉寄分組中的系統伺服器可能不會全部被分配到長串連，導致ALB執行個體達不到QPS限速峰值。

• 建議：基於負載平衡的實現原理，建議在配置轉寄規則的QPS限速時，根據您實際的業務情況並結合其實現方式來設定一個較為合理的值，從而確保您業務的正常對外服務不會受到影響和限制。關於如何在監聽轉寄規則中設定QPS限速，請參見添加轉寄規則。

ALB轉寄請求的長度限制是多少？是否支援調整？

ALB處理時間是否包含接收用戶端資料和發送資料時間？

ALB處理時間包含接收用戶端資料和發送資料時間。

• 接收用戶端資料時間：即read_request_time，指負載平衡讀取用戶端請求的總耗時，包括接收HTTP要求標頭（read_header_time）和請求體（read_body_time）。

• 發送響應資料時間：包含向用戶端返迴響應資料的時間。

用戶端到ALB的單個HTTP長串連最多支援多少個請求

單個長串連最多支援連續發送 100 個請求，超過該限制後串連將自動關閉。

僅當使用HTTPS監聽並開啟HTTP 2.0時，單個長串連支援的請求數上限可提升至 1000 個。

ALB的QUIC監聽對用戶端Client Hello包的長度限制

使用QUIC監聽時，ALB 對用戶端的Client Hello包設有最小長度限制，其長度不得小於 1024 位元組，否則ALB會返回“client hello too small”並關閉串連。使用者可以通過補Null 字元的方式將Client Hello包長度補足至1024位元組以通過校正。

使用ALB Ingress有哪些注意事項？

通常情況下，通過ALB Ingress建立的ALB執行個體不應該在控制台做手動修改，ALB的配置以AlbConfig資源同步為主。關於ALB Ingress的相關介紹，請參見ALB Ingress管理和ALB Ingress功能操作指導。

如果您在控制台進行了手動修改，會因為AlbConfig配置沒有修改而導致控制台手動修改的配置被覆蓋，從而會出現例如訪問日誌被關閉、路由規則被刪除等問題。

ALB支援跨域常見問題

配置ALB監聽轉寄規則，轉寄動作為寫入Header時，如何引用原始Header的值？

鍵是填寫想要寫入的Header名稱，值是選擇引用方式，並填寫想要引用對應值的原始Header的名稱。如下樣本，寫入Header名稱為abc-abc，引用原始Headerabc的值。轉寄規則會提取原始Headerabc的欄位值附給新寫入的Headerabc-abc。

該轉寄規則的轉寄條件為路徑精確匹配 /，轉寄動作除寫入 Header 外，還配置了轉寄至指定伺服器組（權重為 100）。

用戶端

用戶端使用 curl 發送請求時，通過 -H 參數攜帶自訂要求標頭 abc:123456，伺服器返回 200 OK。樣本命令及輸出：

curl http://xxx.xxx.174 -v -k -H abc:123456
*   Trying xxx.xxx.174:80...
* Connected to xxx.xxx.174 (xxx.xxx.174) port 80
> GET / HTTP/1.1
> Host: xxx.xxx 174
> User-Agent: curl/8.4.0
> Accept: */*
> abc:123456
>
< HTTP/1.1 200 OK
< Date: Sat, 13 Sep 2025 16:18:38 GMT
< Content-Type: text/html
< Content-Length: 4833
< Connection: keep-alive
< Vary: Accept-Encoding
< Set-Cookie: acw_tc=0a2a24fb17577803180911860e42646551283f5ec94793498a70af97834171;path=/;HttpOnly;Max-Age=1800
< Last-Modified: Fri, 16 May 2014 15:12:48 GMT
< ETag: "53762af0-12e1"
< Accept-Ranges: bytes

服務端

GET / HTTP/1.1
RemoteIp: xxx.xxx.xxx.103
Host: xxx.xxx.xxx.174
X-Forwarded-For: xxx.xxx.xxx.103
User-Agent: curl/8.4.0
Accept: */*
abc: 123456
X-Sinfo: on
abc-abc: 123456
HTTP/1.1 200 OK
Server: nginx/1.20.1
Date: Sat, 13 Sep 2025 16:18:38 GMT
Content-Type: text/html
Content-Length: 4833

ALB是否支援CA雙向認證？

基礎版ALB執行個體不支援CA雙向認證，標準版和WAF增強版ALB執行個體添加HTTPS監聽時支援配置CA雙向認證。如果基礎版ALB需要使用CA雙向認證功能，請升級執行個體功能版本。

ALB監聽認證為萬用字元認證（泛網域名稱認證）時，需滿足哪些規則？

ALB支援上傳認證嗎？

不支援。

ALB是直接調用SSL認證服務（Alibaba Cloud SSL Certificates Service）的認證，需要您將認證上傳至SSL認證控制台，因此不支援在ALB進行認證上傳操作。更多資訊，請參見SSL上傳認證。

ALB更新認證後，瀏覽器中查看到的網域名稱認證到期時間沒變

這種情況通常是因為ALB通過透明接入的方式接入了WAF2.0，WAF側的認證還未更新。WAF同步ALB的認證有周期性，如需立即完成同步，可以在WAF側關閉引流再重新開啟，強制重新整理認證狀態；請注意，此操作會導致業務出現1-2秒的閃斷。

配置了HTTPS監聽但HTTPS訪問仍不生效，如何排查認證問題？

配置HTTP到HTTPS重新導向後，若HTTPS訪問仍提示不安全或訪問失敗，通常是HTTPS監聽綁定的認證網域名稱與實際訪問的網域名稱不匹配。請重點確認認證類型與訪問網域名稱的匹配關係：

• 單網域名稱認證：僅匹配認證簽發的精確網域名稱。例如為example.com簽發的認證僅對example.com有效，對子網域名稱app.example.com無效。

• 如需覆蓋多個子網域名稱，請改用泛網域名稱認證。泛網域名稱認證的具體匹配規則，請參見前文ALB監聽認證為萬用字元認證（泛網域名稱認證）時，需滿足哪些規則？。

排查步驟：

1. 確認HTTPS監聽已綁定SSL認證，且認證已簽發、未到期。

2. 對比認證綁定的網域名稱與實際訪問的網域名稱，確認認證已覆蓋訪問所用網域名稱；若通過子網域名稱訪問，需綁定對應的泛網域名稱認證（如*.example.com）。

如何修改監聽的健全狀態檢查配置？

1. 登入應用型負載平衡ALB控制台。

2. 在左側導覽列，選擇應用型負載均衡 ALB > 伺服器組。

3. 在伺服器組頁面，找到目標伺服器組，然後單擊伺服器組ID。

4. 在詳細資料的健全狀態檢查地區，單擊編輯健全狀態檢查。

5. 在編輯健全狀態檢查對話方塊，單擊健全狀態檢查配置右側的编辑，根據需求修改健全狀態檢查配置。然後單擊儲存。

   更多資訊，請參見ALB健全狀態檢查。

為什麼健全狀態檢查結果正常但訪問ALB請求返回502？

通常是因為ALB執行個體後端伺服器負載過高。當ALB執行個體後端伺服器負載過高時，可能會出現健全狀態檢查結果和訪問請求結果不一致的情況。關於如何查詢後端伺服器負載情況，請參見Linux執行個體負載高問題排查和異常處理。

同一個伺服器組的所有後端伺服器健全狀態檢查均異常時，ALB如何轉寄請求？

ALB仍會嘗試根據調度演算法轉寄請求，最大可能避免您的業務受損。若請求不符合預期，建議通過日誌排查後端伺服器是否有異常，或者檢查健全狀態檢查配置是否存在異常。更多資訊，請參見ALB健全狀態檢查異常排查方法。

通過ALB無法訪問服務時如何排查？

可參考以下思路：

1. 確認網域名稱解析（CNAME）：建立ALB執行個體不支援直接使用DNS名稱訪問，需將自訂網域名通過CNAME方式解析到ALB執行個體的DNS名稱。可以通過 nslookup 或 dig 命令驗證解析結果。詳見ALB執行個體DNS名稱說明。

2. 確認執行個體網路類型：私網ALB執行個體僅支援VPC內部訪問，無法直接通過公網訪問。如需公網訪問，請將執行個體網路類型變更為公網並綁定EIP。參考變更ALB執行個體的網路類型。

3. 確認監聽和轉寄規則：在ALB控制台檢查是否已建立監聽，確認監聽連接埠和協議配置正確，並確認轉寄規則能夠匹配請求的網域名稱和路徑。

4. 確認健全狀態檢查狀態：在ALB控制台查看後端伺服器的健全狀態檢查狀態。當後端伺服器健全狀態檢查異常時，ALB可能無法正常轉寄請求。

5. 確認後端服務正常：直接登入後端伺服器，通過 curl -I http://<後端伺服器內網IP>:<連接埠> 確認後端服務本身可正常響應。

6. 確認存取控制和防火牆設定：確認 ALB 執行個體的存取控制或安全性群組未攔截用戶端請求來源位址區段；確認後端 ECS 的 iptables 或第三方安全軟體未屏蔽 ALB 的 Local IP 網段。

通過ALB訪問時延遲較高，如何排查？

ALB面嚮應用層，請求需經過ALB轉寄至後端伺服器，相比直接存取後端會有少量延遲增加，這是正常現象。

如果延遲明顯偏高，建議通過以下步驟排查：

1. 開啟訪問日誌並分析延遲欄位：開啟ALB訪問日誌，重點關注以下欄位：

   • request_time：負載平衡收到第一個請求報文的時間到返回應答之間的時間間隔，單位為秒。

   • upstream_response_time：從負載平衡向後端伺服器建立串連開始到接收完資料然後關閉串連為止的時間，單位為秒。

2. 判斷延遲來源：

   • 若 upstream_response_time 較高：延遲來源通常是後端伺服器處理慢。建議排查後端應用效能、資料庫查詢效率、CPU/記憶體等資源使用方式，或增加後端伺服器分擔壓力。

   • 若 request_time 遠大於 upstream_response_time：延遲可能在用戶端到ALB的網路鏈路上。建議從用戶端對ALB服務地址持續執行 ping 測試或MTR路由跟蹤，排查網路鏈路問題。

3. 跨地區訪問情境：如果用戶端與ALB執行個體分布在不同地區，物理距離導致的網路延遲不可避免。建議使用Global AccelerationGA服務最佳化跨地區訪問體驗。

通過網域名稱無法訪問ALB服務，怎麼辦？

建立ALB執行個體不支援直接通過DNS名稱訪問，需將自訂網域名通過CNAME方式解析到ALB執行個體的DNS名稱後才能訪問。如已正確配置CNAME但仍無法訪問（返回403或串連被重設），最常見的原因是網域名稱未完成ICP備案。

建議按以下步驟排查：

1. 確認CNAME解析配置：通過 nslookup 或 dig 命令驗證網域名稱是否已正確解析到ALB執行個體的DNS名稱。參考配置CNAME解析。

2. 確認網域名稱ICP備案狀態：根據相關法規要求，在中國內地地區使用網域名稱通過公網訪問時，網域名稱必須已完成ICP備案，否則訪問會被阻斷。登入阿里雲ICP備案系統查詢網域名稱備案狀態。如未備案，請先完成ICP備案。可參考ICP備案流程。

3. 確認是否需要接入備案：如果網域名稱已在其他雲端服務商完成ICP備案，但首次在阿里雲使用，還需要進行接入備案，將備案資訊接入阿里雲。未完成接入備案同樣可能導致訪問被阻斷。

500（Internal Server Error）

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

• 後端直接返回500：建議檢查訪問日誌，如upstream_status為500，則很可能ALB透傳了後端狀態代碼。請排查後端服務。

• 後端伺服器異常關閉串連：後端伺服器在發送完響應前即異常關閉串連。請在後端伺服器抓包排查串連異常關閉的原因。

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 標題。建議在後端伺服器抓包，分析響應報文的格式是否規範。

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 Time-out）

後端伺服器響應逾時。

• 後端直接返回504：建議檢查訪問日誌，如upstream_status為504，則很可能ALB透傳了後端狀態代碼。請排查後端服務。

• ALB與後端伺服器建立連線逾時：逾時時間預設為5秒且無法修改。建議抓包排查後端伺服器響應逾時的原因。

• 後端伺服器響應逾時：串連請求逾時時間預設為60秒。可查看CloudMonitor的UpstreamResponseTime和訪問日誌的upstream_response_time來確定後端伺服器是否響應逾時。

WAF 2.0透明化接入和WAF 3.0服務化接入的區別？

更多資訊，請參見WAF 3.0與WAF 2.0對比。

ALB接入WAF的使用說明？

• 建議通過服務化接入方式為ALB執行個體開啟 WAF 3.0 防護，即使用WAF增強版ALB執行個體。

  • 支援的地區：

    地區	地區
    中國	西南1（成都）、華北1（青島）、華北2（北京）、華南3（廣州）、華東1（杭州）、華北6（烏蘭察布）、華東2（上海）、華南1（深圳）、華北3（張家口）、中國香港、華南2（河源）
    亞太地區	菲律賓（馬尼拉）、印尼（雅加達）、日本（東京）、馬來西亞（吉隆坡）、新加坡、泰國（曼穀）、韓國（首爾）
    歐美地區	德國（法蘭克福）、美國（矽谷）、美國（維吉尼亞）、墨西哥
    中東	沙特（利雅得）- 夥伴營運、阿聯酋（杜拜）

  • 採用 WAF 3.0 服務化接入架構。如果帳號下已有 WAF 2.0 執行個體，需先釋放WAF 2.0執行個體或遷移至WAF 3.0。

    ALB 預設不開啟 X-Forwarded-Proto 頭欄位。釋放 WAF 2.0 執行個體後，直接存取 ALB 可能會因後端服務無法正確識別協議（HTTP/HTTPS）而導致業務異常（例如，無限重新導向）。為避免此問題，務必在 ALB 監聽配置中手動開啟X-Forwarded-Proto要求標頭。

  • 開通後，WAF 的資訊泄露防護功能將不受支援。

• 如需使用帳號已有的 WAF 2.0 執行個體，公網基礎版和公網標準版ALB執行個體支援透明化接入 WAF 2.0 防護，支援的地區：華東1（杭州）、華東2（上海）、華南1（深圳）、西南1（成都）、華北2（北京）、華北3（張家口）。私網ALB執行個體不支援接入 WAF 2.0 防護。

CLB和ALB對透明化接入WAF 2.0和服務化接入WAF 3.0的支援情況？

WAF 2.0透明化接入出現逾時時間和認證不同步等配置問題的原因？

WAF 2.0透明化接入時，用戶端請求需先經過WAF檢測後，再去往ALB或CLB，用戶端請求需經過兩道網關，導致WAF側和負載平衡側需要同步多個配置，尤其逾時時間和認證變更操作容易引發配置同步的延時問題。