本文介紹傳統型負載平衡CLB（Classic Load Balancer）監聽服務相關的常見問題。
包含以下問題：
問題類別 | 常見問題 |
監聽配置 | |
頻寬問題 | |
串連管理 | |
會話保持 | |
七層監聽 |
傳統型負載平衡CLB是否支援連接埠跳轉？
支援。
CLB支援連接埠重新導向，具體操作樣本，請參見使用CLB將HTTP訪問重新導向至HTTPS。
負載平衡CLB的四層監聽是否支援監聽連接埠範圍？
不支援。若您需要配置TCP或者UDP監聽並對一個連接埠範圍進行監聽，請建立網路型負載平衡NLB執行個體，啟用TCP監聽或者UDP監聽的全連接埠功能。相關操作文檔請參見使用NLB全連接埠監聽功能實現多連接埠流量轉寄。
負載平衡CLB配置監聽連接埠時需要注意什麼問題？
部分電訊廠商將連接埠25、135、139、444、445、5800、5900等標記為高危連接埠，並預設屏蔽這些連接埠。即使您在安全性群組規則中允許存取了這些連接埠，受限地區的使用者仍無法訪問。因此，建議您考慮使用其他非高危連接埠來承載業務。
關於Windows Server系統應用的連接埠說明，請參見《微軟文檔》Windows伺服器系統的服務概述和網路連接埠要求。
常用連接埠資訊請參見常用連接埠。
負載平衡是否支援用戶端請求內建TOA欄位？
不支援。用戶端請求內建的TOA（TCP Option Address）欄位會與負載平衡內部互動使用的TOA欄位衝突，導致無法擷取用戶端的真實IP地址。
但您可以通過以下方法來擷取用戶端的真實IP：
後端伺服器部署WebSocket或者WebSocket Secure業務，監聽該怎麼配？
後端伺服器部署WebSocket業務，可以配置TCP監聽或者HTTP監聽。
後端伺服器部署WebSocket Secure業務，可以配置TCP監聽或者HTTPS監聽。
修改CLB監聽配置的生效機制及影響？
修改後立即生效，且僅對新發起的請求有效，不會影響進行中的請求串連。
CLB開啟WAF防護的使用說明？
CLB執行個體支援WAF 2.0透明化接入和WAF 3.0透明化接入。您可以通過Web應用防護牆控制台和傳統型負載平衡CLB控制台開啟WAF防護。
WAF 3.0發行，且WAF 2.0已停止新購，推薦您使用WAF 3.0防護。更多資訊，請參見：
使用限制
通過Web Application Firewall控制台開啟
通過Web Application Firewall控制台，支援為四層和七層CLB執行個體開啟WAF 2.0防護或WAF 3.0防護。
四層CLB執行個體接入WAF 3.0，請參見為四層CLB（TCP）開啟WAF防護。
七層CLB執行個體接入WAF 3.0，請參見為CLB執行個體開啟WAF防護。
四層CLB執行個體接入WAF 2.0，請參見四層SLB執行個體連接埠引流、使用教程和透明接入。
七層CLB執行個體接入WAF 2.0，請參見七層SLB執行個體連接埠引流、使用教程和透明接入。
通過負載平衡控制台開啟
目前，通過負載平衡控制台僅支援為七層（HTTP/HTTPS）監聽的CLB執行個體開啟WAF 2.0防護或WAF3.0防護。
若無法開啟WAF防護或開啟失敗，請檢查是否建立了七層監聽並檢查適用範圍。
分類 | 說明 |
阿里雲帳號沒有WAF 2.0執行個體或未開啟WAF | CLB開啟WAF防護時會自動開通WAF3.0隨用隨付版本。 |
阿里雲帳號已有WAF 2.0執行個體 | CLB支援開啟WAF 2.0防護。如需開啟WAF 3.0防護，請先釋放WAF 2.0執行個體。關於釋放WAF 2.0執行個體的操作，請參見關閉WAF。 |
阿里雲帳號已有WAF 3.0執行個體 | CLB僅支援開啟WAF 3.0防護。 |
通過負載平衡控制台開啟WAF防護：
通過方式一和方式二開啟成功後，執行個體下的HTTP、HTTPS連接埠將全部開啟防護能力，如需自訂連接埠防護可前往目標監聽的監聽詳情頁操作。
方式一：登入傳統型負載平衡CLB控制台，在實例管理頁面，將滑鼠移至上方在目標執行個體名稱後的
表徵圖，然後在氣泡框中單擊WAF安全防護地區的開啟連接埠防護。方式二：登入傳統型負載平衡CLB控制台，在實例管理頁面，單擊目標執行個體ID，單擊安全防護頁簽，然後單擊全部開啟。
方式三：在建立HTTP或HTTPS監聽時，在監聽設定精靈進階配置選中為監聽開啟WAF安全防護。具體操作，請參見HTTP/HTTPS監聽和添加HTTPS監聽。
方式四：已建立HTTP或HTTPS監聽時，在目標監聽的監聽詳情頁支援開啟WAF安全防護。
如需關閉WAF防護，請前往Web Application Firewall接入管理頁面關閉WAF防護。
禁用公網網卡是否影響負載平衡服務？
如果ECS有公網IP，禁用公網網卡會影響負載平衡服務。
因為在有公網網卡的情況下，預設路由會走公網，禁用後無法回包，從而影響負載平衡服務。建議不要禁用公網網卡，如必須禁用，需要修改預設路由為私網才不會影響服務，但需要考慮業務是否依賴公網，如通過公網訪問RDS等。
在部分特殊情境中，為什麼會出現串連達不到頻寬峰值的現象？
情境描述：購買公網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執行個體提供服務，限速採用的是分布式限速。單個節點的限速峰值=設定的負載平衡總頻寬/(N-1)，N為叢集子節點個數，所以整體限速值會略大於配置的限速值。
為什麼監控資料顯示頻寬未超規格，但仍然發生了流量丟棄？
通常由以下原因導致：
阿里雲的頻寬監控資料基於每分鐘的平均值。當一分鐘內特定秒的瞬時流量超過了執行個體的頻寬節流設定，只要一分鐘的平均頻寬未超出設定規格，監控圖表顯示的整體頻寬使用量會顯示低於頻寬規格。
負載平衡系統通過叢集部署的方式為CLB執行個體提供服務，所有外部的訪問請求都將平均分散到這些負載平衡系統伺服器上進行轉寄。設定的頻寬峰值實際是被平均分配到多台系統伺服器上。如果某用戶端請求串連下載的資料量超過單台伺服器的閾值，就會導致流量被丟棄。更多資訊，請參見在部分特殊情境中，為什麼會出現串連達不到頻寬峰值的現象？中單個串連下載資料傳輸量上限的計算方法。
在部分特殊情境中，為什麼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=<評估後的值>來更改該參數，並重啟後端伺服器上的應用。從四層負載平衡後端伺服器訪問該四層負載平衡的服務地址
四層負載平衡，在該負載平衡的後端伺服器上訪問該負載平衡的服務地址會導致串連失敗，常見的情境是後端應用使用URL拼接的方式跳轉訪問。
對連線逾時的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伺服器組開啟後端長串連功能，具體請參考建立和管理伺服器組。
為什麼有時候會話保持會失敗？
會話保持功能未開啟：查看是否在監聽配置中已經開啟了會話保持功能。
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測試負載平衡會話保持？
建立測試頁面。
在負載平衡所有後端ECS中建立一個顯示本機內網IP的測試頁面。內網IP用於判斷相應請求被指派到的物理伺服器。通過觀察該IP的一致性，判斷負載平衡會話保持的有效性。
Linux系統內執行curl命令。
假設負載平衡服務IP地址是 10.170.XX.XX，測試頁面URL為：
http://10.170.XX.XX/check.jsp。登入測試用的Linux伺服器。
執行以下命令查詢負載平衡伺服器Cookie值。
curl -c test.cookie http://10.170.XX.XX/check.jsp說明阿里雲負載平衡會話保持預設模式是植入Cookie，而curl測試預設不會儲存和發送Cookie，所以必須先儲存相應的Cookie，用於Cookie測試。否則，curl測試結果是隨機的，會誤認為負載平衡會話保持無效。
執行以下命令持續測試。
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情況進行相應修改。觀察上述測試返回的IP，如果是同一台ECS內網IP，則證明負載平衡會話保持有效；反之則證明負載平衡會話保持有問題。
為什麼HTTP監聽訪問正常但HTTPS監聽開啟網址不載入樣式？
現象：
分別建立HTTP和HTTPS監聽，兩個監聽使用同樣的後端伺服器。以HTTP方式訪問監聽連接埠對應的網站時，網站正常顯示，但使用HTTPS監聽訪問時，網站排版顯示錯亂。
原因：
負載平衡預設是不會屏蔽JS檔案載入傳輸的，可能原因：
認證和瀏覽器安全層級不相容導致。
認證是非正規第三方認證，需要聯絡認證發行者檢查認證問題。
解決方案：
開啟網站時，按照瀏覽器提示載入指令碼。
在用戶端中添加對應認證。
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配置HTTP重新導向至HTTPS後，後端伺服器是否還需配置認證？
不需要。只需要在CLB執行個體的HTTPS監聽中配置相關認證即可。具體請參見配置SSL認證。
CLB是否支援針對URL限速？
CLB不支援針對URL限速，CLB只支援針對監聽維度做頻寬限速。
ALB支援針對URL限速，您可以配置監聽轉寄規則，針對特定路徑配置QPS限速（需要搭配轉寄動作“轉寄至”使用）。參考下圖：
CLB更新認證後，瀏覽器中查看到的網域名稱認證到期時間沒變
這種情況通常是因為CLB通過透明接入的方式接入了WAF2.0，WAF側的認證還未更新。WAF同步CLB的認證有周期性，如需立即完成同步，可以在WAF側關閉引流再重新開啟，強制重新整理認證狀態；請注意，此操作會導致業務出現1-2秒的閃斷。