CLB server groups

Server group types

Weight configuration

The scheduling algorithm determines how CLB distributes incoming requests across multiple backend servers. Weight is a parameter used in weighted algorithms to control the proportion of traffic assigned to each server.

• Scope: Applies only when using a weighted scheduling algorithm. It has no effect with the round-robin algorithm.

• Range: 0–100, with a default value of 100.

• Behavior when weight is 0: The server stops receiving new request traffic. Existing connections continue until they close normally, and health checks still run. This is commonly used for graceful shutdown.

• Effect of weight changes: Weight adjustments apply only to new connections and do not affect existing connections. In persistent connection scenarios, traffic redistribution after a weight change occurs slowly.

Service high availability

Enable CLB health checks to periodically send requests and verify server status.

• Successful health check: The server is healthy, and CLB forwards traffic to it.

• Failed health check: The server is unhealthy, and CLB stops sending new request traffic to it until it recovers.

CLB health checks originate from the 100.64.0.0/10 CIDR block. Ensure your backend servers’ iptables or other third-party security software do not block this CIDR block. Otherwise, health checks will fail and cause service disruption.

Primary/secondary server groups rely on health checks for automatic failover:

• If the primary server fails its health check, traffic switches to the secondary server. By default, the secondary server does not undergo health checks, so you must ensure its availability manually to guarantee seamless failover.

• The failover time depends on the configured health check response timeout period. When the primary server recovers, traffic automatically switches back to it.

Can I adjust the number of ECS instances while the CLB instance is running?

• Default server group and vServer group: You can add or remove backend ECS instances at any time and switch between different ECS instances. To ensure service stability, enable health checks before performing these operations and ensure at least one healthy ECS instance remains in the backend.

• Primary/secondary server group: Not supported.

Can backend ECS instances use different operating systems?

They may differ.

CLB does not restrict the operating systems of backend ECS instances, as long as the application services and data are consistent. We recommend using the same operating system for easier management and maintenance.

Can I use ECS instances from different regions as backend servers?

CLB does not support directly attaching cross-region backend servers. To implement cross-region deployment, use one of the following solutions:

• Deploy Global Traffic Manager above CLB and deploy multiple CLB instances across regions. Switch between CLB instances to achieve cross-region attachment.

• Use Application Load Balancer (ALB) or Network Load Balancer (NLB), which support cross-region backend attachment.

Why are there frequent requests from IPs starting with 100 to my ECS instance?

These requests come from the load balancer’s health checks and availability monitoring.

• Source: Alibaba Cloud reserved CIDR block 100.64.0.0/10.

• Security: This CIDR block is reserved by Alibaba Cloud and cannot be allocated to other users, so it poses no security risk.

• Recommendation: Ensure your backend servers’ iptables or other third-party security software do not block this CIDR block to maintain service availability.

If health checks fail, see How do I troubleshoot health check failures?

My ECS instance does not have compression enabled, but HTTP responses from CLB are compressed. Why?

• Reason: Gzip compression is enabled in the CLB listener configuration, and the client browser supports compression.

• Action: To disable it, turn off Gzip compression in the CLB console listener settings or switch to a TCP listener.

Does an ECS instance using HTTP/1.0 support chunked transfer encoding?

Yes.

Why does my CLB backend ECS instance frequently receive requests with User-Agent KeepAliveClient?

• Observation: The backend ECS receives many GET requests from internal IP addresses with User-Agent KeepAliveClient.

• Reason: The listener protocol is TCP, but the health check protocol is set to HTTP. When a TCP listener uses HTTP health checks, it defaults to the GET method.

• Solution: Align the listener protocol and health check protocol (for example, use both TCP or both HTTP).

Can I modify the server port in the default server group?

Direct modification is not supported.

• Restriction: The port for the default server group can only be set when creating the listener, and all backend servers under the same listener must use the same port.

• Solution: To configure different backend ports for the same listener, use a vServer group.

Does CLB Layer 4 listener support using the same ECS instance as both a backend server and a client?

No. This configuration causes a loop.

Alternatives:

• Use a CLB Layer 7 listener (HTTP/HTTPS).

• Use an NLB instance and disable client IP preservation for the server group. See How can an ECS instance serve as both a backend server and a client in NLB?

Why does my CLB backend have many TIME-WAIT connections, while ALB has few?

Classic Load Balancer (CLB) and Application Load Balancer (ALB) use different connection mechanisms when interacting with backend servers.

• Classic Load Balancer (CLB): Uses HTTP short-lived connections by default. CLB inserts the Connection: close header into HTTP requests. After processing the request, the backend server sends a FIN packet to close the connection based on this header. Each closure enters the TIME-WAIT state (default 60 seconds), leading to rapid accumulation under high concurrency.

• Application Load Balancer (ALB): Supports HTTP persistent connections (keep-alive) by default. A single TCP connection handles multiple requests, reducing connection closures and thus TIME-WAIT connections.

To reduce TIME-WAIT accumulation, consider these options:

• Switch to a CLB Layer 4 (TCP) listener. Layer 4 health checks send an RST packet after a successful handshake to close the connection without entering TIME-WAIT.

• Migrate to ALB to leverage its default HTTP persistent connection reuse mechanism.

Why is traffic unevenly distributed among backend servers?

How do I safely remove a backend ECS instance from CLB?

Removing an ECS instance directly may cause transient disconnections. First, set the ECS instance weight to 0. Wait for existing connections to complete before removing the instance. For details on weight behavior when set to 0, see the Weight configuration section above.

If business requests continue after removing the ECS instance, check the following:

• Whether the ECS instance is also attached to other CLB instances.

• Whether the ECS instance provides other services directly. Use the netstat command to check port listening status.

Why is no traffic forwarded to a newly added backend server?

If CLB does not forward traffic to a newly added backend server, check the following:

• Health check failed: The backend server port is unreachable or the application is not listening on the expected port, causing health check failure. In the CLB console, confirm the server’s health check status and verify port listening and application status on the backend server. If health checks fail, see How do I troubleshoot health check failures?

• Weight set to 0: Servers with weight 0 do not receive new request traffic. Check the server’s weight in the server group and ensure it is greater than 0. For details, see the Weight configuration section above.

• Added to the wrong server group: Each CLB listener binds to a specific server group (default or vServer group). If the new server is added to a group not bound to the target listener, it will not receive traffic for that listener. Confirm the server group actually bound to the listener and add the server to the correct group.

• iptables or third-party security software blocks the health check CIDR block: CLB health checks use the 100.64.0.0/10 CIDR block. If iptables or other third-party security software on the backend server blocks this CIDR block, health checks fail and CLB treats the server as unhealthy. Ensure relevant rules do not block this CIDR block.

• Health check window not reached: After adding a backend server, CLB waits for a successful health check before forwarding traffic. Wait briefly and then verify if traffic flows normally.