Server Load Balancer：CLB監聽服務FAQ

傳統型負載平衡CLB是否支援連接埠跳轉？

支援。

CLB支援連接埠重新導向，具體操作樣本，請參見使用CLB將HTTP訪問重新導向至HTTPS。

負載平衡CLB的四層監聽是否支援監聽連接埠範圍？

不支援。若您需要配置TCP或者UDP監聽並對一個連接埠範圍進行監聽，請建立網路型負載平衡NLB執行個體，啟用TCP監聽或者UDP監聽的全連接埠功能。相關操作文檔請參見使用NLB全連接埠監聽功能實現多連接埠流量轉寄。

負載平衡CLB配置監聽連接埠時需要注意什麼問題？

部分電訊廠商將連接埠25、135、139、444、445、5800、5900等標記為高危連接埠，並預設屏蔽這些連接埠。即使您在安全性群組規則中允許存取了這些連接埠，受限地區的使用者仍無法訪問。因此，建議您考慮使用其他非高危連接埠來承載業務。

• 關於Windows Server系統應用的連接埠說明，請參見《微軟文檔》Windows伺服器系統的服務概述和網路連接埠要求。

• 常用連接埠資訊請參見常用連接埠。

後端伺服器部署WebSocket或者WebSocket Secure業務，監聽該怎麼配？

• 後端伺服器部署WebSocket業務，可以配置TCP監聽或者HTTP監聽。

• 後端伺服器部署WebSocket Secure業務，可以配置TCP監聽或者HTTPS監聽。

修改CLB監聽配置的生效機制及影響？

修改後立即生效，且僅對新發起的請求有效，不會影響進行中的請求串連。

為什麼監控資料顯示頻寬未超規格，但仍然發生了流量丟棄？

通常由以下原因導致：

• 阿里雲的頻寬監控資料基於每分鐘的平均值。當一分鐘內特定秒的瞬時流量超過了執行個體的頻寬節流設定，只要一分鐘的平均頻寬未超出設定規格，監控圖表顯示的整體頻寬使用量會顯示低於頻寬規格。

• 負載平衡系統通過叢集部署的方式為CLB執行個體提供服務，所有外部的訪問請求都將平均分散到這些負載平衡系統伺服器上進行轉寄。設定的頻寬峰值實際是被平均分配到多台系統伺服器上。如果某用戶端請求串連下載的資料量超過單台伺服器的閾值，就會導致流量被丟棄。更多資訊，請參見在部分特殊情境中，為什麼會出現串連達不到頻寬峰值的現象？中單個串連下載資料傳輸量上限的計算方法。

為什麼監控裡看到的監聽流量比配置的限速要大？

負載平衡系統通過叢集部署的方式為CLB執行個體提供服務，限速採用的是分布式限速。單個節點的限速峰值=設定的負載平衡總頻寬/(N-1)，N為叢集子節點個數，所以整體限速值會略大於配置的限速值。

在部分特殊情境中，為什麼會出現串連達不到頻寬峰值的現象？

• 情境描述：購買公網CLB且按固定頻寬計費時，單用戶端壓測或傳輸超巨量資料包等特殊情境，可能會出現串連達不到頻寬峰值。

• 原理（原因）：

  負載平衡系統通過叢集部署的方式為CLB執行個體提供服務，所有外部的訪問請求都將平均分散到這些負載平衡系統伺服器上進行轉寄。所以，設定的頻寬峰值將被平均分配到多台系統伺服器上。

  單個串連下載的資料傳輸量上限計算方法為：單個串連下載峰值=設定的負載平衡總頻寬/(N-1)，N為叢集子節點個數，四層監聽是4，七層監聽是8。例如您在控制台上設定的是10 Mbps頻寬上限，當多用戶端同時使用時，總頻寬可以達到10 Mbps。單個用戶端可下載的最大流量為10/(4-1)=3.33 Mbps。

• 推薦方案：

  • CLB執行個體的公網計費方式使用按流量計費。

  • 使用NLB或ALB執行個體，且搭配EIP和共用頻寬。此種方案下Server Load Balancer執行個體具有足夠的彈性，不會有此類限制。

在部分特殊情境中，為什麼CLB執行個體達不到QPS峰值？

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

• 原理（原因）：

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

  單個系統伺服器的QPS上限計算方法為：單個系統伺服器QPS峰值=執行個體總QPS/（N-1）。N為轉寄分組中系統伺服器的個數。例如您在控制台上購買了簡約型I（slb.s1.small）規格的CLB執行個體，對應的QPS為1000，當多用戶端同時使用時，總QPS可以達到1000 QPS。若系統伺服器個數為8，那麼單個系統伺服器的最大QPS為1000/(8-1)=142 QPS。

  說明

  CLB按規格計費執行個體已於2025年06月01日00:00:00（北京時間，UTC+8）停止新購。詳情請參見傳統型負載平衡CLB按規格計費執行個體停售公告。

