Add a TCP listener to a CLB instance - Server Load Balancer

When your business requires high reliability, high data accuracy, and can tolerate relatively slower speeds, such as file transfer, sending or receiving emails, and remote logon, you can add a TCP listener to a CLB instance to forward TCP protocol requests from clients to backend servers for processing.

Prerequisites

You have created a CLB instance. For more information, see how to create and manage CLB instances.

Procedure

Step 1: configure the listener

Log on to the Classic Load Balancer (CLB) console.
In the top menu bar, select the region where your CLB instance resides.
Select one of the following methods to open the listener configuration wizard.
- On the Instance Management page, find the target instance, and then click Listener Configuration Wizard in the Actions column.
- On the Instance Management page, find the target instance, click the instance ID. On the instance product page, select the Listener tab, and click Add Listener.

In the Protocol & Listener configuration wizard, complete the following configurations, and then click Next.

Listener Configuration	Description
Select Listener Protocol	Select TCP.
Backend Protocol	When TCP is selected in this topic, the Backend Protocol is TCP.
Listener Port	Specify the listener port that is used to receive and forward requests to backend servers. The port range is 1 to 65535.
Tag	Select or enter the Tag Key and Tag Value.
Advanced Configuration	Click Modify to expand the advanced configuration.
Scheduling Algorithm	You can select the following scheduling algorithms. By default, Round Robin (RR) is selected. For more information about scheduling algorithms and scenarios, see Introduction to SLB Scheduling Algorithms. Weighted Round Robin (WRR): Backend servers with higher weights are more likely to be polled. Round Robin (RR): External requests are distributed to backend servers in sequence. Consistent Hashing (CH): Four-tuple: Consistent hashing based on the four-tuple (source IP, destination IP, source port, and destination port). The same stream is scheduled to the same backend server. Source IP: Consistent hashing based on the source IP address. The same source address is scheduled to the same backend server. Note Only guaranteed-performance instances support the consistent hashing (CH) scheduling algorithm. You cannot change the scheduling algorithm of an existing TCP listener from Weighted Round Robin (WRR) or Round Robin (RR) to Consistent Hashing (CH). To use the Consistent Hashing (CH) scheduling algorithm, you need to create a new TCP listener and configure the scheduling algorithm as Consistent Hashing (CH).
Enable Session Persistence	By default, session persistence is disabled. After session persistence is enabled, the SLB listener forwards all requests from the same client to the same backend server. For TCP listeners, session persistence is implemented based on IP addresses. Requests from the same IP address are forwarded to the same backend server.
Enable Access Control	By default, access control is disabled. After access control is enabled, select an access control method and set an access control list (ACL) 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 IPv4 instances can only be associated with IPv4 ACLs, while IPv6 instances can only be associated with IPv6 ACLs. For more information, see Create an Access Control List.
Enable Listener Bandwidth Throttling	If the SLB instance is billed based on bandwidth usage, you can set different maximum bandwidth values for different listeners to limit the amount of traffic that can be forwarded by each listener. The sum of the maximum bandwidth of all listeners that are added to an SLB instance cannot exceed the maximum bandwidth of the SLB instance. By default, this feature is disabled. All listeners share the total bandwidth of the instance. For more information about how to share the total bandwidth, see CLB Listener Shared Instance Bandwidth. Important If the maximum bandwidth of an Internet-facing CLB instance is 5 Mbit/s and you configure two listeners, allocating 5 Mbit/s of bandwidth to Listener A and not allocating bandwidth to Listener B, 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 not limited by default.
Connection Timeout	The maximum time that a TCP connection between a CLB instance and a client can remain open when no data is being transferred. The default range is 10 to 900 seconds. If no request is received within the timeout period, the CLB instance closes the current connection and establishes a new connection when the next request arrives. Note After you set a connection timeout, the setting applies to the entire listener. If you need to set a connection timeout for a specific backend server, you must configure a separate listener for the backend server and set the connection timeout in the new listener.
Proxy Protocol Configuration	The Proxy Protocol is used to carry the client's source address to the backend server. For more information, see Obtain the Real IP Address of a Client through a CLB Layer 4 Listener Important PrivateLink scenarios currently do not support obtaining the source address through the Proxy Protocol. The Proxy Protocol requires both the proxy server and the backend server to support the protocol for it to function properly. If the backend server cannot parse Proxy Protocol headers but the Proxy Protocol is enabled, parsing errors may arise on the backend server and compromise service availability.
Obtain Client Real IP	For Layer 4 listeners, backend servers can directly retrieve the real IP address of the client. By default, this feature is enabled.
Automatically Start Listener After Creation	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

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 Group. This topic uses the default backend server group as an example to describe the configuration.

In the Backend Server configuration wizard, select Default Server Group, and click Continue To Add.
In the Select Server configuration wizard, select the backend servers to add, and click Next.
In the Configure Port and Weight configuration wizard, set the weight, and click Add.
Note
- The default weight is 100. A 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.
Configure the port on the backend server (ECS instance) to receive requests, and click Next. The port range is 1 to 65535.

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

Step 3: configure health check

CLB employs health checks to ensure the availability of backend servers, thereby enhancing the availability of frontend services and preventing service disruptions due to backend server issues.

Note

Health checks cannot be disabled for listeners in primary/secondary server groups.

Optional:In the Health Check configuration wizard, click Modify to change the health check configuration, and click Next. For more information, see the referenced document.
In the Configuration Review configuration wizard, check the listener configuration, and click Modify to change the configuration.
After confirming that everything is correct, click Submit. After the configuration is successful, click Got It.

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

FAQ

How to set domain name access for services configured with the TCP protocol on a Classic Load Balancer CLB?

Directly resolve your custom domain name to the public endpoint of the CLB instance. For more information, see Set an A Record for Domain Name Resolution.

How to enable backend persistent connection on a Classic Load Balancer CLB?

CLB instances do not support enabling backend persistent connections. To achieve this, you need to deploy and enable Keep-Alive on the corresponding backend servers. ALB server groups support enabling backend persistent connections. For more information, see Create and Manage Server Groups.

References

For more information about backend server groups, see the following topics:
For more information about health check principles, see CLB Health Check. For more information about configuring health check parameters, see Configure and Manage CLB Health Checks.
If you encounter issues related to listeners, see CLB Listener Service FAQ for troubleshooting and solutions.
For more information about load balancing scheduling algorithms, see Introduction to SLB Scheduling Algorithms.
If you need backend servers to obtain the real IP address of clients through a CLB when using a TCP listener, see the tutorial Obtain the Real IP Address of a Client through a CLB Layer 4 Listener for configuration.