Server Load Balancer:FAQ about CLB listeners

Does CLB support port forwarding?

Yes.

CLB supports port forwarding. For more information, see Redirect requests from HTTP to HTTPS.

Can Layer 4 CLB listeners listen on a port range?

No, they cannot. To configure a TCP or UDP listener that listens on a port range, you can create a Network Load Balancer (NLB) instance and enable the full-port listening feature for TCP or UDP listeners. For more information, see Enable multi-port listening and forwarding for NLB.

What do I need to know before configuring listener ports for CLB?

Some carriers block traffic over high-risk ports, such as 25, 135, 139, 444, 445, 5800, and 5900, by default in specific regions. Even if you open these ports in your security group rules, users in restricted regions cannot access your CLB instances over them. We recommend that you use other ports for your services.

• For information about ports used by applications on Windows Server operating systems, see the Windows documentation Service overview and network port requirements for Windows.

• For more information about common ports, see Common ports.

Which listeners should I choose for backend services using the WebSocket or WebSocket Secure protocol?

• For backend services that use the WebSocket protocol, use TCP or HTTP listeners.

• For backend services that use the WebSocket Secure protocol, use TCP or HTTPS listeners.

How long does it take for CLB listener configuration modifications to take effect, and what is the impact?

Modifications take effect immediately and apply only to new requests. Existing connections are not affected.

Why do packet losses occur even if monitoring data indicates the maximum bandwidth of a CLB instance is not reached?

Possible causes:

• Bandwidth monitoring data from Alibaba Cloud is based on per-minute averages. If instantaneous traffic exceeds the bandwidth limit for a few seconds within a minute, the average bandwidth for that minute may remain below the configured limit. In this case, the monitoring dashboard shows that the overall bandwidth usage is below the limit, but packet loss may still occur.

• CLB provides load balancing services by distributing requests across groups of backend servers. The configured bandwidth limit is distributed across multiple backend servers. If a client's request exceeds the threshold for a single server, packet loss occurs. For more information, see the calculation method for the download limit per connection in Why do connections fail to reach the maximum bandwidth in some scenarios?.

Why does the traffic shown in my monitoring dashboard exceed the configured rate limit?

CLB uses cluster deployment and distributed rate limiting. Rate limit per node = Total bandwidth of the CLB instance/(N-1), where N is the number of nodes in the cluster. As a result, the total effective rate limit may slightly exceed the configured value.

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

• Description: When you perform stress tests from a single client or transfer large packets to an Internet-facing, pay-by-bandwidth CLB instance, connections may fail to reach the maximum bandwidth.

• Principle (Reason):

  CLB provides load balancing services by distributing requests across groups of backend servers. The configured bandwidth limit is distributed across multiple backend servers.

  The upper limit for data downloaded through a single connection is calculated as follows: Maximum bandwidth per connection = Total bandwidth of the CLB instance/(N-1), where N is the number of nodes in the cluster. For Layer 4 listeners, N is 4. For Layer 7 listeners, N is 8. For example, if you set a 10 Mbps bandwidth limit in the console, the total bandwidth can reach 10 Mbps when multiple clients access the CLB instance at the same time. A single client can download up to 10/(4-1)=3.33 Mbps.

• Solutions:

  • Use pay-by-data-transfer billing for the CLB instance.

  • Use a Network Load Balancer (NLB) or Application Load Balancer (ALB) instance with an Elastic IP Address (EIP) and an Internet Shared Bandwidth instance. This solution provides greater elasticity and avoids this limitation.

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

• Description: If you use only a few persistent connections, not all backend servers in the forwarding group may receive a connection. As a result, the CLB instance may fail to reach its maximum QPS.

• Rationale:

  CLB provides load balancing services by distributing requests across groups of backend servers. The configured QPS limit is distributed across multiple backend servers.

  The maximum QPS per backend server is calculated as follows: Maximum QPS per backend server = Total QPS/(N-1). N is the number of backend servers in the forwarding group. For example, if you purchase a Small I (slb.s1.small) CLB instance in the console, the maximum QPS is 1,000. When multiple clients access the instance at the same time, the total QPS can reach 1,000. If there are eight backend servers, each server supports up to 1000/(8-1)=142 QPS.

  Note

  Subscription CLB instances were discontinued on June 1, 2025, 00:00:00 (UTC+8). For more information, see Discontinuation Notice for subscription CLB instances.