• 推薦方案：

  • 使用單用戶端短串連進行壓測。

  • 根據實際業務情況減少串連複用。

  • 升配CLB執行個體規格。具體操作，請參見隨用隨付（按規格計費）升降配。

  • 使用ALB執行個體，此種方案下Server Load Balancer執行個體具有足夠的彈性。

在部分特殊情境中，為什麼會出現建立串連速率達不到峰值的現象？

• 情境描述：在購買傳統型負載平衡（CLB）並選擇按規格計費時，某些特定情境（例如單用戶端壓力測試或單一訪問源），可能會導致建立串連速率（CPS）無法達到規格所聲明的水平。

  說明

  CLB按規格計費執行個體已於2025年06月01日00:00:00（北京時間，UTC+8）停止新購。詳情請參見傳統型負載平衡CLB按規格計費執行個體停售公告。

• 原理（原因）：

  負載平衡系統採用叢集部署架構，以確保服務的高可用性和擴充性。所有外部存取請求的串連操作被均勻分配至叢集中的多個系統伺服器進行處理。因此，CLB執行個體的CPS峰值將在這些伺服器之間平均分配。

  單個系統伺服器的CPS峰值計算公式為：單個系統伺服器CPS峰值=執行個體總CPS/(N-1)，其中N代錶轉發分組中系統伺服器的數量。

  例如，若購買的是簡約型I（slb.s1.small）規格的CLB執行個體，其標稱CPS為3000。在多用戶端並發訪問時，整體CPS可達到3000 CPS，若系統伺服器數量為4，則單個伺服器的CPS上限為3000/(4−1)=1000 CPS。

• 推薦方案：

  • 調整CLB計費模式：考慮將CLB執行個體的計費模式從按規格計費變更為更靈活的按使用量計費，按使用量計費的CLB執行個體無需指定規格，相比大多數規格執行個體效能上限更高，避免因規格過小而影響效能。

  • 升級為網路型負載平衡（NLB）：針對高並發及建立串連需求密集的情境，推薦採用NLB服務。相比CLB，NLB不僅在效能上有顯著提升，還提供了更高的彈性，能更有效地應對大規模並發串連的挑戰，從而避免因CLB系統伺服器數量限制而導致的CPS不足問題。

負載平衡各監聽支援的連線逾時時間範圍是多少？

• TCP監聽連線逾時時間：10~900秒。

• HTTP監聽：

  • 串連空閑逾時時間：1~60秒。

  • 串連請求逾時時間：1~180秒。

• HTTPS監聽：

  • 串連空閑逾時時間：1~60秒。

  • 串連請求逾時時間：1~180秒。

為什麼負載平衡服務地址會串連訪問逾時？

從服務端分析，以下情況會導致服務地址串連訪問逾時：

• 服務地址被安全防護

  如流量黑洞和清洗，WAF防護（WAF的特點是建立串連後向用戶端和伺服器叢集雙向發送RST報文）。

• 用戶端連接埠不足

  尤其容易發生在壓測的時候，用戶端連接埠不足會導致建立串連失敗，負載平衡預設會抹除TCP串連的timestamp屬性，Linux協議棧的tw_reuse（time_wait狀態串連複用）無法生效，time_wait狀態串連堆積導致用戶端連接埠不足。

  解決方案：用戶端使用長串連代替短串連。使用RST報文中斷連線（socket設定SO_LINGER屬性） ，而不是發送FIN包這種方式斷開。

• 後端伺服器accept隊列滿

  後端伺服器accept隊列滿，導致後端伺服器不回複SYN-ACK報文，用戶端逾時。

  解決方案：預設的net.core.somaxconn值為128。請根據業務量評估，調整該值以滿足實際需求，然後執行 sysctl -w net.core.somaxconn=<評估後的值>來更改該參數，並重啟後端伺服器上的應用。

• 從四層負載平衡後端伺服器訪問該四層負載平衡的服務地址

  CLB四層監聽（TCP/UDP）不支援後端伺服器同時作為用戶端和服務端，在該負載平衡的後端伺服器上訪問該負載平衡的服務地址會導致串連失敗。常見的觸發情境是後端應用使用URL拼接的方式跳轉訪問CLB的服務地址。

  解決方案：

  • 使用其他用戶端而非四層負載平衡後端伺服器本身訪問。

  • 遷移到網路型負載平衡NLB，並在伺服器組中關閉用戶端地址保持功能。關閉後，伺服器組內的ECS可同時作為後端伺服器和訪問NLB的用戶端。如需擷取用戶端源IP，可通過開啟ProxyProtocol實現。參考ECS如何在NLB中同時作為後端伺服器和用戶端？。

