All Products
Search

This Product

    Server Load Balancer:Add a UDP listener

    Document Center

    Server Load Balancer:Add a UDP listener

    Last Updated:May 14, 2026

    You can add a UDP listener to a Classic Load Balancer (CLB) instance to forward UDP requests from clients. This is ideal for scenarios that require real-time performance over reliability, such as video chats and real-time financial data streaming.

    Limitations

    Before you add a UDP listener, note the following limitations:

    • The system reserves ports 250, 4789, and 4790. These ports are unavailable.

    • IP fragmentation is not supported.

    • UDP listeners for CLB instances in the classic network cannot retrieve source IP addresses.

    • Because the IPv6 IP header is longer than the IPv4 header, when you use a UDP listener on a CLB IPv6 instance, ensure that the MTU of the network interface card on the backend server (typically an ECS instance) that communicates with CLB is at least 1200. Some applications may also require you to update their configuration files to match this MTU value. Otherwise, packets may be dropped because they are too large.

      If you use a TCP, HTTP, or HTTPS listener, no additional configuration is required because the TCP protocol supports automatic MSS negotiation.

    Prerequisites

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

    Procedure

    Step 1: Configure the listener

    1. Log on to the Classic Load Balancer (CLB) console.

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

    3. On the Instances page, find the target instance and configure the listener in one of the following ways:

      • In the Actions column, click Configure Listener.

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

    4. In the Protocol & Listener step, set the following options and click Next.

      Parameter

      Description

      Select Listener Protocol

      Select UDP.

      Backend Protocol

      When Select Listener Protocol is set to UDP, Backend Protocol is automatically set to UDP.

      Listener Port

      The port used to receive and forward requests to backend servers. Valid values: 1 to 65535.

      Tags

      Select or enter a Tag Key and a Tag Value.

      Advanced Settings

      Click Modify to expand the advanced settings.

      Scheduling Algorithm

      Select a scheduling algorithm. The default algorithm is Round Robin (RR). For more information about scheduling algorithms and their use cases, see Load balancing scheduling algorithms.

      • Weighted Round-robin (WRR): Backend servers with higher weights receive a higher percentage of requests.

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

      • Consistent Hashing (CH):

        • QUIC ID: Requests are distributed based on a consistent hash of the QUIC Connection ID. Requests with the same QUIC Connection ID are routed to the same backend server.

          Important

          QUIC is a rapidly evolving protocol. This algorithm is implemented based on draft-ietf-quic-transport-10 and may not be compatible with all QUIC versions. We recommend that you test this algorithm thoroughly before you use it in a production environment.

        • Four-element: Requests are distributed based on a consistent hash of a four-element tuple (source IP address, destination IP address, source port, and destination port). Flows with the same tuple are routed to the same backend server.

        • Source IP: Requests are distributed based on a consistent hash of the source IP address. Requests from the same source IP address are routed to the same backend server.

          Note

          You cannot change an existing TCP listener's scheduling algorithm from Weighted Round-robin (WRR) or Round Robin (RR) to Consistent Hashing (CH). To use the Consistent Hashing (CH) algorithm, you must create a new UDP listener and set its scheduling algorithm to Consistent Hashing (CH).

      Session Persistence

      Session persistence is disabled by default.

      If you enable this feature, the listener directs requests from the same client to the same backend server.

      Access Control

      Access control is disabled by default.

      After you enable this feature, select an access control method and an access control list (ACL) to use as a whitelist or blacklist for the listener.

      • Whitelist: Allows Specified IP Addresses to Access the SLB Instance Use a whitelist to allow access only from specific IP addresses.

        If you enable a whitelist but do not add any IP addresses to the ACL, the listener forwards all requests.

      • Blacklist: Forbids Specified IP Addresses to Access the SLB Instance Use a blacklist to block access from specific IP addresses.

        If you enable a blacklist but do not add any IP addresses to the ACL, the listener forwards all requests.

      Note

      IPv4 instances can be associated only with IPv4 access control lists (ACLs). IPv6 instances can be associated only with IPv6 ACLs. For more information, see Create an access control list.

      Bandwidth Throttling for Listeners

      For pay-by-bandwidth CLB instances, you can set different peak bandwidth values for different listeners to limit the traffic of each listener. The sum of the peak bandwidth values of all listeners on an instance cannot exceed the bandwidth of the instance.

      By default, this feature is disabled, and all listeners share the instance's total bandwidth. For more information about how bandwidth is shared, see Bandwidth sharing among CLB listeners.

      Important

      • If a public-facing CLB instance has a total bandwidth of 5 Mbps and you configure two listeners where listener A is allocated 5 Mbps and listener B is not allocated any bandwidth, listener B becomes inaccessible. Allocate bandwidth carefully.

      • If an internal-facing CLB instance has three listeners and listeners A and B together use 5,120 Mbps of bandwidth, the remaining listener C becomes inaccessible. Allocate bandwidth carefully.

      • For instances that use the pay-by-data-transfer billing method, the peak bandwidth is not limited by default.

      Proxy Protocol

      Use the Proxy Protocol to pass the client source address to backend servers. For more information, see Use the Proxy Protocol to obtain the source IP address.

      Important

      • Obtaining source IP addresses through the Proxy Protocol is not currently supported in PrivateLink scenarios.

      • The Proxy Protocol must be supported by both the proxy server and the backend servers. If the backend servers cannot parse the Proxy Protocol, enabling this feature directly may cause the backend service to fail to parse requests, which affects service availability.

      Obtain Client Source IP Address

      For Layer 4 listeners, backend servers automatically receive the client's real source IP address. This feature is enabled by default.

      Note

      For UDP listeners of CLB instances in the classic network, you can enable Proxy Protocol to obtain the source IP address.

      Automatically Enable Listener

      Specifies whether to enable the listener after it is configured. This feature is enabled by default.

    Step 2: Add backend servers

    Add backend servers to handle frontend requests. You can use the default server group of the instance, or configure a vServer group or a primary/secondary server group for the listener. For more information, see Backend servers. This topic uses the default server group as an example.

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

    2. In the Select Servers step, select the backend servers to add and click Next.

    3. In the Ports/Weights step, set the weight and click Add.

      Note

      • The default weight is 100. Backend servers with higher weights receive a larger share of requests.

      • A backend server with a weight of 0 does not receive new requests.

    4. Configure the port that the backend server (an ECS instance) uses to receive requests, and click Next. Valid values: 1 to 65535.

      Note

      Backend servers within the same CLB instance can use the same port.

    Step 3: Configure health checks

    CLB uses health checks to determine the availability of backend servers, which improves the overall availability of frontend services and avoids service disruptions caused by abnormal backend servers.

    Note

    You cannot disable health checks for listeners that use a primary/secondary server group.

    1. Optional: In the Health Check step, click Modify to modify the health check configuration, and then click Next. For more information, see Configure and manage CLB health checks.

    2. In the Confirm step, review the listener configuration. To change the configuration, click Modify.

    3. After you confirm the configuration, click Submit. After the listener is configured, click OK.

      After the listener is created, you can view it on the page.