• Recommended solution:

  • Use short-lived connections from a single client for stress testing.

  • Reduce connection reuse as needed.

  • Upgrade the specification of the CLB instance. For more information, see Upgrade or downgrade pay-as-you-go (pay-by-specification) instances.

  • Use an ALB instance, which offers greater elasticity.

In some scenarios, why does the number of new connections fail to reach the upper limit?

• Description: After you purchase a subscription CLB instance, the new connections per second (CPS) rate may fail to reach the specified limit in certain scenarios, such as client-side stress testing or single-source access.

  Note

  Subscription CLB instances were discontinued on June 1, 2025, 00:00:00 (UTC+8). For more information, see Discontinuation Notice for subscription CLB instances.

• Cause:

  CLB uses cluster deployment to ensure high availability and scalability. External connection requests are evenly distributed across multiple system servers in the cluster. As a result, the CPS limit is distributed across these servers.

  The maximum CPS per system server is calculated as follows: Maximum CPS per system server = Total CPS of the CLB instance/(N-1), where N is the number of servers in the forwarding group.

  For example, if you purchase a Small I (slb.s1.small) CLB instance, the declared CPS is 3,000. When multiple clients access the instance at the same time, the total CPS can reach 3,000. If there are four system servers, each server supports up to 3,000/(4−1)=1,000 CPS.

• Solutions:

  • Change the billing method: Switch from subscription to pay-as-you-go billing. Pay-as-you-go CLB instances do not require a specification and offer higher performance than most subscription instances. This avoids performance issues that are caused by undersized specifications.

  • Use Network Load Balancer (NLB): NLB is ideal for high-concurrency scenarios or scenarios that require a high rate of new connections per second. Compared with CLB, NLB delivers significantly better performance and elasticity. This allows NLB to effectively handle large-scale concurrent connections and avoid CPS limitations that are caused by the fixed number of servers in CLB.

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?

A connection to the service endpoint times out on the server side in the following situations:

• The service endpoint is protected.

  This can be caused by traffic blackholing, traffic scrubbing, or Web Application Firewall (WAF) protection. WAF sends Reset (RST) packets to both the client and the backend server after a connection is established.

• Client port exhaustion

  Port exhaustion on the client side commonly occurs during stress testing. By default, CLB removes the timestamp attribute from TCP connections. As a result, the `tw_reuse` setting in the Linux kernel, which reuses connections in the TIME_WAIT state, does not take effect. This causes TIME_WAIT connections to accumulate and exhaust available ports.

  Solution: Use persistent connections instead of short-lived connections on the client side. Close connections by sending RST packets (set the SO_LINGER socket option) instead of FIN packets.

• The accept queue of a backend server is full

  If the accept queue on a backend server is full, the server stops responding with SYN-ACK packets. This causes client requests to time out.

  Solution: The default value of net.core.somaxconn is 128. You can evaluate your business needs and adjust this value. Then, run sysctl -w net.core.somaxconn=<Desired value> to update the parameter and restart applications on the backend servers.

• Accessing CLB from a backend server of a Layer 4 CLB instance

  Layer 4 CLB (TCP/UDP) does not support scenarios where a backend server acts as both a client and a server. Accessing the CLB service address from a backend server in this scenario causes connection failures. A common trigger is a backend application that redirects to the CLB service address using URL concatenation.

  Solutions:

  • Use a different client instead of the Layer 4 CLB backend server.

  • Migrate to Network Load Balancer (NLB) and disable the Preserve Client IP Address feature in the server group. After you disable this feature, ECS instances in the server group can act as both backend servers and clients to access NLB. To obtain the originating IP address, enable ProxyProtocol. For more information, see How do ECS instances act as both backend servers and clients for NLB?.

• Improper handling of RST packets for timed-out connections

  After a TCP connection is established, CLB sends RST packets to both the client and the server to close the connection if no data is transmitted for 900 seconds. Some applications handle RST packets incorrectly and attempt to send data after the connection is closed, which causes timeouts.

  Note

  The default timeout is 900 seconds. You can adjust this value as needed.

What are the timeout values specified for HTTP and HTTPS listeners?

• A maximum of 100 requests can be sent consecutively over an HTTP persistent connection. The connection closes after this limit is reached.

