You can create a TCP listener for a Cloud Load Balancer (CLB) instance to forward TCP requests from the client. TCP is suitable for scenarios that have high requirements for reliability and data accuracy but relatively low requirements for transmission speed, such as file transfers, email messaging, and remote logins. Real servers bound to the TCP listener can directly obtain the real client IP address.
1. Log in to the CLB console and click Instance management in the left sidebar.
2. Select your region in the top-left corner of the CLB instance list and click Configure listener in the Operation column of the target instance.
3. Under TCP/UDP/TCP SSL/QUIC listener, click Create and configure the TCP listener in the pop-up window.
3.1 Configure basic parameters
Parameter
Description
Example
Name
Listener name.
test-tcp-80
Listening Protocol and Port
Listening protocol: In this case, select TCP.
Listening port: The port used to receive requests and forward them to the real server. The port ranges from 1 to 65535.
A listening port must be unique in the same CLB instance.
TCP:80
Balancing Method
CLB supports two scheduling algorithms for TCP listeners: weighted round robin (WRR) and weighted least connections (WLC).
WRR: Requests are distributed to real servers in sequence based on their weights. This algorithm performs scheduling based on the number of new connections. Servers with higher weights are more likely to be scheduled and servers with the same weight process the same number of connections.
WLC: Loads of servers are estimated based on the number of active connections to the servers. This algorithm performs scheduling based on server loads and weights. For servers with the same weight, those have less loads are more likely to be scheduled.
Note:
Note: If WLC is selected, the listener does not support session persistence.
WRR
ProxyProtocol Configuration
After it is selected, you can enable the ProxyProtocol configuration. This allows ProxyProtocol to carry the client's source address to the real server.
Selected
Rescheduling
The rescheduling feature for existing connections is designed to proactively manage and migrate existing connections when the real server status changes, improving service availability and business continuity. This feature is currently in beta test. If you want to use it, please submit a ticket.
If it is disabled, existing connections with the same five-tuple are not actively interrupted. They are automatically released only when the connection idle time exceeds the value configured for Idle Connection Timeout Period. For example, when a health check exception occurs on a real server, new traffic is forwarded to other normal real servers. However, existing traffic continues to be forwarded to the abnormal real server, which may cause packet loss and service exceptions.
If it is enabled, the disconnection policy and rescheduling timing for existing connections can be precisely controlled and connection migration can be actively triggered. You can select the disconnection method for existing connections, rescheduling trigger condition, rescheduling start time, and rescheduling duration as needed. After configuration, the corresponding operation triggers the existing connections on the real server to continue forwarding for a specified period. When the period ends, RST packets are sent to both ends (the client and server) to disconnect the connections, achieving rescheduling of existing connections.
Disconnection method for existing connections:
Immediate disconnection: Existing connections are forcibly terminated to quickly complete rescheduling.
Graceful disconnection: Connections are disconnected progressively to minimize service impact.
Rescheduling trigger conditions:
The real server is unbound.
The real server weight is 0.
A health check exception occurs on the real server.
Rescheduling start time: It is configurable only when the graceful disconnection method is selected. A value of 0 indicates that rescheduling starts immediately. Any other value indicates that rescheduling starts after a specified delay once the condition is met. This design adapts to complex production network scenarios and provides a buffer period.
Rescheduling duration: It is configurable only when the graceful disconnection method is selected. It indicates the duration for which the existing connection is interrupted. It controls the pace and intensity of connection interruption.
Note:
Rescheduling of existing connections is triggered only when the client has data packets.
Rescheduling of existing connections only accelerates their convergence in specific scenarios and cannot cover all exception scenarios. To ensure ultimate business robustness and continuity, the client must have a fault tolerance mechanism that establishes new connections for retry after a connection times out or is disconnected.
Enable and select required conditions.
Idle Connection Timeout Period
The current TCP connection timeout defaults to 900 seconds. If there is no data transmission in the session after the time threshold is exceeded, the connection will be disconnected. If adjustments are needed, submit a ticket application.
Value range for an LCU-supported instance: 10–1980. Unit: seconds.
Value range for other types of instances: 10–900. Unit: seconds.
900 seconds
3.2 Configure health check
For more information about health check, see TCP Listener.
3.3 Configure session persistence
Parameter
Description
Example
Session Persistence
After session persistence is enabled, a CLB listener distributes access requests from the same client to the same real server.
TCP session persistence is implemented based on the client IP address. That is, the access requests from the same IP address are forwarded to the same real server.
Session persistence can be enabled for WRR scheduling instead of WLC scheduling.
Enabled
Session Persistence Duration
Session persistence is terminated if no new requests are received for the connection within the specified duration.
The value range is 30–3600. Unit: seconds.
30 seconds
Step 2: Binding a Real Server
1. On the Listener management page, click the created listener test-tcp-80 to view the bound real servers on the right of the listener.
2. Click Bind, select the target real server, and configure the server port and weight in the pop-up window.
Note:
If you set Default port first and then select real servers, the port of every real server is the default port.
(Optional) Step 3: Configuring a Security Group
You can configure a CLB security group to isolate public network traffic. For more information, see Configuring a CLB Security Group.
(Optional) Step 4: Modifying/Deleting a Listener
If you need to modify or delete a created listener, click the listener on the Listener management page and click
