A Classic Load Balancer (CLB) UDP listener distributes UDP traffic to backend servers. UDP listeners suit scenarios that require high time efficiency but tolerate lower reliability, such as video conferencing and real-time financial data streaming.
Prerequisites
A CLB instance. For more information, see Create and manage a CLB instance.
Limitations
Ports 250 and 4789 are reserved by the system and cannot be used for UDP listeners.
IP fragmentation is not supported.
UDP listeners on a CLB instance deployed in the classic network cannot pass client IP addresses to backend servers, regardless of whether the instance is Internet-facing or internal-facing.
For IPv6 CLB instances that use a UDP listener, the maximum transmission unit (MTU) of the network interface controller (NIC) on each backend server must be 1,200 bytes or greater. Otherwise, oversized packets may be discarded. Modify the MTU settings in backend application configuration files if possible.
TCP supports Maximum Segment Size (MSS) announcement. TCP, HTTP, and HTTPS listeners do not require additional MTU configurations.
Step 1: Configure listener protocol and settings
Log on to the CLB console.
In the top navigation bar, select the region where the CLB instance is deployed.
On the Instances page, find the CLB instance and start the listener configuration by using one of the following methods:
Click Configure Listener in the Actions column.
Click the instance ID, click the Listener tab, and then click Add Listener.
In the Protocol & Listener wizard step, configure the following parameters and click Next.
Basic settings
| Parameter | Description |
|---|---|
| Listener Protocol | Select UDP. |
| Backend Protocol | Automatically set to UDP. This value cannot be changed. |
| Listener Port | Specify the port that receives and forwards requests to backend servers. Valid values: 1 to 65535. |
| Tag | Select or enter a tag key and a tag value. |
Advanced settings
Click Modify under Advanced Settings to configure the following parameters.
Scheduling algorithm
Select a scheduling algorithm to control how requests are distributed to backend servers. Round Robin (RR) is the default.
| Algorithm | Distribution method | Best for |
|---|---|---|
| Weighted Round-robin (WRR) | Distributes requests based on backend server weights. Servers with higher weights receive more requests. | Backends with different processing capacities |
| Round Robin (RR) | Distributes requests sequentially and evenly across all backend servers. | Backends with identical processing capacities |
| Consistent hashing (CH) | Distributes requests based on a hash key. Requests with the same key always go to the same backend server. Three hash modes are available. | Stateful applications that require session affinity |
Consistent hashing (CH) modes:
| Mode | Hash key | Description |
|---|---|---|
| QUIC ID | Quick UDP Internet Connections (QUIC) ID | Requests with the same QUIC ID are sent to the same backend server. |
| Four-element | Source IP address, destination IP address, source port, and destination port | Requests that match on all four factors are sent to the same backend server. |
| Source IP | Source IP address | Requests from the same source IP address are sent to the same backend server. |
QUIC is implemented based on draft-ietf-quic-transport-10 and iterates rapidly. Compatibility is not guaranteed for all QUIC versions. Test this mode before applying it to a production environment.
If a TCP listener uses Weighted Round-robin (WRR) or Round Robin (RR), the scheduling algorithm cannot be changed to Consistent hashing (CH). Create a new listener to use consistent hashing for a TCP listener.
Session persistence
Session persistence is disabled by default. When enabled, the CLB instance forwards all requests from the same client to the same backend server.
Access control
Access control is disabled by default. After enabling access control, select a method and an access control list (ACL).
| Method | Behavior |
|---|---|
| Whitelist | Only requests from IP addresses or CIDR blocks in the ACL are forwarded. If a whitelist is configured but contains no IP addresses, the listener forwards all requests. Your service may be adversely affected if the whitelist is not properly configured. |
| Blacklist | Requests from IP addresses or CIDR blocks in the ACL are denied. If a blacklist is configured but contains no IP addresses, the listener forwards all requests. |
IPv6 CLB instances can be associated only with IPv6 ACLs. IPv4 CLB instances can be associated only with IPv4 ACLs. For more information, see Create an ACL.
Bandwidth throttling for listeners
For pay-by-bandwidth CLB instances, set a maximum bandwidth for each listener to limit the network traffic forwarded by that listener. This feature is disabled by default, and all listeners share the bandwidth of the CLB instance. For more information, see Enable bandwidth sharing among listeners of a CLB instance.
The sum of the maximum bandwidth allocated to all listeners cannot exceed the maximum bandwidth of the CLB instance.
For example, if an Internet-facing CLB instance has a maximum bandwidth of 5 Mbit/s and you allocate 5 Mbit/s to Listener A without allocating bandwidth to Listener B, Listener B becomes inaccessible.
For an internal-facing CLB instance with three listeners, if the total bandwidth allocated to Listener A and Listener B is 5,120 Mbit/s, Listener C becomes inaccessible. Exercise caution when you allocate bandwidth.
Pay-by-data-transfer CLB instances have unlimited listener bandwidth by default.
Proxy Protocol
Specify whether to use the Proxy Protocol to pass client IP addresses to backend servers. For more information, see Enable Layer 4 listeners to preserve client IP addresses and pass them to backend servers.
This feature is not available when PrivateLink is used.
Both the proxy server and backend servers must support the Proxy Protocol. Do not enable this feature if backend servers do not support it, because backend services may fail to parse packets as expected, which affects the availability of backend services.
Obtain client source IP address
Specify whether to preserve client IP addresses. This feature is supported only by Layer 4 listeners and is enabled by default.
For UDP listeners on a CLB instance deployed in the classic network, enable Proxy Protocol to obtain client IP addresses.
Automatically enable listener
Specify whether to enable the listener immediately after it is created. By default, listeners are enabled after creation.
Step 2: Add backend servers
After configuring the listener, add backend servers to process client requests. Use the default server group, a vServer group, or a primary/secondary server group. For more information, see CLB server groups.
The following steps use the default server group as an example.
In the Backend Servers step, select Default Server Group and click Add More.
In the Servers panel, select the backend servers to add and click Next.
In the Ports/Weights step, configure the weight for each backend server and click Add.
NoteThe default weight is 100. A server with a higher weight receives more requests.
Setting the weight to 0 stops all requests from being distributed to that server.
Specify the port on each backend Elastic Compute Service (ECS) instance that receives requests. Valid values: 1 to 65535. Different backend servers added to the same CLB instance can use the same port.
Click Next.
Step 3: Configure health checks
CLB performs health checks to verify the availability of backend servers. Health checks improve overall service availability and reduce the impact of backend server failures.
Health checks cannot be disabled for a listener associated with a primary/secondary server group.
In the Health Check step, click Modify to change the health check configuration. For detailed instructions, see Configure and manage CLB health checks. Click Next.
In the Confirm step, review the listener configuration. Click Modify to make changes if needed.
Click Submit. In the Configuration Successful message, click OK.
After you complete the configuration, the listener appears on the Listener tab.