A listener routes business requests to a specified server group based on configured forwarding rules. The server group then distributes traffic to backend servers using a scheduling algorithm.
How it works
Server group types
Server group type | Default server group | vServer group | Primary/secondary server group |
Description | Each CLB instance includes a default server group. (exactly one) | Created and managed by the user | You create and manage this server group. |
Number of backend servers | One or more | One or more | Two (one primary and one secondary) |
Characteristics |
|
|
|
Use cases | Simple architectures where all requests are forwarded to the same group of backend servers. | Complex architectures, such as distributing requests by domain name or port. | Services that require a fixed active-passive mode, such as databases or core APIs. |
Supported listener types | TCP/UDP/HTTP/HTTPS | TCP/UDP/HTTP/HTTPS | TCP/UDP only |
Weight configuration
The scheduling algorithm determines how CLB distributes incoming requests across multiple backend servers. Weights control the proportion of traffic assigned to each server when you use a weighted algorithm.
Scope: Applies only when you use a weighted scheduling algorithm. Has no effect with round-robin scheduling.
Valid values: 0 to 100. Default is 100.
Weight set to 0: The server stops receiving new requests. Existing connections continue until they close normally. Health checks continue. This is commonly used for graceful shutdown.
Effect of weight changes: Changes apply only to new connections. Existing connections are unaffected. In persistent connection scenarios, traffic shifts gradually after you adjust weights.
Service high availability
Enable CLB health checks to regularly send requests and verify server status.
Health check succeeds: The server is healthy. CLB forwards traffic to it.
Health check fails: The server is unhealthy. CLB stops sending new requests to it until it recovers.
CLB health checks use the 100.64.0.0/10 CIDR block. Ensure your backend servers' security group rules allow traffic from this CIDR block. Otherwise, health checks fail and cause service interruptions.Primary/secondary server groups rely on health checks for automatic failover:
If the primary server fails a health check, traffic switches to the secondary server. By default, health checks are not performed on the secondary server. You must ensure the secondary server is available before failover.
Failover time depends on the Health Check Response Timeout setting. After the primary server recovers, traffic automatically switches back to it.
Scope of use
Associations:
Listeners and server groups are resources scoped to a CLB instance. Listeners and server groups are not shared across different CLB instances.
A server group can be associated with multiple listeners, but a listener can be associated with only one server group.
CLB Layer 4 listeners do not support an ECS instance acting as both a backend server and a client. If needed, use a Layer 7 listener instead.
Backend server associations:
CLB supports associating only backend servers in the same Alibaba Cloud account and region.
Private network CLB instances: You can associate only backend servers in the same VPC as the CLB instance.
Internet-facing CLB instances: All associated backend servers must belong to the same VPC.
All CLB server group types support associating the following resources: Elastic Compute Service (ECS) instances, Elastic Network Interfaces (ENIs), and Elastic Container Instances (ECIs).
You can add only ENIs already associated with ECS instances. Both the primary private IP address and secondary private IP addresses of an ENI can be added.
If an ECS instance undergoes hot migration while acting as a backend server, persistent connections to CLB may break. To restore them, ensure your application implements automatic reconnection.
Configuration modifiability:
Configuration modifiability
Add or remove server groups
Modify port
Modify weight
Default server group
After you first create a listener and associate it, the port is not modifiable.
vServer group
Primary/secondary server group
Primary/secondary roles are not modifiable.
Configure server groups
Console
Default server group
No creation required. Each CLB instance includes exactly one default server group.
Add servers:
Go to the CLB - Instance Management page. Click the target instance ID. Select the Default Server Group tab. Click Add.
Set Server Type and Resource Group to filter available resources.
To add an ENI, first enable Advanced Mode. Then click the plus sign icon next to the ECS instance that has the ENI attached. Select the target ENI. Check the ENI you want to associate and choose an IP.
Configure port and weight:
Configure port: Go to the Listener tab. Click Add Listener. In the Backend Servers step, set the Port for the default server group. All servers in the default server group for the same listener must use the same port.
You can specify the port only when adding a listener. You cannot modify it later.
Configure weight: Set the Weight for selected servers.
vServer group
Go to the CLB - Instance Management page. Click the target instance ID. Select vServer groups. Click Create vServer Group.
Add servers:
Set Server Type and Resource Group to filter available resources.
To add an ENI, first enable Advanced Mode. Then click the plus sign icon next to the ECS instance that has the ENI attached. Select the target ENI. Check the ENI you want to associate and choose an IP.
Configure the Port and Weight for selected servers. Click Add Port to assign multiple ports to the same backend server.
Primary/secondary server group
Go to the CLB - Instance Management page. Click the target instance ID. Select Primary/Secondary Server Groups. Click Create Primary/Secondary Server Group.
Add servers:
Set Server Type and Resource Group to filter available resources.
To add an ENI, first enable Advanced Mode. Then click the plus sign icon next to the ECS instance that has the ENI attached. Select the target ENI. Check the ENI you want to associate and choose an IP.
You can add exactly two backend servers.
Configure the Port for selected servers. Click Add Port to assign multiple ports to the same backend server. Then select Primary Server to define the primary/secondary relationship.
API
Default server group
Call AddBackendServers to add backend servers.
Call SetBackendServers to set backend server weights.
Call RemoveBackendServers to remove backend servers.
vServer group
Call CreateVServerGroup to create a vServer group and add backend servers, and configure ports and weights.
Call AddVServerGroupBackendServers or RemoveVServerGroupBackendServers to add or remove backend servers from a specified vServer group.
Call DeleteVServerGroup to delete a vServer group.
Primary/secondary server group
Call CreateMasterSlaveServerGroup to create a primary/secondary server group.
Call DeleteMasterSlaveServerGroup to delete a primary/secondary server group.
FAQ
Can I adjust the number of ECS instances while a CLB instance is running?
Default server group and vServer group: You can increase or decrease the number of backend ECS instances at any time. You can also switch between different ECS instances. To ensure service stability, enable health checks before performing these operations and ensure that at least one backend ECS instance remains healthy.
Primary/secondary server group: Not supported.
Can backend ECS instances run different operating systems?
They can differ.
CLB does not restrict the operating systems used by backend ECS instances, as long as application services and data are consistent across instances. However, we recommend using the same operating system to simplify management and maintenance.
Can I use ECS instances from different regions as backend servers?
CLB does not natively support associating cross-region backend servers. To achieve cross-region deployment, use one of the following options:
Deploy Global Traffic Manager (GTM) in front of multiple CLB instances across regions. GTM routes traffic to different CLB instances to achieve cross-region load balancing. For more information, see Global Traffic Manager.
Use Application Load Balancer (ALB) or Network Load Balancer (NLB), both of which support associating cross-region backend servers. For more information, see Application Load Balancer or Network Load Balancer.
Why do IP addresses that start with 100 frequently access my ECS instances?
These requests originate from CLB health checks and availability monitoring.
Source: The reserved Alibaba Cloud CIDR block
100.64.0.0/10.Security: This CIDR block is reserved exclusively for Alibaba Cloud internal use. Other users cannot allocate IP addresses in this range, so there is no security risk.
Recommendation: Allow traffic from this CIDR block in your security group rules to ensure service availability.
Compression is not configured on my ECS instances. Why are HTTP responses from CLB compressed?
Cause: Gzip compression is enabled in the CLB listener configuration, and the client browser supports compression.
Action: Disable Gzip compression in the CLB console listener configuration, or use a TCP listener instead.
Do ECS instances that use HTTP 1.0 support chunked transfer encoding?
Supported.
Why do backend ECS instances of a CLB instance frequently receive requests with the User-Agent 'KeepAliveClient'?
Symptom: Backend ECS instances receive many GET requests from internal Alibaba Cloud IP addresses, with the User-Agent
KeepAliveClient.Cause: The listener protocol is TCP, but the health check protocol is HTTP. When HTTP health checks are used with TCP listeners, GET requests are sent by default.
Solution: Use the same protocol for both the listener and health checks, such as TCP or HTTP.
Can I modify the server ports in a default server group?
You cannot modify this directly.
Limitation: You can set the port only when creating a listener. All backend servers in the default server group for the same listener must use the same port.
Solution: To configure different backend ports for the same listener, use a vServer group.
Do Layer 4 listeners of CLB support an ECS instance that acts as both a backend server and a client?
No. This configuration creates a loopback scenario.
Alternative solutions:
Use a CLB Layer 7 listener (HTTP or HTTPS).
Use an NLB instance and disable the Preserve Client IP feature for the server group. For more information, see How do I configure my NLB instance to allow an ECS instance in the server group to work as both a backend server and a client?.
Why are there many TIME-WAIT connections on CLB backends but few on ALB backends?
CLB and ALB use different connection mechanisms when interacting with backend servers.
CLB: Uses short-lived HTTP connections by default. When CLB forwards a request to a backend server, it inserts the
Connection: closefield into the HTTP header. After the backend server processes the request, it actively sends a FIN packet to close the connection based on this header. Each time a connection is closed, it enters the TIME-WAIT state (60 seconds by default). In high-concurrency scenarios, many TIME-WAIT connections can accumulate quickly.ALB: Supports persistent HTTP connections (keep-alive) by default. A single TCP connection can be reused to process multiple requests. Enabling persistent connections reduces the number of disconnections, thus reducing the number of TIME-WAIT connections.