Docs

Load Balancer

Creating a listener

Creating a HTTP listener

Action description

Each port can only be monitored by one listener.

A Classic Load Balancer (CLB) instance cannot create new listeners when the aggregate bandwidth of its existing listeners equals the instance's maximum bandwidth limit. If creation is still required, first either adjust bandwidth for existing listeners via Edit Listener settings or upgrade the specification of the CLB instance through Changing instance specification to ensure that the total bandwidth remains below the instance's maximum bandwidth limit.

IPv6 access requests currently only support forwarding to IPv4 backend servers through layer 7 listeners (HTTP and HTTPS protocols).

Procedures

In the top menu bar, select the target project and region.

Click Configure Listener to the right of the target CLB instance.

Click Add Listener, and see the table below to complete the basic configuration of the listener.

Parameter	Explanation	Example
Listener name	Set the name of Listener. If left blank, it defaults to Protocol-Port, for example HTTP-80.	listener-1
CLB protocol	Select the protocol type for CLB instance listener.	HTTP
Listening port	This refers to the listening port. The listener forwards requests from this port to the backend server group.	80
Scheduling algorithm	Specify the rule that the listener follows to forward requests. Weighted Round Robin (WRR): In this case, higher weights values receive more frequent polling attempts (higher probability). Weighted Least Connection (WLC): First calculate the current connections/weight value of the backend server, then dispatch the request to the backend server with the smallest value. Source hashing (SH): A consistency hash based on the Source IP address, allowing the same source to be scheduled to the same backend server.	Weighted Round Robin (WRR)

Set the timeout according to the table below.

Parameter	Explanation	Example
keepalive_timeout	Keepalive timeout between the client and the CLB. If there are no access requests within the timeout period, the CLB will terminate the current connection and establish a new connection upon the next request. Valid input range: 0–900 seconds. Setting it to 0 disables keepalive connections.	75 seconds
client_header_timeout	Enter the timeout for reading the client_header_timeout. If the client does not transmit the complete header within the timeout, CLB returns error code 408, indicating a request timeout. Value range: 30 to 120 seconds.	60 seconds
client_body_timeout	Enter the timeout for reading the client_body_timeout. When the client sends a request to CLB, if the client does not send any request body within the timeout period, CLB returns error code 408 to the client, indicating the request timed out. This timeout only applies to the interval between two consecutive read operations, not the entire request transmission process. Value range: 30 to 120 seconds.	60 seconds
send_timeout	Enter the timeout for CLB to send a response to the client. When CLB sends a response to the client, if the client does not receive any data within the timeout period, the connection will be closed. This timeout applies only between two consecutive write operations, not the entire response transmission process. Value range: 1 to 3600 seconds.	60 seconds
proxy_read_timeout	Enter the timeout for CLB to read responses from the backend server. CLB sends requests to the backend server. If no response is received from the server within the timeout, the connection will close. This timeout applies only between two consecutive read operations, not the entire response transmission. Value range: 30 to 3600 seconds.	60 seconds
proxy_send_timeout	Enter the CLB timeout for transmitting requests to the backend server. When CLB sends a request to the backend server, it closes the connection if no data is received within the timeout period. This timeout applies only between two consecutive write operations, not the entire request transmission. Value range: 30 to 3600 seconds.	60 seconds
proxy_connect_timeout	Enter the timeout for establishing a connection between the CLB and the backend server. If the connection between CLB and the backend server is not established within the timeout period, the connection attempt will be terminated. It is advised to set this longer than the health check timeout. Input range: 4–120 seconds.	4 seconds

Configure more advanced features for the listener according to the table below.

