All Products
Search
Document Center

Server Load Balancer:FAQ about CLB listeners

Last Updated:Jan 31, 2024

This topic provides answers to some frequently asked questions about listeners of Classic Load Balancer (CLB).

Does CLB support port forwarding?

Yes, CLB supports port forwarding.

For more information, see Redirect requests from HTTP to HTTPS.

If I disable the public network interface controller (NIC), is my CLB service affected?

If an Elastic Compute Service (ECS) instance is assigned a public IP address, your service will be interrupted after you disable the public NIC.

By default, if an ECS instance is assigned a public IP address, the ECS instance uses the public IP address to communicate with the Internet. In this case, network traffic is transferred through the public NIC of the ECS instance. If you disable the public NIC, the ECS instance cannot send responses to the Internet. We recommend that you keep the public NIC enabled. If you want to disable the public NIC, you must change the destination of the default route to a private IP address. Before you modify the default route, make sure that the ECS instance does not need to access resources such as ApsaraDB RDS over the Internet.

Why do connections fail to reach the maximum bandwidth in some scenarios?

  • Description: If you purchase an Internet-facing CLB instance whose Internet metering method is pay-by-bandwidth, and you perform stress tests on a client or use a client to transfer large packets, connections may fail to reach the maximum bandwidth.

  • Causes:

    CLB provides load balancing services by evenly distributing requests across groups of backend servers. Therefore, bandwidth is evenly allocated to each connection.

    The maximum bandwidth of each connection is calculated based on the following formula: Maximum bandwidth per connection = Maximum bandwidth of the CLB instance/(N - 1). N represents the number of server groups. In this example, N is 4. For example, if you set the maximum bandwidth to 10 Mbit/s in the CLB console, the total bandwidth can reach 10 Mbit/s if multiple clients are used at the same time. The maximum bandwidth of each client is calculated based on the following formula: 10/(4 - 1) = 3.33 Mbit/s.

  • Recommended solutions:

    • Change the Internet metering method of the CLB instance to pay-by-data-transfer.

    • Use a Network Load Balancer (NLB) or Application Load Balancer (ALB) instance, an elastic IP address (EIP), and an EIP bandwidth plan. This solution eliminates this issue because it ensures high scalability for the load balancer.

Why does CLB fail to reach the maximum QPS in some scenarios?

  • Description: In scenarios in which a small number of persistent connections are used, not all backend servers in server groups are allocated persistent connections. As a result, the CLB instance cannot reach the maximum QPS.

  • Causes:

    CLB provides load balancing services by evenly distributing requests across groups of backend servers. The maximum QPS that you configure is evenly allocated to each backend server.

    The maximum QPS of each backend server is calculated by using the following formula: Maximum QPS of each backend server = Total QPS/(N - 1). N is the number of backend servers in server groups. For example, if you purchase a CLB instance of the Small I (slb.s1.small) specification in the CLB console, the maximum QPS is 1,000. When multiple clients are used at the same time, the total QPS can reach 1,000. If the number of backend servers is 8, the maximum QPS of each backend server is calculated based on the following formula: 1000/(8 - 1) = 142.

  • Recommended solutions:

How long is the connection timeout period for each type of listener?

  • TCP listener: 10 to 900 seconds.

  • HTTP listener:

    • Idle connection timeout period: 1 to 60 seconds.

    • Connection request timeout period: 1 to 180 seconds.

  • HTTPS listener:

    • Idle connection timeout period: 1 to 60 seconds.

    • Connection request timeout period: 1 to 180 seconds.

Why do connections to the service address of CLB time out?

