Add an HTTP listener

Step 1: Configure the listener

1. Log on to the CLB console.

2. Select the region of the instance.

3. Use one of the following methods to open the listener configuration wizard:

   • On the Instances page, find the target instance and click Configure Listener in the Actions column.

   • On the Instances page, click the target instance ID. Then, on the Listener tab, click Add Listener.

4. In the Protocol & Listener wizard, complete the following settings and click Next.

   Parameter	Description
   Select Listener Protocol	Select a listener protocol. Select HTTP for this example. CLB instances in the Mexico region do not support HTTP listeners. Use an Application Load Balancer or a CLB instance in another region instead.
   Backend Protocol	When HTTP is the listener protocol, the Backend Protocol is automatically set to HTTP.
   Listener Port	The port that receives and forwards requests to backend servers. Valid values: 1 to 65535. Default HTTP port: 80.
   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. Round Robin is the default. Weighted Round-robin: Backend servers with higher weights receive more requests. Round Robin: Requests are distributed to backend servers in sequence. For scheduling algorithm details and use cases, see Scheduling algorithms.
   Redirection by Listener	When enabled, CLB redirects HTTP requests to a specified HTTPS listener by returning a 302 status code. For the complete process, see Redirect HTTP requests to HTTPS by using a CLB instance. Before enabling redirection, create the target HTTPS listener and configure its certificate. Redirection cannot be enabled on an existing HTTP listener. Delete the current listener and create a new one.
   Session Persistence	Session persistence is disabled by default. When enabled, CLB routes requests from the same client to the same backend server using cookies. Cookie Option: Insert Cookie: Specify only the cookie timeout period. On the first request, CLB inserts a cookie (ServerId) into the response. Subsequent requests with this cookie are forwarded to the same backend server. Session Persistence Timeout Period: If you select Insert Cookie, enter a timeout period for session persistence. Rewrite Cookie: Specify a custom cookie to insert into the response. You must manage the expiration and lifetime of this cookie on your backend servers. CLB overwrites the original cookie with the custom one. Subsequent requests with the new cookie are forwarded to the same backend server. Cookie Name: If you select Rewrite Cookie, enter a name for the cookie.
   Access Control	Access control is disabled by default. When enabled, select an access control method and an access control list (ACL) as a whitelist or blacklist for the listener. Whitelist: allows only trusted IP addresses to access SLB.. Only requests from IP addresses or CIDR blocks in the selected ACL are forwarded. Whitelists carry risk: once configured, only listed IP addresses can access the listener. If a whitelist is enabled but the ACL is empty, the listener forwards all requests. Blacklist: denies access from specified IP addresses to SLB.. Requests from IP addresses or CIDR blocks in the selected ACL are blocked. If a blacklist is enabled but the ACL is empty, the listener forwards all requests. Note IPv6 instances support only IPv6 ACLs, and IPv4 instances support only IPv4 ACLs. Create an ACL.
   Bandwidth Throttling for Listeners	For pay-by-bandwidth CLB instances, set a maximum bandwidth per listener to limit traffic. The sum of all listener bandwidth values cannot exceed the instance total. Disabled by default. All listeners share the instance bandwidth. See CLB listeners share the bandwidth of an instance. Important If a public-facing CLB instance has a total bandwidth of 5 Mbps and you allocate the entire 5 Mbps to listener A and 0 Mbps to listener B, listener B becomes inaccessible. Allocate bandwidth to each listener with care. If an internal-facing CLB instance has three listeners and you allocate a total of 5,120 Mbps to listeners A and B, the remaining listener C becomes inaccessible. Allocate bandwidth to each listener with care. Pay-by-data-transfer instances do not have a default maximum bandwidth.
   Idle Connection Timeout Period	Idle connection timeout. Valid values: 1 to 60 seconds. Default: 15 seconds. If no data is transferred within the timeout period, CLB closes the connection. A new connection is established on the next request. Note The maximum idle timeout for CLB Layer 7 (HTTP/HTTPS) listeners is 60 seconds and cannot be increased. If your workload requires a longer idle timeout, use a Layer 4 TCP listener (up to 900 seconds) or Application Load Balancer (ALB, idle timeout up to 3,600 seconds). The connection timeout setting applies to the entire listener. To set a different timeout for a specific backend server, configure the server with a separate listener and set the timeout on that listener.
   Connection Request Timeout	If a backend server does not respond within this period, CLB returns an HTTP 504 error to the client. Valid values: 1 to 180 seconds. Default: 60 seconds. Note The maximum request timeout for CLB Layer 7 (HTTP/HTTPS) listeners is 180 seconds and cannot be increased. For longer request timeouts, use Application Load Balancer (ALB, request timeout up to 3,600 seconds).
   GZIP Compression	Compresses specific file types. Enabled by default. Gzip supports the following file types: text/xml, text/plain, text/css, application/javascript, application/x-javascript, application/rss+xml, application/atom+xml, and application/xml.
   Custom HTTP Header	Select custom HTTP headers to add: Add the X-Forwarded-For header to retrieve the client's real IP address. Note Layer 7 CLB listeners use X-Forwarded-For by default to retrieve client IP addresses. This cannot be disabled. If the header contains multiple IP addresses, the first is the client's real IP. Retrieve client IP addresses over a Layer 7 listener. Add the SLB-ID header to retrieve the ID of the CLB instance. Add the SLB-IP header to retrieve the IP address of the CLB instance. Add the X-Forwarded-Proto header to retrieve the listener protocol of the CLB instance. Add the X-Forwarded-Port header to retrieve the listener port of the CLB instance. Add the X-Forwarded-Client-srcport header to retrieve the client port used to access the CLB instance. Note The X-Forwarded-Port and X-Forwarded-Client-srcport headers are supported only in the China (Hangzhou), China (Shanghai), China (Qingdao), China (Beijing), China (Zhangjiakou), China (Shenzhen), China (Hong Kong), and Singapore regions.
   Obtain Client Source IP Address	Retrieves visitors' real IP addresses. Enabled by default.
   Automatically Enable Listener	Specifies whether to start the listener after creation. Enabled by default.