Parameter	Explanation	Example
Access control	Indicates whether the listener applies an allowlist or denylist to control access requests, allowing or blocking certain IPs; the default is off. For details, see ACL overview. After turning on Identity and Access Management (IAM), select the control method and policy group name. Control method Denylist: prohibits IPs in the selected policy group from accessing this CLB instance. If the selected policy group contains no IPs, all source IPs are allowed to access this listener. Allowlist: only allows IPs in the selected policy group to access this CLB instance. If the selected policy group contains no IPs, all source IPs are denied access to this listener. Configure carefully. Policy group name Select an access control policy group. IPs in the policy group will be added to the listener’s denylist or allowlist. Up to 5 policy groups can be selected. If no policy group exists yet, click Create access control policy group in the selection box and refer to Creating a policy group.	Turn on, denylist, policy01
Session Persistence	When the scheduler is Weighted Round Robin (WRR), enabling sticky session for the listener is optional. After enabling session persistence, the load balancer forwards requests from the same client to the same backend server based on cookies. Select the cookie handling method and set the session persistence timeout or cookie name as needed. Cookie processing method: Supports both Cookie Insertion and Cookie Rewriting. Cookie Insertion: The CLB notes the backend server to which the client's request is initially forwarded and injects Cookies (CLBSERVERID and CLBSERVERCORSID) into the response before forwarding it to the client. Subsequent client requests carry this cookie information, and the load balancer forwards the requests to the corresponding backend server. This method requires specifying the Cookie expiration time (Session persistence timeout duration). The session established timeout defaults to 1000 seconds, with a range of 1 to 86400 seconds. Cookie rewriting: You define the name of the backend cookie to be rewritten. When the client's first request is responded to by the backend server and reaches CLB, the CLB locates the specified cookie name in the response and rewrites it before forwarding the response to the client. Subsequent client requests carrying the specified Cookie are forwarded by the load balancer to the corresponding backend server. When selecting this method, you must specify the cookie to be injected into the response, namely the Cookie Name. tip If the backend server’s response Cookie does not match the specified Cookie name, the load balancer does not rewrite the Cookie and forwards the request according to the configured routing algorithm.	Turn on, implant cookies, 1000 seconds
Bandwidth cap	Select whether to enable bandwidth speed limit for the listener. After turning on the switch, set the bandwidth limit for this listener. The maximum value equals the remaining unallocated bandwidth of the CLB instance specification to which the listener belongs, measured in Mbps.	Enable, 100Mbps
Max new connections limit	Type CLB's maximum limit of new connections as needed. Value range: 1 to the CLB's maximum limit of new connections. The default value is CLB's CPS. When new connections captured by the listener exceed the configured threshold, excess connections will be discarded and not forwarded to the backend server. tip This feature is currently in Beta stage. For trial requests, please contact your account manager.	30000
Max Connections	Type CLB's maximum limit of concurrent connections as needed. Value range: 1 to the CLB's maximum limit of concurrent connections. The default value is CLB's Max Connections. When concurrent connections captured by the listener exceed the configured threshold, excess connections will be discarded and not forwarded to the backend server. tip This feature is currently in Beta stage. For trial requests, please contact your account manager.	300000
Tags	A tag consists of a key-value pair and is used for categorizing and searching resources For more information, see Tag management. Click the Add icon, input the tag key and tag value, and add a tag for the listener.	Tag key: listener-key Tag value: listener-test

Click Next to configure the default backend server group.

Select the adding method and backend server group as needed.

If there is an existing backend server group that meets the requirements, search or select from the dropdown.

If there is no Server Group that meets your needs, you can create one. For detailed parameter information, see Creating a Server Group.

Click Next to add a backend server to the Server Group.

Select the adding method as needed and configure the backend servers.

If existing backend servers are available, you can choose to add them directly, and configure the port and weight of each backend server. For more information, refer to Adding a backend server.

If there are no available backend servers, select Add Later after creating the listener.

tip

After creating the listener, the system automatically creates a default forwarding rule and associates it with the default server group. The default forwarding rule has an empty domain name and a / URL, meaning it can forward requests for any domain and URL. If a request does not match any other forwarding rules in the listener, it will be forwarded to the default server group via the default forwarding rule. For more information on forwarding rules, refer to Configure forwarding rule.

When selecting an existing backend server group or adding a backend server to a server group, ensure the security group allows traffic using the same protocol as the listener by referring to Configuring a backend server security group.

Click Next to configure health check information, as shown below.

The health check configuration can remain at the default settings here. If modification is required, refer to Configuring health check for detailed parameter descriptions.

tip

After configuring the health check, the CLB instance will periodically send requests to backend servers to test their status and determine availability. If a backend server is detected to be in poor health, traffic will stop being forwarded to it and will be redirected to other normally functioning backend servers.

Click Next to review all configuration information of the listener, and complete the creation of the listener.

If there are errors in the configuration information, click the add icon to return to the corresponding page and modify the settings.

After verifying the configuration details, click OK to create the listener.

What to do next

The HTTP listener enables Gzip data compression by default.

When a client request includes the Accept-encoding: gzip header, the CLB compresses responses from the backend server before returning them to the client, provided the responses contain the files of specific types (including text/plain, text/css, text/xml, application/xml, text/javascript, application/x-javascript, application/json, application/javascript, application/x-protobuf).

In addition to forwarding traffic to servers in the default server group, you can add forwarding rules to route traffic to other server groups. For specific actions, refer to Configuring a forwarding rule.