本文介绍传统型负载均衡CLB（Classic Load Balancer）监听服务相关的常见问题。
传统型负载均衡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防护。更多信息，请参见：
使用限制
通过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防护。