• 對連線逾時的RST處理不當

  負載平衡建立TCP串連後，如果900秒未活動，則會向用戶端和伺服器雙向發送RST中斷連線，有些應用對RST異常處理不當，可能會對已關閉的串連再次發送資料導致應用逾時。

  說明

  900秒為系統設定的預設值，可根據需求調整。

HTTP或HTTPS串連的逾時時間是如何規定的？

• HTTP長串連的請求數量限定是最多連續發送100個請求，超過限定將關閉這條串連。

• HTTP長串連兩個HTTP或HTTPS請求之間的逾時時間是可配置的，配置範圍為1~60秒（存在誤差1~2秒），超過後會關閉TCP串連，如果使用者有長串連使用需求請盡量保持在13秒之內發送一個心跳請求。

• 負載平衡與後端一台ECS執行個體TCP三向交握完成過程的逾時時間為5秒，逾時後選擇下一台ECS執行個體，查詢訪問日誌的upstream回應時間可以定位。

• 負載平衡等待一台ECS執行個體回複請求的回應時間是可配置的，配置範圍為1~180秒，超過後一般會返回504響應碼或408響應碼給用戶端，查詢訪問日誌的upstream回應時間可以協助定位問題。

• HTTPS session重用逾時時間為300秒，超過後同一用戶端需要重新進行完整的SSL握手過程。

用戶端在未收到後端伺服器的回複前主動中斷連線，負載平衡會同時斷開和後端伺服器的串連嗎？

負載平衡在讀寫過程中不會斷開與後端伺服器的串連。

傳統型負載平衡CLB如何開啟後端長串連？

CLB執行個體不支援開啟後端長串連功能，若需要實現此功能，可以建立ALB執行個體並配置HTTP或HTTPS監聽，在對應的ALB伺服器組開啟後端長串連功能，具體請參考建立和管理伺服器組。

通過CLB訪問時延遲明顯高於直接存取後端，如何排查？

通過CLB訪問後端服務時，相比直接存取後端伺服器會有少量延遲增加，這是正常現象。CLB七層監聽採用反向 Proxy架構（Tengine），請求需經過CLB轉寄，會增加一次網路跳轉和協議處理的耗時；四層監聽採用LVS轉寄，額外延遲通常較小。

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

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

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

   • upstream_response_time：從與後端建立串連開始到接收完資料然後關閉串連為止的時間，單位為秒。

2. 判斷延遲來源：

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

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

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

CLB返回502/503/504錯誤碼時如何排查？

通過CLB訪問後端服務時返回 502、503、504 錯誤碼，通常表示請求未能被後端伺服器正常處理。三種錯誤碼的含義如下：

• 502 Bad Gateway：CLB無法將請求轉寄至後端伺服器或無法從後端伺服器擷取響應。常見原因包括後端服務不可達、健全狀態檢查全部失敗等。

• 503 Service Temporarily Unavailable：通常由於流量超限或者後端伺服器不可用。當請求的瞬時流量超過CLB執行個體規格上限時返回此錯誤碼。

• 504 Gateway Time-out：後端伺服器響應逾時。常見原因為後端處理耗時過長或後端伺服器建連逾時。

排查第一步：查看訪問日誌

建議先開啟CLB訪問日誌，查看日誌中的 status（CLB返回給用戶端的狀態代碼）和 upstream_status（後端伺服器返回給CLB的狀態代碼）欄位：

• 若 status 與 upstream_status 相同，很可能CLB直接透傳了後端伺服器返回的異常狀態代碼，請優先排查後端伺服器返回狀態代碼的原因。

• 若 upstream_status 為"-"或與 status 不同，錯誤碼由CLB返回，可參考以下要點排查。

502錯誤排查要點

• 所有後端伺服器健全狀態檢查失敗：當監聽關聯的全部後端伺服器健全狀態檢查均異常時，CLB無法轉寄請求，直接返回502。請在控制台確認健全狀態檢查狀態，並排查健全狀態檢查失敗的原因（如安全性群組未允許存取100.64.0.0/10（CLB系統位址區段）、健全狀態檢查狀態代碼配置不匹配、健全狀態檢查路徑不存在等）。參考CLB健全狀態檢查FAQ。