Possible causes:

  • The service IP address of CLB is blocked for security reasons.

    The IP address of CLB may be blocked due to traffic blackholing, traffic scrubbing, or WAF. WAF offers protection by sending Reset (RST) packets to the client and backend server after a connection is established.

  • Client port exhaustion

    Client port exhaustion can cause connection errors, especially in stress tests. By default, CLB removes the timestamps of TCP connections. As a result, the tw_reuse setting does not take effect and connections in the time_wait state cannot be reused. These accumulated connections exhaust all ports.

    Solutions: Set clients to establish persistent connections instead of short-lived connections. Set the so_linger socket option to close connections by sending RST packets instead of FIN packets.

  • The accept queue of a backend server is full.

    If the accept queue on the backend servers is full, the backend servers can no longer return syn_ack packets. As a result, requests from clients time out.

    Solutions: The default value of the net.core.somaxconn parameter is 128. Run sysctl -w net.core.somaxconn=1024 to change the value of this parameter to 1024 and then restart the application on the backend server.

  • Layer 4 CLB is accessed from backend servers.

    If you access Layer 4 CLB from a backend server, the connection fails. For example, a request that reaches a backend server is redirected to the application on another backend server.

  • RST packets are not correctly responded to.

    If no data is transmitted within 900 seconds after a TCP connection is established on CLB, CLB sends RST packets to the client and the backend server to close the connection. If the application on the backend server does not correctly respond to the RST packet, the application may send data packets after the connection is closed. As a result, a CLB connection timeout occurs.

Why does session persistence fail in some scenarios?

  • Check whether session persistence is enabled for the listener.

  • HTTP and HTTPS listeners cannot persist sessions by inserting cookies into responses that carry 4xx status codes.

    Solutions: Use TCP listeners instead of HTTP or HTTPS listeners. TCP listeners persist sessions based on client IP addresses. Backend servers can insert or validate cookies to ensure that sessions are persisted.

  • HTTP 302 redirects change the SERVERID string for persisting a session.

    When CLB inserts a cookie into a response that carries the HTTP status code 302, the SERVERID string is changed. As a result, the session cannot be persisted.

    To verify the cause, check the requests and responses by using your browser or packet capture software. Then, check whether a 302 status code is included in the packets and whether the SERVERID string in the cookie is changed.

    Solutions: Use TCP listeners instead of HTTP or HTTPS listeners. TCP listeners persist sessions based on client IP addresses. Backend servers can insert or validate cookies to ensure that sessions are persisted.

  • The timeout period is set to a small value. You can set the timeout period to a greater value.

How do I view a cookie?

Open your browser and press F12 to check whether SERVERID or a user-defined cookie is inserted into the response. You can also run the curl www.example.com -c /tmp/cookie123 command to save a cookie and then run the curl www.example.com -b /tmp/cookie123 command to view the cookie.

How do I test session persistence by using the Linux curl command?

  1. Create a test page.

    Create a test page on each backend server. You can view the private IP address of the backend server on the test page. The following figure shows an example of a test page. The private IP address indicates the backend server to which requests are distributed. The private IP address is used to test whether CLB can persist sessions.

  2. Run the curl command in Linux.

    In this example, the IP address of the CLB instance that runs Linux is 10.170.XX.XX and the URL of the created page is http://10.170.XX.XX/check.jsp.

    1. Log on to a server that runs Linux.

    2. Run the following command to query the cookie inserted by the backend server:

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

      By default, CLB persists sessions by inserting cookies. However, curl does not send or save cookies. Therefore, you must save a cookie before you perform the test. Otherwise, the curl test result may show that session persistence is invalid.

    3. After you save the cookie, run the following command:

      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
      Note

      a<=30 indicates the number of tests to be performed. You can set this value based on your business requirements. Set the IP address in grep '10.170.XX.XX' to the private IP address of your ECS instance.

    4. Check the IP addresses that are returned in the preceding tests. If the same IP address is returned, it indicates that CLB can persist sessions.

If a client closes the connection with CLB before the client receives a response, does CLB closes the connection on the backend server side?

No, CLB does not close the connection on the backend server side in this case.

If a request already carries a TCP Option Address (TOA) header before the request is sent to CLB, can CLB preserve the client IP address in the header?

No, CLB cannot preserve the client IP address in the TOA header. By default, if the TOA module is installed, CLB automatically adds the TOA header to preserve client IP addresses. If CLB receives a request that already carries a TOA header, CLB cannot preserve the client IP address in the header.

