本文介紹傳統型負載均衡CLB（Classic Load Balancer）監聽服務相關的常見問題。
傳統型負載均衡CLB是否支持端口跳轉？
支持。
CLB支持端口重定向，具體操作示例，請參見使用CLB將HTTP訪問重定向至HTTPS。
禁用公網網卡是否影響負載均衡服務？
如果ECS有公網IP，禁用公網網卡會影響負載均衡服務。
因為在有公網網卡的情況下，默認路由會走公網，禁用后無法回包從而影響負載均衡服務。建議不要禁止公網網卡，如一定要禁止，需要修改默認路由為私網才不會影響服務，但需要考慮業務是否對公網有依賴，如通過公網訪問RDS等。
在部分特殊場景中，為什么會出現連接達不到帶寬峰值的現象？
場景描述：當購買公網CLB且公網計費方式為按固定帶寬時，單客戶端壓測或單客戶端傳輸超大數據包等特殊場景下，可能會出現連接達不到帶寬峰值的現象。
原理（原因）：
因為負載均衡系統通過集群部署的方式為CLB實例提供服務，所有外部的訪問請求都將平均分散到這些負載均衡系統服務器上進行轉發。所以，設定的帶寬峰值將被平均設定在多臺系統服務器上。
單個連接下載的流量上限計算方法為：
單個連接下載峰值=設置的負載均衡總帶寬/(N-1)，N為流量轉發分組個數，當前值固定為4。例如您在控制臺上設置的是10 Mbps帶寬上限，當多客戶端同時使用時，總帶寬可以達到10 Mbps。單個客戶端可下載的最大流量為10/(4-1)=3.33 Mbps。推薦方案：
CLB實例的公網計費方式使用按流量計費。
使用NLB或ALB實例，且搭配EIP和共享帶寬。此種方案下負載均衡實例具有足夠的彈性，不會有此類限制。
在部分特殊場景中，為什么CLB實例達不到QPS峰值？
場景描述：在使用少量長連接的業務場景下，轉發分組中的系統服務器可能不會全部被分配到長連接，可能會出現CLB實例達不到QPS峰值的現象。
原理（原因）：
因為負載均衡系統通過集群部署的方式為負載均衡實例提供服務，所有外部的訪問請求都將平均分散到這些負載均衡系統服務器上進行轉發。所以，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實例規格。具體操作，請參見包年包月升配和按量付費（按規格計費）升降配。
使用ALB實例，此種方案下負載均衡實例具有足夠的彈性。
負載均衡各監聽支持的連接超時時間范圍是多少？
TCP監聽連接超時時間：10~900秒。
HTTP監聽：
連接空閑超時時間：1~60秒。
連接請求超時時間：1~180秒。
HTTPS監聽：
連接空閑超時時間：1~60秒。
連接請求超時時間：1~180秒。
在部分特殊場景中，為什么會出現新建連接速率達不到峰值的現象？
場景描述：在購買傳統型負載均衡（CLB）并選擇按規格計費時，某些特定場景（例如單客戶端壓力測試或單一訪問源），可能會導致新建連接速率（CPS）無法達到規格所聲明的水平。
原理（原因）：
負載均衡系統采用集群部署架構，以確保服務的高可用性和擴展性。所有外部訪問請求的連接操作被均勻分配至集群中的多個系統服務器進行處理。因此，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不足問題。
為什么負載均衡服務地址會連接訪問超時？
從服務端分析，以下情況會導致服務地址連接訪問超時：
服務地址被安全防護
如流量黑洞和清洗，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監聽在后端服務器返回4xx響應碼的報文中無法插入會話保持所需Cookie。
解決方案：改用TCP監聽，因為TCP監聽是以源客戶端的IP來做會話保持的，另外后端ECS上也可以插入Cookie，并增加Cookie的判斷來多重保障。
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，則證明負載均衡會話保持有效；反之則證明負載均衡會話保持有問題。
一個請求通過負載均衡到達后端服務器，如果客戶端在未收到后端服務器的回復前主動斷開和負載均衡的連接，負載均衡會同時斷開和后端服務器的連接么？
負載均衡在讀寫過程中不會斷開與后端服務器的連接。
負載均衡是否支持客戶端請求自帶TOA字段？
不支持。客戶端請求自帶的TOA（TCP Option Address）字段會與負載均衡內部交互使用的TOA字段沖突，導致無法獲取客戶端的真實IP地址。
但您可以通過以下方法來獲取客戶端的真實IP：
CLB開啟WAF防護的使用說明？
CLB實例支持WAF 2.0透明化接入和WAF 3.0透明化接入。您可以通過Web應用防護墻控制臺和傳統型負載均衡CLB控制臺為CLB實例開啟WAF防護。
WAF 3.0已發布及WAF 2.0已停止新購，推薦您使用WAF 3.0防護。更多信息，請參見：
使用限制
限制項類型 | 描述 |
支持的實例 | 同時滿足：
|
支持的地域 |
|
引流端口配置的數量 | 與防護對象數量保持一致：
|
TLS安全策略 | 配置HTTPS監聽的引流端口僅支持CLB內置的TLS安全策略。如果該端口配置了內置TLS安全策略以外的其他自定義TLS安全策略，會導致接入失敗。更多信息，請參見TLS安全策略有哪些。 |
業務同時接入DDoS高防和WAF | 如果您的業務需要同時接入DDoS高防和WAF，則只有在業務通過域名接入（即七層接入模式）接入DDoS高防時，該業務才支持通過透明接入模式接入WAF。 |
通過Web應用防火墻控制臺開啟
通過Web應用防火墻控制臺，支持為四層和七層CLB實例開啟WAF 2.0防護或WAF 3.0防護。
四層CLB實例接入WAF 3.0，請參見為四層CLB（TCP）開啟WAF防護。
七層CLB實例接入WAF 3.0，請參見為七層CLB（HTTP/HTTPS）開啟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監聽。
方式四：已創建HTTP或HTTPS監聽時，在目標監聽的監聽詳情頁支持開啟WAF安全防護。
如需關閉WAF防護，請前往Web應用防火墻接入管理頁面關閉WAF防護。