CLB listener FAQ

Port redirection support in CLB

Yes.

CLB supports port redirection. For an example, see Use CLB to redirect HTTP requests to HTTPS.

Port range support for Layer 4 listeners

No. To listen on a port range with a TCP or UDP listener, create a Network Load Balancer (NLB) instance and enable the All Ports feature for the listener. For more information, see Use the NLB All Ports listener feature to forward traffic on multiple ports.

Listener port configuration considerations

Some carriers classify ports such as 25, 135, 139, 444, 445, 5800, and 5900 as high-risk and block them by default. Even if you allow these ports in security group rules, users in restricted regions may not be able to access your services. We recommend using other non-high-risk ports.

• For information about the ports that are used by applications on Windows Server systems, see Microsoft Documentation Service overview and network port requirements for Windows Server.

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

Listener configuration for WebSocket

• If your backend servers host WebSocket services, you can configure a TCP listener or an HTTP listener.

• If your backend servers host WebSocket Secure services, you can configure a TCP listener or an HTTPS listener.

Effect of listener configuration changes

Changes take effect immediately and apply only to new requests. Existing connections are unaffected.

Special characters in URL forwarding rules

You must URL-encode special characters in a URL for proper access. For example, the hash character (#) is encoded as %23, so the URL would be http://www.example.com/%23/. For complete encoding rules, see RFC 3986.

Manage backend servers for forwarding rules

On the Forwarding Rule page, click the name of the target vServer group in the Virtual Server Group column. On the Edit Virtual Server Group page, you can add or delete backend servers, and modify their ports or weights.

Traffic drops without exceeding bandwidth limit

This issue typically occurs for the following reasons:

• Alibaba Cloud's bandwidth monitoring uses one-minute averages. If an instantaneous traffic spike within a second exceeds the instance's bandwidth limit, the system drops traffic. This can happen even if the average bandwidth for the entire minute remains below the configured limit. As a result, the monitoring chart might show that the overall bandwidth usage is lower than the specified limit.

  Note

  For a Layer-4 listener, you can enable the high-precision second-level monitoring feature to view second-level traffic peaks.

• CLB instances run on a server cluster that evenly distributes incoming requests among its servers. The configured peak bandwidth is also distributed across the servers in the cluster. If the data downloaded by a single client connection exceeds the threshold of an individual server, the system drops the traffic. For more information about how the maximum download traffic for a single connection is calculated, see Why can't a connection reach the peak bandwidth in certain scenarios?.

Monitored traffic exceeds configured limit

CLB instances use a server cluster for distributed rate limiting. The peak rate limit for a single node is calculated as Peak rate limit for a single node = Total configured bandwidth / (N - 1), where N is the number of nodes in the cluster. As a result, the total effective rate limit might be slightly higher than the configured value.

Connection fails to reach peak bandwidth

• Scenario: A single connection to a public-facing CLB instance that uses the pay-by-specification (fixed bandwidth) billing method may not reach the configured peak bandwidth. This issue often occurs during single-client stress testing or when transferring a very large data packet.

• Cause:

  CLB instances run on a server cluster. The cluster evenly distributes all incoming requests among its servers.

  The maximum download traffic for a single connection is calculated as follows: Peak download traffic per connection = Total configured bandwidth / (N - 1), where N is the number of servers in the cluster. N is 4 for a Layer-4 listener and 8 for a Layer-7 listener. For example, if you set the bandwidth limit to 10 Mbps in the console, the total bandwidth can reach 10 Mbps when multiple clients are used simultaneously. However, the maximum traffic that a single client can download is 10 / (4 - 1) = 3.33 Mbps.

• Solution:

  • Use the pay-by-traffic billing method for the public-facing CLB instance.

  • Use an NLB or ALB instance with an EIP and shared bandwidth. This configuration is more elastic and avoids this limitation.

CLB instance fails to reach peak QPS

• Scenario: When using a small number of persistent connections, the connections may not be distributed to all servers in the forwarding cluster. As a result, the CLB instance may not reach its peak QPS.

• Cause:

  CLB instances are deployed in a cluster. The system distributes incoming requests evenly across the servers in the cluster. Therefore, the peak QPS of a CLB instance is also distributed across these servers.

  The maximum QPS for a single server is calculated as follows: Peak QPS per server = Total instance QPS / (N - 1), where N is the number of servers in the forwarding cluster. For example, if you purchase a CLB instance of the slb.s1.small specification, which supports 1,000 QPS, the total QPS can reach 1,000 when multiple clients are used. However, if the cluster has 8 servers, the maximum QPS for a single server is 1000 / (8 - 1) = 142 QPS.

  Note

  New purchases of pay-by-specification CLB instances are discontinued from 00:00:00 on January 1, 2026 (UTC+8). For more information, see Discontinuation of new purchases for pay-by-specification Classic Load Balancer (CLB) instances.

• Solution:

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

  • Reduce connection reuse based on your actual business requirements.

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

  • Use an ALB instance. This instance type offers greater elasticity.

New connection rate fails to reach peak

• Scenario: When you use a pay-by-specification Classic Load Balancer (CLB) instance, its new connection rate (CPS) may not reach the specified level, particularly during single-client stress testing or when traffic comes from a single source.

  Note

  New purchases of pay-by-specification CLB instances are discontinued from 00:00:00 on January 1, 2026 (UTC+8). For more information, see Discontinuation of new purchases for pay-by-specification Classic Load Balancer (CLB) instances.

• Cause:

  The load balancing system uses a cluster architecture for high availability and scalability. It distributes incoming connection requests evenly across the servers in the cluster. Therefore, the peak CPS of a CLB instance is also distributed across these servers.

  The peak CPS for a single server is calculated as follows: Peak CPS per server = Total instance CPS / (N - 1), where N is the number of servers in the forwarding cluster.

  For example, if you purchase a CLB instance of the slb.s1.small specification rated for 3,000 CPS, the instance can achieve the full 3,000 CPS with requests from multiple clients. However, if the cluster has 4 servers, the maximum CPS for a single server is 3000 / (4 - 1) = 1,000 CPS.

• Solution:

  • Change the instance's billing method from pay-by-specification to pay-by-usage. Pay-by-usage instances are not tied to a specific performance specification and offer higher limits, which helps prevent bottlenecks.

  • Upgrade to a Network Load Balancer (NLB) for scenarios with high concurrency and a high rate of new connections. NLB offers superior performance and elasticity compared to CLB. A single NLB instance supports 100 million concurrent connections, making it ideal for large-scale applications and avoiding the CPS limitations of the CLB cluster architecture.

Supported connection timeout ranges

• TCP listener connection timeout: 10 to 900 seconds.

• HTTP listener:

  • Idle timeout: 1 to 60 seconds.

  • Request timeout: 1 to 180 seconds.

• HTTPS listener:

  • Idle timeout: 1 to 60 seconds.

  • Request timeout: 1 to 180 seconds.

Causes of CLB connection timeouts

The following server-side issues can cause connection timeouts to the CLB service address:

• The service address is blocked by security measures

  This includes traffic scrubbing, blackhole filtering, or WAF protection. WAF, for example, sends RST packets to both the client and the server cluster after establishing a connection.

• Insufficient client ports

  This issue is common during stress tests. A shortage of client ports can cause connection failures. By default, CLB removes the timestamp option from TCP connections, which prevents the Linux kernel's tw_reuse feature (reusing connections in the TIME_WAIT state) from taking effect. This leads to an accumulation of connections in the TIME_WAIT state and a shortage of available client ports.

  Solution: Use persistent connections instead of short-lived connections. Disconnect by sending an RST packet by setting the SO_LINGER socket option, instead of sending a FIN packet.

• The backend server's accept queue is full

  If a backend server's accept queue is full, it does not send a SYN-ACK response, which causes a client timeout.

  Solution: The default value ofnet.core.somaxconn is 128. Evaluate your traffic volume and adjust this value to meet your needs. Then, run sysctl -w net.core.somaxconn=<new_value> to change the parameter and restart the application on the backend server.

• A Layer 4 backend server accesses its own load balancer's service address

  CLB Layer 4 listeners (TCP/UDP) do not allow a backend server to act as both a client and a server. If a backend server attempts to access the service address of the CLB instance it is attached to, the connection will fail. This often happens when a backend application redirects to the CLB service address by constructing a URL.

  Solution:

  • Use a different client to access the service address instead of the Layer 4 backend server.

  • Migrate to a Network Load Balancer (NLB) instance and disable client IP preservation in the server group. After this feature is disabled, an ECS instance in the server group can act as both a backend server and a client of the NLB instance. To obtain the client's source IP address, enable Proxy Protocol. For more information, see How can an ECS instance act as both a backend server and a client of an NLB instance?.

• Improper handling of RST packets on connection timeout

  After a TCP connection is established, if there is no activity for 900 seconds, CLB sends RST packets to both the client and the server to close the connection. Some applications may not handle the RST packet correctly and might attempt to send data over the closed connection, causing an application timeout.

  Note

  The default timeout is 900 seconds but can be adjusted as needed.

HTTP and HTTPS connection timeouts

• An HTTP persistent connection supports a maximum of 100 consecutive requests. After this limit is reached, CLB closes the connection.

• The idle timeout between two HTTP or HTTPS requests on a persistent connection is configurable from 1 to 60 seconds (with a margin of error of 1 to 2 seconds). If this timeout is exceeded, the TCP connection is closed. If your application uses persistent connections, we recommend sending a heartbeat request at least every 13 seconds.

• The TCP three-way handshake between a CLB instance and a backend ECS instance times out after 5 seconds. If the handshake times out, CLB tries the next ECS instance. You can identify this issue by checking the upstream response time in the access log.

• The request timeout (the time a CLB instance waits for a response from an ECS instance) is configurable from 1 to 180 seconds. If this timeout is exceeded, CLB typically returns a 504 or 408 status code to the client. You can identify this issue by checking the upstream response time in the access log.

• The HTTPS session reuse timeout is 300 seconds. After this period, the same client must perform a full SSL handshake again.

CLB behavior on early client disconnection

No. CLB does not close the connection to the backend server during read and write operations.

Enable backend persistent connections for CLB

CLB instances do not support backend persistent connections. To use this feature, create an ALB instance, configure an HTTP or HTTPS listener, and enable backend persistent connections for the corresponding ALB server group. For more information, see Create and manage a server group.

Troubleshoot high CLB latency

Accessing a backend service through a CLB instance introduces a small amount of extra latency compared to accessing the backend server directly. This is normal. CLB Layer 7 listeners use a reverse proxy architecture (Tengine), which adds an extra network hop and protocol processing time. The extra latency for Layer 4 listeners, which use LVS for forwarding, is typically smaller.

If you experience significantly high latency, follow these steps to troubleshoot:

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

   • request_time: The interval, in seconds, from when CLB receives the first request packet to when it returns the response.

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

2. Identify the source of the latency:

   • If upstream_response_time is high: The latency is likely caused by slow processing on the backend server. Check the backend application's performance, database query efficiency, and resource usage (CPU/memory), or add more backend servers to distribute the load.

   • If request_time is much greater than upstream_response_time, the latency may be in the network link from the client to the CLB. You can run a continuous ping test or perform MTR route tracing from the client to the CLB service address to troubleshoot network link issues.

3. Cross-region access: If the client and the CLB instance are in different regions, network latency due to physical distance is unavoidable. We recommend using Global Accelerator (GA) to optimize the cross-region access experience.

Troubleshoot 502, 503, or 504 errors

When you access a backend service through a CLB instance, 502, 503, or 504 error codes usually indicate that the request was not processed correctly by the backend server. The error codes mean the following:

• 502 Bad Gateway: CLB could not forward the request to a backend server or receive a response from it. Common causes include unreachable backend services or all health checks failing.

• 503 Service Temporarily Unavailable: This is usually caused by traffic exceeding limits or an unavailable backend server. This error is returned when instantaneous traffic exceeds the limits of the CLB instance's specification.

• 504 Gateway Timeout: The backend server timed out. Common causes include long processing times on the backend or a timeout while establishing a connection to the backend server.

First step: Check access logs

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

• If status and upstream_status are the same, CLB likely passed the error code directly from the backend server. Investigate why the backend server is returning this error.

• If upstream_status is "-" or different from status, the error was returned by CLB. Refer to the following points to troubleshoot.

Troubleshooting 502 errors

• All backend server health checks fail: When all backend servers associated with a listener fail their health checks, CLB cannot forward requests and instead returns a 502 error. Check the health check status in the console and troubleshoot the cause of the failure, such as iptables or third-party security software blocking the CLB system CIDR block 100.64.0.0/10, a mismatched health check status code, or a non-existent health check path. For more information, see CLB Health Check FAQ.

• Backend returns an error code that CLB converts to 502: If a backend server returns certain error codes (such as 504 or 444), CLB may return a 502 error to the client. Check the upstream_status field in the access log to confirm the actual status code returned by the backend and investigate the cause of the backend error.

• Backend service errors: High load, malformed responses, or unexpected connection closures on the backend server can also cause 502 errors. Check the backend server's logs and resource usage, such as CPU and memory.

Troubleshooting 503 errors

• Traffic exceeds instance specification limits: CLB returns a 503 error if the QPS, bandwidth, or new connection rate of incoming traffic exceeds the limits of the current CLB instance specification. You can retrieve these metrics from CloudMonitor.

• Instantaneous traffic exceeds limits but is not shown in monitoring: CloudMonitor displays data at a minute-level granularity and may not show second-level spikes. Check the second-level request count in the access log. If the upstream_status is "-", it indicates that the request was not sent to the backend server.

Troubleshooting 504 errors

• Backend response timeout: If the backend server does not respond within the request timeout period configured for the listener, CLB returns a 504 error. Check the upstream_response_time field in the access log to confirm the actual response time of the backend and adjust the listener's request timeout accordingly.

• Backend connection timeout: The timeout for a CLB instance to complete a TCP three-way handshake with a backend ECS instance is 5 seconds. If the upstream_response_time in the access log is too long, it may indicate a connection issue with the backend server. We recommend capturing packets to investigate the cause.

• High backend load: High resource usage (CPU, memory, etc.) on the backend server can cause response times to exceed the timeout period. Investigate and optimize the backend service performance, or add more backend servers to distribute the load.

Troubleshoot CLB access issues

If you cannot access your service after configuring a CLB instance, follow these steps to troubleshoot layer by layer:

1. Verify domain name resolution: If you access the service by using a domain name, make sure that the domain name correctly resolves to the service address of the CLB instance. You can use the nslookup or dig commands to verify the resolution. Incorrect domain name resolution is a common reason for access failures.

2. Verify the listener configuration: In the CLB console, check whether a listener has been created and confirm that the listener port and protocol are correctly configured. If a listener is missing or misconfigured, CLB cannot forward requests.

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

4. Check firewall settings: Check whether iptables or third-party security software on the backend server allows the backend service port and the CLB system CIDR block 100.64.0.0/10.

5. Verify that the backend service is running properly: Log on to the backend server directly and confirm that the backend service itself is responsive by running telnet <private IP address of the backend server> <port> (Layer 4) or curl -I http://<private IP address of the backend server> (Layer 7).

6. Troubleshoot the network link: Test access to the CLB service address from different network environments. If only your local network is affected, you can run a continuous ping test or use MTR route tracing for further investigation.

Access by IP but not by domain name

The most common reason is that the domain name has not completed its ICP filing.

According to regulations, when a domain name is used for public access in the Chinese mainland, it must have a valid ICP filing. Access to domains without an ICP filing is blocked, resulting in a 403 status code or a connection reset.

We recommend that you follow these steps to troubleshoot and resolve the issue:

1. Verify the ICP filing status: Log on to the Alibaba Cloud ICP Filing System to check if your domain name has completed its ICP filing. If not, complete the process first. For more information, see ICP filing process.

2. Check if you need to transfer your ICP filing: If your domain name has an ICP filing with another cloud service provider but you are using it with Alibaba Cloud for the first time, you must also complete a transfer ICP filing to associate the filing information with Alibaba Cloud. Failure to complete this transfer can also result in blocked access.

3. Rule out other causes: If the domain name has an ICP filing and the transfer ICP filing is also complete, check whether the domain name resolution correctly points to the service address of the CLB (you can use the nslookup or dig command to verify), and whether the CLB listener port and protocol configuration match the domain name access method.

Impact of access control on internal traffic

Yes. Access control is applied at the listener level and affects both internal and public traffic. If you configure an allowlist that only permits specific public IP addresses, requests from internal IP addresses not on the allowlist will be blocked. To avoid disrupting internal services, we recommend adding the relevant internal CIDR blocks to the allowlist or using Cloud Firewall to restrict public access to the EIP.

Troubleshoot request timeouts during stress tests

When you stress test a Layer 7 CLB, if you receive 504 status codes or request timeouts, and the upstream_response_time in the logs is clustered around 5 seconds, the issue is usually a connection timeout caused by a failed TCP three-way handshake between the CLB and the backend server. A common reason for this is that the connection tracking table (nf_conntrack) on the backend server is full, which causes the server to drop packets for new connections.

Log on to the backend server and check the /var/log/messages log. You can confirm the issue if the following error message appears:

nf_conntrack: table full, dropping packet

Solution: Adjust the values of the following nf_conntrack parameters based on your actual service requirements:

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_buckets=262144
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600

Note: The preceding command takes effect only temporarily. The changes are lost after the instance is restarted. To make the changes permanent, write the parameters to /etc/sysctl.conf.

Impact of backend failures on shared listeners

Scenario: You have multiple websites, such as a static website www.example.com and a dynamic website app.example.com, attached to the same CLB listener. When the backend database for the dynamic website fails, the static website also becomes inaccessible and returns an HTTP 502 error.

Cause: Both sites share the same listener, and the listener's Health Check Domain Name is configured with the domain name of the dynamic site. When the dynamic site's backend fails, all backend servers fail their health checks. As a result, CLB stops forwarding traffic to the backend, which affects all sites configured under that listener.

Solution: Use separate CLB instances to provide load balancing for the dynamic and static sites to achieve business isolation. This way, a failure in the dynamic site will not affect the static site.

Reasons for session persistence failure

• Session persistence is not enabled: Check if session persistence is enabled in the listener configuration.

• HTTP/HTTPS listener issues: For an HTTP or HTTPS listener, CLB cannot insert the cookie required for session persistence into a 4xx response.

  Solution: Switch to a TCP listener, which uses the client's source IP address to maintain session persistence. For added reliability, you can also insert a cookie on the backend ECS instance and add a cookie validation check.

• 302 redirect issues: A 302 redirect can change the SERVERID string used for session persistence.

  If a backend ECS instance issues a 302 redirect, it can alter the SERVERID string in the CLB-injected cookie, breaking session persistence.

  How to troubleshoot: Use your browser's developer tools or a packet sniffer to capture requests and responses. Analyze the packets to check for 302 redirect responses and compare the SERVERID strings in the cookies before and after the redirect.

  Solution: Switch to a TCP listener, which uses the client's source IP address to maintain session persistence. For added reliability, you can also insert a cookie on the backend ECS instance and add a cookie validation check.

• The session persistence timeout is too short: If the timeout value is set too low, session persistence may fail.

Viewing the session persistence string

You can use your browser's developer tools (F12) to check if the response headers contain the SERVERID string or a custom keyword. Alternatively, run the curl www.example.com -c /tmp/cookie123 command to save the cookie, and then run curl www.example.com -b /tmp/cookie123 to send the cookie in the next request.

Testing session persistence with curl

1. Create a test page.

   On each backend ECS instance, create a test page that displays the instance's private IP address. This address identifies which server is handling a request. If the IP address is consistent across multiple requests, session persistence is working.

   

2. Run the curl command on a Linux system.

   Assume 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 server that you will use for testing.

   2. Run the following command to retrieve the cookie from the load balancer.

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

      Note

      By default, CLB uses cookie injection for session persistence. However, curl does not save or send cookies by default. You must save the cookie before testing. Otherwise, subsequent curl requests will be sent without a cookie, leading to random routing, which may cause you to incorrectly conclude that session persistence is not working.

   3. Run 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

      In a≤30, 30 is the number of repeated tests and can be modified as needed. The grep '10.170.XX.XX' command filters the displayed IP information. Change 10.170.XX.XX to the private IP address of the backend ECS instance.

   4. Observe the IP addresses returned by the test. If all responses come from the same backend server's private IP address, session persistence is working correctly. Otherwise, session persistence is not working correctly.

Configure backend cookies for Rewrite Cookie mode

If you select the Rewrite Cookie mode for Layer 7 session persistence, you must configure a cookie with the same name on your backend servers. The cookie name must be identical to the one configured in the CLB console. The following examples show how to configure this on common web servers:

server {
    listen 8080;
    server_name wqwq.example.com;
    location / {
        add_header Set-Cookie name=xxxx;
        root   html;
        index  index.html index.htm;
    }
}

Troubleshoot uneven server load

If you have multiple backend servers attached to a CLB instance and one server has a significantly higher load than the others, follow these steps to troubleshoot:

1. Check if session persistence is enabled: CLB HTTP/HTTPS listeners support session persistence through cookie injection. When session persistence is enabled, all requests from the same client are routed to the same backend server. If a few clients generate a large number of requests, this concentrates traffic on specific backend servers, leading to an uneven load.

2. Disable session persistence for even distribution: If your application does not depend on session state (such as cookies or sign-in state), disable session persistence for the listener. Once disabled, CLB distributes requests evenly to all backend servers based on the configured scheduling algorithm, such as weighted round-robin. Perform this action during off-peak hours and immediately verify that your application remains available. Disabling session persistence will affect stateful services, such as shopping carts or persistent sign-ins. Assess your application's dependency on session persistence before you proceed.

3. Check the application load on backend servers: Even if CLB distributes traffic evenly, differences in CPU, memory, or other resource usage on the backend servers themselves can cause some servers to experience a higher load. Log on to each backend server, compare the resource usage of your applications, and check for performance bottlenecks.

Styles fail to load over HTTPS

Symptom:

You have an HTTP and an HTTPS listener, both using the same backend servers. When you access the website through the HTTP listener, it displays correctly. However, when you access the website through the HTTPS listener, its layout appears broken.

Cause:

A load balancer does not block JavaScript (JS) files by default. This issue can be caused by the following:

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

• The certificate is from an untrusted third-party provider. Contact the issuer to resolve this.

Solution:

1. When you open the website, follow the browser prompts to load the scripts.

2. Add the corresponding certificate to the client's trust store.

Backend server certificates for HTTP-to-HTTPS redirection

No. You only need to configure a certificate on the HTTPS listener of the CLB instance. For more information, see Configure an SSL certificate.

Browser shows old certificate expiration after update

This typically occurs if the CLB instance is transparently integrated with WAF 2.0, and WAF's certificate has not been updated. WAF synchronizes certificates from CLB periodically. To trigger an immediate synchronization, you can disable and then re-enable traffic redirection in the WAF console to force a certificate refresh. This action may cause a brief service interruption, lasting 1 to 2 seconds.

HTTP protocol version for backend server access

• If a client request uses HTTP/1.1 or HTTP/2.0, the Layer-7 listener communicates with the backend server using HTTP/1.1.

• If a client request uses a protocol version other than HTTP/1.1 or HTTP/2.0, the Layer-7 listener communicates with the backend server using HTTP/1.0.

Retrieving the client protocol version

Yes.

URL-based throttling

CLB does not support URL-based throttling, only bandwidth throttling at the listener level.

ALB supports URL-based throttling. You can configure a listener forwarding rule to apply QPS throttling to a specific path. This feature must be used in conjunction with the "Forward to" action. See the following figure:

The Transfer-Encoding: chunked field

Transfer-Encoding: chunked is a standard HTTP protocol field indicating that the message body is sent using chunked transfer. Layer-7 CLB is a reverse proxy built on Tengine. When it forwards requests to a backend server, it uses chunked transfer. Therefore, the backend server receives this field in the request header. This is normal behavior for a reverse proxy and does not affect your services. A Layer-4 CLB only forwards traffic and does not add this field.

Removed response header fields

To implement session persistence, CLB removes fields such as Date, Server, X-Pad, and X-Accel-Redirect from the response header. To retain these fields, you can add a prefix to your custom response headers, such as xl-server, or switch to a Layer-4 TCP listener.

proxy_buffering and proxy_cache

The proxy_buffering and proxy_cache features are not enabled for CLB. CLB does not buffer or cache request or response data. Instead, it forwards client requests directly to backend servers in a transparent forwarding mode. This is the default behavior of CLB and requires no additional configuration.

Enable WAF protection for CLB

Impact of disabling the public ENI

If an ECS instance has a public IP, disabling its public elastic network interface affects the load balancer service.

This is because if a public elastic network interface exists, the default route directs traffic through the public network. Disabling the interface prevents response packets from being sent back, which disrupts the load balancer service. We recommend not disabling the public elastic network interface. If you must disable it, change the default route to the private network to avoid service disruption. However, consider whether your services rely on public network access, for example, to access RDS.

Support for client requests with a TOA field

No. A client-provided TCP Option Address (TOA) field conflicts with the TOA field that the load balancer uses for internal communication. This conflict prevents the backend server from obtaining the real IP address of the client.