All Products
Search
Document Center

Server Load Balancer:Add a UDP listener

Last Updated:Apr 01, 2025

If you want your Classic Load Balancer (CLB) instance to forward UDP requests in scenarios that have high requirements for time efficiency but can tolerate relatively lower reliability, such as video conferencing and real-time push of financial information, you can create UDP listeners for your CLB instance.

Limitations

Before you add a UDP listener, take note of the following items:

  • You cannot specify port 250, port 4789, or port 4790 for UDP listeners. They are reserved by the system.

  • Fragmentation is not supported.

  • If you add a UDP listener to a CLB instance deployed in the classic network, whether the instance is Internet- or internal-facing, the UDP listener cannot pass client IP addresses to backend servers.

  • IPv6 packets have longer IP headers than IPv4 packets. If an IPv6 CLB instance uses a UDP listener, the maximum transmission unit (MTU) supported by the network interface controller (NIC) that a backend server uses to communicate with CLB must be equal to or greater than 1,200 bytes. Otherwise, oversized packets may be discarded. You must also modify the MTU settings in the configuration files of applications deployed on backend servers, if possible.

    TCP supports Maximum Segment Size (MSS) announcement. Therefore, when you use a TCP, HTTP, or HTTPS listener, you do not need to perform additional configurations.

Prerequisites

A CLB instance is created. For more information, see Create and manage a CLB instance.

Procedure

Step 1: Add a UDP listener

  1. Log on to the CLB console.

  2. In the top navigation bar, select the region where the CLB instance is deployed.

  3. On the Instances page, find the CLB instance that you want to manage and choose one of the following ways to configure a listener:

    • Click Configure Listener in the Actions column.

    • Click the ID of the instance, click the Listener tab, and click Add Listener.

  4. In the Protocol & Listener wizard step, configure the following parameters and click Next.

    Parameter

    Description

    Listener Protocol

    In this example, UDP is selected.

    Backend Protocol

    In this example, UDP is selected, and the Backend Protocol is automatically set to UDP and cannot be changed.

    Listener Port

    Specify the listener port that is used to receive and forward requests to backend servers. Valid values: 1 to 65535.

    Tag

    Select or enter a tag key and a tag value.

    Advanced Settings

    Click Modify to configure advanced settings.

    Scheduling Algorithm

    Select a scheduling algorithm. The following options are supported:

    • Weighted Round-robin (WRR): Backend servers that have higher weights receive more requests than backend servers that have lower weights.

    • Round Robin (RR): Requests are sequentially distributed to backend servers.

    • Consistent Hash (CH):

      • QUIC ID: specifies consistent hashing that is based on Quick UDP Internet Connections (QUIC) IDs. Requests that contain the same QUIC ID are distributed to the same backend server.

        Important

        QUIC is implemented based on draft-ietf-quic-transport-10 and iterates rapidly. Therefore, compatibility is not guaranteed for all QUIC versions. We recommend that you perform tests before you apply the protocol to a production environment.

      • Four-element: specifies consistent hashing that is based on four factors: source IP address, destination IP address, source port, and destination port. Requests that contain the same information based on the four factors are distributed to the same backend server.

      • Source IP: specifies consistent hashing that is based on source IP addresses. Requests from the same source IP address are distributed to the same backend server.

    Round Robin (RR) is selected by default. For more information about the scheduling algorithms, see SLB scheduling algorithms.

    Note

    If you have a TCP listener using the Weighted Round-robin (WRR) or Round Robin (RR) scheduling algorithm, you cannot modify the algorithm to Consistent Hash (CH). To use the Consistent Hash (CH) algorithm for a TCP listener, you need to create a new listener.

    Session Persistence

    Session persistence is disabled by default.

    After session persistence is enabled, the CLB instance forwards all requests from a client to the same backend server.

    Access Control

    Access control is disabled by default.

    Select an access control method after you enable access control. Then, select an access control list (ACL) that is used as the whitelist or blacklist of the listener.

    • Whitelist: Allows Specified IP Addresses to Access the SLB Instance. Only requests from the IP addresses or CIDR blocks specified in the network ACL are forwarded. Whitelists apply to scenarios in which you want to allow access only from specific IP addresses. Your service may be adversely affected if the whitelist is not properly configured. After a whitelist is configured, only requests from IP addresses that are added to the whitelist are forwarded by the listener.

      If a whitelist is configured but no IP address is added to the whitelist, the listener forwards all requests.

    • Blacklist: Forbids Specified IP Addresses to Access the SLB Instance. Requests from the IP addresses or CIDR blocks specified in the network ACL are denied. Blacklists apply to scenarios in which you want to deny access from specific IP addresses.

      If a blacklist is configured but no IP address is added to the blacklist, the listener forwards all requests.

    • Whitelist: Only requests from the IP addresses or CIDR blocks specified in the network ACL are forwarded. Whitelists apply to scenarios in which you want to allow access only from specific IP addresses. Your service may be adversely affected if the whitelist is not properly configured. After a whitelist is configured, only requests from IP addresses that are added to the whitelist are forwarded by the listener.

      If a whitelist is configured but no IP address is added to the whitelist, the listener forwards all requests.

    • Blacklist: Requests from the IP addresses or CIDR blocks specified in the network ACL are denied. Blacklists apply to scenarios in which you want to deny access from specific IP addresses.

      If a blacklist is configured but no IP address is added to the blacklist, the listener forwards all requests.

    Note

    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

    If a pay-by-bandwidth CLB instance is used, you can set a maximum bandwidth for each listener to limit the amount of network traffic forwarded by listeners. The sum of the maximum bandwidth of all listeners that are added to a CLB instance cannot exceed the maximum bandwidth of the CLB instance.

    By default, this feature is disabled and all listeners share the bandwidth of the CLB instance. For information on how listeners share the instance bandwidth, see Enable bandwidth sharing among listeners of a CLB instance.

    Important
    • For example, the maximum bandwidth of an Internet-facing CLB instance is 5 Mbit/s, and you configure two listeners. You allocate 5 Mbit/s of bandwidth to Listener A, and do not allocate bandwidth to Listener B. In this case, Listener B is inaccessible. Exercise caution when you allocate bandwidth.

    • If three listeners are configured for an internal-facing CLB instance, and the total bandwidth allocated to Listener A and Listener B is 5,120 Mbit/s, Listener C is inaccessible. Exercise caution when you allocate bandwidth.

    • If a pay-by-data-transfer CLB instance is used, the bandwidth of listeners is unlimited by default.

    Proxy Protocol

    Specify whether to use the Proxy protocol to pass client IP addresses to the backend servers. For more information, see Enable Layer 4 listeners to preserve client IP addresses and pass them to backend servers.

    Important
    • You cannot use this feature if PrivateLink is used.

    • The Proxy protocol can be used only when both the proxy server and backend servers support it. If backend servers do not support this protocol, do not directly enable this feature, as backend servers may fail to parse packets as expected, which affects the availability of backend services.

    Obtain Client Source IP Address

    Specify whether to reserve the IP addresses of clients. Only Layer 4 listeners support this feature. By default, this feature is enabled.

    Note

    If the UDP listener is added to a CLB instance deployed in the classic network, you can enable Proxy Protocol to obtain client IP addresses.

    Automatically Enable Listener

    Specify whether to immediately enable the listener after it is created. By default, listeners are enabled after they are created.