Step 2: Add backend servers

Add backend servers to process requests. Use the default server group or create a vServer group. See Server groups. This example uses the default server group.

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

2. In the Servers step, select the backend servers that you want 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 more requests.

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

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

   Note

   Multiple backend servers in the same CLB instance can use the same port.

Step 3: Configure health checks

CLB uses health checks to determine backend server availability, improving overall service reliability.

1. Optional: In the Health Check step, click Modify to change settings, and click Next. Configure and manage CLB health checks.

2. In the Confirm step, review the listener configuration. Click Modify if you need to change any settings.

3. Confirm the configuration and click Submit. After the listener is created, click OK.

   The new listener appears on the page.

Response headers removed by Layer 7 listeners

To support session persistence, CLB modifies response headers such as Date, Server, X-Pad, and X-Accel-Redirect from backend servers.

Workarounds:

• Prefix custom response headers (e.g., xl-server, xl-date) to prevent CLB from processing them.

• Switch from a Layer 7 HTTP listener to a Layer 4 TCP listener.

The Transfer-Encoding: chunked header in responses

Symptom:

After a domain name is mapped to a Layer 7 load balancer, the "Transfer-Encoding: chunked" header appears in HTTP responses when accessed from a local machine. This header is absent when the backend server is accessed directly.

Cause:

Layer 7 load balancing uses Tengine reverse proxy, which applies chunked transfer encoding to the response body.

WebSocket support in CLB listeners

CLB HTTP listeners support WebSocket by default. Use CLB to enable real-time messaging with WebSocket.

How do I configure CLB to allow only specific domain names or block direct IP access?

CLB HTTP/HTTPS (Layer 7) listeners support domain- and URL-based forwarding rules, but CLB does not provide a built-in domain allowlist or blocklist feature. You can indirectly implement domain-level access control by combining forwarding rules with vServer groups. Note that this is access control, not security protection. To defend against attacks such as CC attacks and SQL injection, use Web Application Firewall (WAF).

Block unmatched domains or direct IP access (fallback policy)

1. Create an empty vServer group with no backend servers added.

2. Set the listener's default forwarding destination (the server group that receives traffic when no forwarding rule is matched) to this empty vServer group.

3. Configure domain-based forwarding rules that route traffic matching your target domains to the actual backend vServer group.

With this configuration, requests matching a forwarding rule are routed to the corresponding backend vServer group, whereas requests that do not match any forwarding rule — including direct IP access and requests from unrecognized domains — fall through to the empty vServer group set as the default forwarding destination and cannot reach a backend because no backend server is available.

Block access from a specific domain

Using the empty vServer group created in the previous scenario, create a forwarding rule that routes the domain you want to block to that empty vServer group. Requests from that domain are then blocked because no backend server is available.