• The idle timeout for an HTTP persistent connection is configurable from 1 to 60 seconds, with a potential margin of error of 1 to 2 seconds. The TCP connection closes after this timeout expires. If your application requires persistent connections, configure clients to send heartbeat requests at an interval of 13 seconds or less.

• The timeout for the TCP three-way handshake between a CLB instance and an Elastic Compute Service (ECS) instance is 5 seconds. If the handshake times out, CLB selects the next ECS instance. You can check the upstream response time in the access logs to locate the issue.

• The time that a CLB instance waits for a response from an ECS instance is configurable from 1 to 180 seconds. If the wait time reaches the timeout, CLB returns an HTTP 504 or 408 status code to the client. You can check the upstream response time in the access logs to locate the issue.

• HTTPS session reuse times out after 300 seconds. After this, the client must perform a complete SSL handshake again.

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

Server Load Balancer maintains connections to backend servers during read/write operations.

Can I enable persistent connections for my CLB instance?

No, you cannot. CLB does not support enabling persistent connections to backend servers. To implement this feature, you can create an ALB instance and configure HTTP or HTTPS listeners. Then, enable persistent connections in the corresponding ALB server group. For more information, see Create and manage server groups.

Why is latency significantly higher when accessing backend services through CLB compared to direct access?

A slight increase in latency is normal when you access backend services through CLB instead of directly. This is because Layer 7 CLB listeners use a reverse proxy architecture (Tengine), which adds one network hop and protocol processing overhead. Layer 4 listeners use LVS forwarding, which results in minimal additional latency.

If latency is significantly higher, follow these steps to troubleshoot the issue:

1. Enable access logs and analyze latency fields: Enable CLB access logs and focus on these fields:

   • request_time: The time from when the first request packet is received to when the response is returned, in seconds.

   • upstream_response_time: The time from when a connection is established with the backend server to when all data is received and the connection is closed, in seconds.

2. Determine the source of latency:

   • If the upstream_response_time value is high, the latency likely originates from slow backend processing. Investigate backend application performance, database query efficiency, and CPU and memory usage, or add backend servers to distribute the load.

   • If the request_time value is much greater than the upstream_response_time value, the latency likely occurs on the network path between the client and the CLB instance. Run continuous ping tests or MTR traceroutes from the client to the CLB service address to identify network issues.

3. Cross-region access: If the client and the CLB instance reside in different regions, the physical distance inevitably introduces network latency. You can use Global Accelerator (GA) to optimize cross-region access.

How do I troubleshoot 502/503/504 errors returned by CLB?

When a CLB instance returns a 502, 503, or 504 error, it means the request was not processed correctly by the backend server. The meanings of these error codes are as follows:

• 502 Bad Gateway: The CLB instance cannot forward the request to the backend server or cannot receive a response from the backend server. Common causes include unreachable backend services or failed health checks.

• 503 Service Temporarily Unavailable: This error is usually caused by traffic that exceeds limits or backend server unavailability. CLB returns this error when instantaneous traffic exceeds the instance's specification limit.

• 504 Gateway Time-out: The backend server response timed out. Common causes include excessive backend processing time or a backend connection establishment timeout.

Step 1: Check access logs

First, enable CLB access logs and check the status field (the status code that is returned to the client by CLB) and the upstream_status field (the status code that is returned to CLB by the backend server):

• If the status value matches the upstream_status value, the CLB instance likely forwarded the abnormal status code from the backend server. Prioritize investigating why the backend server returned that status code.

• If the upstream_status value is "-" or differs from the status value, the error code was generated by CLB. Refer to the following points for troubleshooting.

Troubleshooting 502 errors

• All backend servers fail health checks: When all backend servers that are associated with a listener fail health checks, the CLB instance cannot forward requests and returns a 502 error. Confirm the health check status in the console and investigate the causes of the failures. For example, security group rules do not allow traffic from 100.64.0.0/10 (the CLB system CIDR block), health check status codes are mismatched, or health check paths do not exist. For more information, see FAQ about CLB health checks.

• The backend server returns abnormal status codes that are converted to 502 by CLB: CLB may return a 502 error to clients when the backend server returns certain abnormal status codes, such as 504 or 444. Check the upstream_status field in access logs to confirm the actual status code that is returned by the backend server and investigate the root cause.

• Backend service abnormalities: High backend server load, malformed response formats, or unexpected connection closures can also cause 502 errors. Review backend server logs and resource usage, such as CPU and memory.

Troubleshooting 503 errors