• 後端返回異常狀態代碼被CLB轉化為502：後端伺服器返回某些異常狀態代碼（如504、444等），CLB可能統一返回502給用戶端。建議查看訪問日誌中的 upstream_status 欄位，確認後端實際返回的狀態代碼，排查後端伺服器異常原因。

• 後端服務異常：後端伺服器負載過高、響應格式異常或串連被異常關閉等情況也可能導致502。建議查看後端伺服器日誌和CPU、記憶體等資源使用方式。

503錯誤排查要點

• 流量超過執行個體規格限制：訪問CLB流量的QPS、頻寬或建立串連數超過當前規格上限時返回503。可從CloudMonitor擷取上述監控指標。

• 瞬時流量超限但監控不顯示：CloudMonitor展示的是分鐘級資料，可能無法展示秒級超限情況。建議通過訪問日誌查看秒級請求數，當日誌中 upstream_status 為"-"時，表示請求未被發送至後端伺服器。

504錯誤排查要點

• 後端響應逾時：後端伺服器在監聽配置的串連請求逾時時間內未返迴響應，CLB返回504。建議查看訪問日誌中的 upstream_response_time 欄位，確認後端的實際回應時間，並適當調整監聽的串連請求逾時時間。

• 後端建連逾時：CLB與後端ECS執行個體TCP三向交握的逾時時間為5秒。如果訪問日誌中upstream_response_time過長，可能與後端伺服器建連異常，建議抓包排查原因。

• 後端負載過高：後端伺服器CPU、記憶體等資源使用率過高，導致回應時間超過逾時時間。建議排查並最佳化後端服務效能，或增加後端伺服器數量分擔壓力。

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

配置CLB後無法正常訪問服務，建議按以下步驟逐層排查：

1. 確認網域名稱解析：如果通過網域名稱訪問，請確認網域名稱已正確解析到CLB執行個體的服務地址。可以通過 nslookup 或 dig 命令驗證解析結果。網域名稱解析錯誤是常見的訪問失敗原因之一。

2. 確認監聽配置：在CLB控制台檢查是否已建立監聽，並確認監聽連接埠和協議配置正確。未添加監聽或監聽連接埠配置有誤會導致請求無法轉寄。

3. 確認健全狀態檢查狀態：在CLB控制台查看後端伺服器的健全狀態檢查狀態。當所有後端伺服器健全狀態檢查均異常時，CLB無法轉寄請求。

4. 確認安全性群組和防火牆：檢查後端伺服器的安全性群組規則和防火牆設定是否允許存取了後端服務連接埠和CLB系統位址區段100.64.0.0/10。

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

6. 排查網路鏈路：從不同網路環境對CLB服務地址進行訪問測試。如果僅本網出現異常，可通過持續 ping 測試或 MTR 路由跟蹤做進一步排查。

通過網域名稱無法訪問CLB但使用IP可以正常訪問，怎麼辦？

最常見的原因是網域名稱未完成ICP備案。

根據相關法規要求，在中國內地地區使用網域名稱通過公網訪問時，網域名稱必須已完成ICP備案。未備案的網域名稱會被阻斷訪問，表現為返回403狀態代碼或串連被重設。

建議按以下步驟排查和處理：

1. 確認網域名稱備案狀態：登入阿里雲ICP備案系統，查詢網域名稱是否已完成備案。如果網域名稱未備案，請先完成ICP備案。參考ICP備案流程。

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

3. 排除其他原因：如果網域名稱已備案且接入備案也已完成，請檢查網域名稱解析是否正確指向CLB的服務地址（可通過 nslookup 或 dig 命令驗證），以及CLB監聽連接埠和協議配置是否與網域名稱訪問方式匹配。

為什麼有時候會話保持會失敗？

• 會話保持功能未開啟：查看是否在監聽配置中已經開啟了會話保持功能。

• HTTP/HTTPS監聽問題：HTTP或HTTPS監聽在後端伺服器返回4xx響應碼的報文中無法插入會話保持所需Cookie。

  解決方案：改用TCP監聽，因為TCP監聽是以源用戶端的IP來做會話保持的，另外後端ECS上也可以插入Cookie，並增加Cookie的判斷來多重保障。

• 302重新導向問題：302重新導向會改變會話保持中的SERVERID字串。

  負載平衡植入Cookie時，如果後端ECS中有回複302重新導向的報文，將改變會話保持中的SERVERID字串，導致會話保持失效。

  排查方法：在瀏覽器端捕獲請求與響應的回複，或用抓包軟體抓包後分析是否存在302的響應報文，對比前後報文的Cookie中的SERVERID字串是否不同了。

  解決方案：改用TCP監聽，因為TCP監聽是以源用戶端的IP來做會話保持的，另外後端ECS上也可以插入Cookie，並增加Cookie的判斷來多重保障。