How do I enable WAF protection for CLB?

You can connect WAF 2.0 and WAF 3.0 to CLB in transparent proxy mode. You can enable WAF for a CLB instance in the WAF console or the CLB console.

Note

WAF 3.0 is released and WAF 2.0 is discontinued. We recommend that you use WAF 3.0. For more information, see the following topics:

Limits

Click to view the limits on enabling WAF for CLB

Item

Description

Supported instances

To add an instance to WAF, the instance must meet the following requirements:

  • The instance is an Internet-facing instance.

  • The instance does not use IPv6.

  • Mutual authentication is disabled for the instance.

Supported regions

  • Chinese mainland: China (Chengdu), China (Beijing), China (Zhangjiakou), China (Hangzhou), China (Shanghai), China (Shenzhen), and China (Qingdao).

  • Outside the Chinese mainland: China (Hong Kong), Malaysia (Kuala Lumpur), and Indonesia (Jakarta).

Number of traffic redirection ports

The limits on the number of traffic redirection ports are the same as the limits on the number of protected objects.

  • Subscription WAF instances: 300 for Basic Edition, 600 for Pro Edition, 2,500 for Enterprise Edition, and 10,000 for Ultimate Edition.

  • Pay-as-you-go WAF instances: 10,000.

TLS security policies

If HTTPS traffic redirection ports are configured, only built-in Transport Layer Security (TLS) security policies are supported. If custom TLS security policies are configured for the ports, you cannot add the ports to WAF. For more information, see Supported TLS security policies.

Services that are protected by Anti-DDoS Pro or Anti-DDoS Premium and WAF

If you want to protect your web services by using Anti-DDoS Pro or Anti-DDoS Premium and WAF, you can add the web services to WAF in transparent proxy mode only if you add the web services to Anti-DDoS Pro or Anti-DDoS Premium by adding a domain name.

Enable WAF for CLB in the WAF console

You can enable WAF 2.0 or WAF 3.0 for Layer 4 and Layer 7 CLB instances in the WAF console.

Enable WAF for CLB in the CLB console

The CLB console allows you to enable WAF 2.0 or WAF 3.0 for Layer 7 CLB instances that use HTTP or HTTPS listeners.

Important

If you cannot enable WAF for your CLB instance, check whether a Layer 7 listener is configured for your CLB instance, and check whether your CLB instance violates service limits. For more information, see Limits.

Category

Description

No WAF 2.0 instances are created in the Alibaba Cloud account, or WAF is not activated in the Alibaba Cloud account

When you enable WAF for your CLB instance, a pay-as-you-go WAF 3.0 instance is automatically created.

A WAF 2.0 instance is created in the Alibaba Cloud account

CLB supports WAF 2.0. If you need to enable WAF 3.0 for your CLB instance, release the WAF 2.0 instance first. For more information about how to release a WAF 2.0 instance, see Terminate the WAF service.

A WAF 3.0 instance is created in the Alibaba Cloud account

CLB supports only WAF 3.0.

The following procedure demonstrates how to enable WAF for a CLB instance in the CLB console.

If you use Method 1 or Method 2 to enable WAF, all the HTTP and HTTPS listeners of the CLB instance are protected by WAF. If you want to enable protection for the custom ports of a listener, go to the details page of the listener.

  • Method 1: Log on to the CLB console. On the Instances page, find the CLB instance that you want to manage and move your pointer over the 未开启 icon. In the popover, click Enable Port Protection in the WAF Protection section.

  • Method 2: Log on to the CLB console. On the Instances page, click the ID of the CLB instance that you want to manage. On the Security Protection tab, click Enable for All.

  • Method 3: When you create an HTTP or HTTPS listener, select Enable WAF Protection in the advanced settings in the configuration wizard. For more information, see Add an HTTP listener and Add an HTTPS listener.

  • Method 4: Click the existing HTTP or HTTPS listener that you want to manage, and turn on WAF Protection in the Listener Details dialog box.

Note

You can disable WAF for your CLB instance in the WAF console.