• Traffic exceeds instance limits: CLB returns a 503 error when the QPS, bandwidth, or new connection rates exceed the limits of the current specification. You can monitor these metrics using CloudMonitor.

• Instantaneous traffic exceeds limits but monitoring does not show it: CloudMonitor displays minute-level data and may miss second-level spikes. Check access logs for second-level request counts. If the upstream_status value is "-", the request was not sent to the backend server.

Troubleshooting 504 errors

• Backend response timeout: CLB returns a 504 error if the backend server does not respond within the configured connection request timeout period. Check the upstream_response_time field in access logs to verify the actual backend response time and adjust the connection request timeout period as needed.

• Backend connection establishment timeout: The timeout for the TCP three-way handshake between a CLB instance and an ECS instance is 5 seconds. If the upstream_response_time value is excessively long in access logs, connection establishment with the backend server may be failing. You can capture packets to investigate.

• High backend server load: High CPU or memory usage on the backend server can cause response times to exceed the timeout. Optimize backend service performance or add backend servers to distribute the load.

How do I troubleshoot when I cannot access services through CLB?

If you cannot access your services after you configure CLB, follow these steps to troubleshoot the issue:

1. Verify domain name resolution: If you access the service using a domain name, verify that the domain name resolves to the service address of the CLB instance. You can use the nslookup or dig command to validate the resolution. Incorrect DNS resolution is a common cause of access failures.

2. Verify the listener configuration: In the CLB console, verify that a listener is created and that the listener port and protocol are configured correctly. Missing listeners or incorrect port configurations prevent request forwarding.

3. Confirm the health check status: In the CLB console, check the health check status of backend servers. If all backend servers fail health checks, CLB cannot forward requests.

4. Confirm security group and firewall settings: Verify that the security group rules and firewall settings of the backend server allow traffic on the backend service port and from the CLB system CIDR block 100.64.0.0/10.

5. Confirm backend service availability: Log on to the backend server and use telnet <Private IP of backend server> <Port> (for Layer 4) or curl -I http://<Private IP of backend server> (for Layer 7) to verify that the backend service responds as expected.

6. Troubleshoot network connectivity: Test access to the CLB service address from different network environments. If only your local network has issues, run continuous ping tests or MTR traceroutes for further investigation.

I cannot access CLB using a domain name, but access works fine using the IP address. What should I do?

The most common cause is that the domain name does not have an ICP filing.

According to regulations, domain names that provide public network access in the Chinese mainland must have an ICP filing. Unfiled domain names are blocked, which results in 403 status codes or connection resets.

Follow these steps to troubleshoot and resolve the issue:

1. Confirm the ICP filing status of the domain name: Log on to the Alibaba Cloud ICP Filing System to check whether the domain name has an ICP filing. If not, complete the ICP filing first. For more information, see ICP filing process.

2. Confirm whether provider registration is required: If the domain name has been filed with another cloud provider but is used on Alibaba Cloud for the first time, you must perform provider registration to add Alibaba Cloud as a service provider in the filing information. Failure to complete provider registration can also block access.

3. Rule out other causes: If the domain name is filed and provider registration is complete, verify that DNS resolution points to the CLB service address. You can validate this using nslookup or dig. Also, verify that the CLB listener port and protocol configurations match the domain name access method.

Why does session persistence fail in some scenarios?

• Session persistence is not enabled: Verify that session persistence is enabled in the listener configuration.

• HTTP/HTTPS listener issue: HTTP or HTTPS listeners cannot insert session persistence cookies into responses that have a 4xx status code.

  Solution: Use TCP listeners instead. TCP listeners maintain sessions based on the client's source IP address. Alternatively, you can configure backend ECS instances to insert and validate cookies for added reliability.

• 302 redirect issue: A 302 redirect can change the SERVERID string that is used for session persistence. When a CLB instance inserts a cookie into a response that has an HTTP 302 status code, the SERVERID string changes, which breaks session persistence.

  When Server Load Balancer inserts a cookie, if a backend ECS instance returns a 302 redirect message, the SERVERID string for session persistence is changed, which causes session persistence to fail.

  To diagnose this issue, you can capture requests and responses in a browser or use packet capture software to check for 302 responses and compare the SERVERID string in cookies before and after the redirect.

  Solution: Use TCP listeners instead. TCP listeners maintain sessions based on the client's source IP address. Alternatively, you can configure backend ECS instances to insert and validate cookies for added reliability.