Step 2: Add backend servers

After you configure the listener, you must add backend servers to process client requests. You can use the default server group that is configured for the CLB instance. You can also configure a vServer group or a primary/secondary server group. For more information, see CLB server groups. In this example, the default server group is used.

  1. In the Backend Servers step, select Default Server Group and click Add More.

  2. In the Servers panel, select the backend servers that you want to add and click Next.

  3. In the Ports/Weights step, configure the weights of the backend servers. Click Add.

    Note
    • The default weight is 100. A backend server with a higher weight receives more requests.

    • If the weight of a backend server is set to 0, no request is distributed to the backend server.

  4. Specify the port that is used by backend Elastic Compute Service (ECS) instances to receive requests. Valid values: 1 to 65535. Click Next.

    You can specify the same port for different backend servers that are added to the same CLB instance.

Step 3: Configure health checks

CLB checks the availability of backend servers by performing health checks. The health check feature improves overall service availability and reduces the impact of backend server failures.

Note

You cannot disable health checks for a listener that is associated with a primary/secondary server group.

  1. Optional: In the Health Check step, click Modify to modify the health check configuration. For detailed instructions on configuring health checks, see Configure and manage CLB health checks. Click Next.

  2. In the Confirm step, check the configurations of the listener. You can click Modify to modify the configurations.

  3. Click Submit. In the Configuration Successful message, click OK.

    After you configure the listener, you can view the listener on the Listener tab.