本文介紹傳統型負載平衡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和共用頻寬。此種方案下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執行個體規格。具體操作，請參見隨用隨付（按規格計費）升降配。
使用ALB執行個體，此種方案下Server Load Balancer執行個體具有足夠的彈性。
負載平衡各監聽支援的連線逾時時間範圍是多少？
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防護。更多資訊，請參見：
使用限制
通過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（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 Application Firewall接入管理頁面關閉WAF防護。