• The session persistence timeout is too short: Setting a short timeout period can cause session persistence to fail.

How do I view a session persistence string?

You can open your browser and press F12 to check whether the response contains the SERVERID string or a user-defined keyword. Alternatively, you can run curl www.example.com -c /tmp/cookie123 to save a cookie, and then run curl www.example.com -b /tmp/cookie123 to access the site.

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

1. Create a test page.

   On each backend ECS instance, create a test page that displays the private IP address of the instance. The private IP address identifies the server that handles the request. If the same IP address is returned for each request, session persistence is successful.

   

2. Run the curl command in Linux.

   Assume that the CLB service IP address is 10.170.XX.XX and the test page URL is http://10.170.XX.XX/check.jsp.

   1. Log on to the Linux test server.

   2. Run the following command to retrieve the cookie that is set by the CLB server:

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

      Note

      By default, CLB maintains sessions by inserting cookies. However, curl does not save or send cookies by default. Therefore, you must save the cookie before testing. Otherwise, curl test results will appear random and incorrectly suggest that session persistence failed.

   3. You can execute the following command to perform continuous testing.

      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 is the number of test iterations and can be adjusted as needed. Replace grep '10.170.XX.XX' with the private IP address of your ECS instance.

   4. Check the IP addresses that are returned by the tests. If the same ECS private IP address appears consistently, session persistence is working. Otherwise, session persistence is failing.

Why do the style sheets fail to load when I open a website over an HTTPS listener?

Phenomenon:

You created an HTTP listener and an HTTPS listener that use the same backend servers. When you access the website over the HTTP listener with the specified port number, the website is displayed correctly. However, when you access the website over the HTTPS listener, the layout is distorted.

Cause:

By default, CLB does not block the loading or transferring of JavaScript files. Possible causes include the following:

• The certificate is incompatible with the browser's security level.

• The certificate is an invalid third-party certificate. Contact the certificate issuer to verify the certificate's validity.

Solution:

1. When you open the website, load the scripts as prompted by the browser.

2. Add the required certificate to the client.

If I enable traffic redirection from an HTTP listener to an HTTPS listener, do I need to deploy certificates on backend servers?

No, you do not. You need to deploy certificates only on the CLB instance and configure them for the HTTPS listener. For more information, see Configure an SSL certificate.

After CLB updates the certificate, the expiration time of the domain name certificate displayed in the browser remains unchanged.

This issue typically occurs if your CLB instance is integrated with WAF 2.0 in transparent proxy mode. In this mode, the certificate on the WAF side is not immediately updated. WAF synchronizes certificates from CLB periodically. To force an immediate update, you can go to the WAF console, disable traffic forwarding for the protected domain, and then immediately re-enable it. This action forces WAF to refresh its certificate status from CLB. Note that this operation causes a brief service interruption of approximately 1 to 2 seconds.

Which version of HTTP is used by HTTP and HTTPS listeners when they access backend servers?

• If a client sends a request over HTTP/1.1 or HTTP/2, the Layer 7 listener uses HTTP/1.1 to forward the request to a backend server.

• If a client sends a request over a protocol other than HTTP/1.1 and HTTP/2, the Layer 7 listener uses HTTP/1.0 to forward the request to a backend server.

Can backend servers obtain the protocol version that a client uses to access the HTTP or HTTPS listener?

Yes.

Does CLB support QPS rate limit on a specific URL?

CLB does not support URL-based rate limiting. Bandwidth throttling is supported only at the listener dimension.

ALB supports URL-based rate limiting. You can configure listener forwarding rules to set QPS rate limits for specific paths. This requires using the Forward To forwarding action. For more information, see the following figure:

How do I enable WAF protection for CLB?

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

Yes, it is. If an Elastic Compute Service (ECS) instance has a public IP address, disabling the public network interface controller (NIC) affects the CLB service.

By default, if an ECS instance has a public IP address, it uses this IP address for communication. Traffic flows 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 do not disable the public NIC of your ECS instance. If you must disable it, change the default route destination to a private IP address to avoid service disruption. Also, confirm whether your service requires Internet access, such as accessing ApsaraDB RDS instances over the Internet.

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, it cannot. A client request that carries a TCP Option Address (TOA) header conflicts with the TOA header that is used internally by CLB. This conflict prevents the retrieval of the client's originating IP address.