• 會話保持時間過小：會話保持時間設定過小，會話保持時間過小也會導致會話保持失敗。

如何查看會話保持字串？

可以在瀏覽器中用F12查看響應報文中是否含有SERVERID字串或使用者指定的關鍵字，或者運行curl www.example.com -c /tmp/cookie123 儲存一下Cookie，再用 curl www.example.com -b /tmp/cookie123訪問。

如何使用Linux curl測試負載平衡會話保持？

1. 建立測試頁面。

   在負載平衡所有後端ECS中建立一個顯示本機內網IP的測試頁面。內網IP用於判斷相應請求被指派到的物理伺服器。通過觀察該IP的一致性，判斷負載平衡會話保持的有效性。

   

2. Linux系統內執行curl命令。

   假設負載平衡服務IP地址是 10.170.XX.XX，測試頁面URL為： http://10.170.XX.XX/check.jsp。

   1. 登入測試用的Linux伺服器。

   2. 執行以下命令查詢負載平衡伺服器Cookie值。

      curl -c test.cookie http://10.170.XX.XX/check.jsp

      說明

      阿里雲負載平衡會話保持預設模式是植入Cookie，而curl測試預設不會儲存和發送Cookie，所以必須先儲存相應的Cookie，用於Cookie測試。否則，curl測試結果是隨機的，會誤認為負載平衡會話保持無效。

   3. 執行以下命令持續測試。

      for ((a=1;a<=30;a++));
          do curl  -b test.cookie http://10.170.XX.XX/check.jsp  | grep '10.170.XX.XX';
          sleep 1;
      done

      說明

      a≤30是重複測試次數，可以按需修改。grep '10.170.XX.XX' 是篩選顯示的IP資訊，根據後端ECS內網IP情況進行相應修改。

   4. 觀察上述測試返回的IP，如果是同一台ECS內網IP，則證明負載平衡會話保持有效；反之則證明負載平衡會話保持有問題。

為什麼HTTP監聽訪問正常但HTTPS監聽開啟網址不載入樣式？

現象：

分別建立HTTP和HTTPS監聽，兩個監聽使用同樣的後端伺服器。以HTTP方式訪問監聽連接埠對應的網站時，網站正常顯示，但使用HTTPS監聽訪問時，網站排版顯示錯亂。

原因：

負載平衡預設是不會屏蔽JS檔案載入傳輸的，可能原因：

• 認證和瀏覽器安全層級不相容導致。

• 認證是非正規第三方認證，需要聯絡認證發行者檢查認證問題。

解決方案：

1. 開啟網站時，按照瀏覽器提示載入指令碼。

2. 在用戶端中添加對應認證。

CLB配置HTTP重新導向至HTTPS後，後端伺服器是否還需配置認證？

不需要。只需要在CLB執行個體的HTTPS監聽中配置相關認證即可。具體請參見配置SSL認證。

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

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

HTTP或HTTPS監聽訪問後端伺服器的HTTP協議版本是什嗎？

• 用戶端請求的協議為HTTP 1.1或者HTTP 2.0版本時，七層監聽訪問後端伺服器的HTTP協議版本是HTTP 1.1。

• 用戶端請求的協議為除HTTP 1.1和HTTP 2.0以外其他版本時，七層監聽訪問後端伺服器的HTTP協議版本是HTTP 1.0。

後端伺服器能否擷取用戶端訪問HTTP或HTTPS監聽的協議版本？

可以。

CLB是否支援針對URL限速？

CLB不支援針對URL限速，CLB只支援針對監聽維度做頻寬限速。

ALB支援針對URL限速，您可以配置監聽轉寄規則，針對特定路徑配置QPS限速（需要搭配轉寄動作“轉寄至”使用）。參考下圖：

CLB開啟WAF防護的使用說明？

禁用公網網卡是否影響負載平衡服務？

如果ECS有公網IP，禁用公網網卡會影響負載平衡服務。

因為在有公網網卡的情況下，預設路由會走公網，禁用後無法回包，從而影響負載平衡服務。建議不要禁用公網網卡，如必須禁用，需要修改預設路由為私網才不會影響服務，但需要考慮業務是否依賴公網，如通過公網訪問RDS等。

負載平衡是否支援用戶端請求內建TOA欄位？

不支援。用戶端請求內建的TOA（TCP Option Address）欄位會與負載平衡內部互動使用的TOA欄位衝突，導致無法擷取用戶端的真實IP地址。