Server Load Balancer:Add an HTTP listener

Procedure

Step 1: Create a listener

1. Log on to the CLB console.

2. Select the region where the CLB instance is deployed.

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

   • On the Instances page, find the CLB instance that you want to manage and click Configure Listener in the Actions column.

   • On the Instances page, click the ID of the CLB instance that you want to manage. On the Listener tab, click Add Listener.

4. In the Protocol & Listener step, set the parameters referring to the following table and click Next.

   Parameter	Description
   Listener Protocol	Select a listener protocol. In this example, HTTP is selected.
   Backend Protocol	In this example, an HTTP listener is created. Backend Protocol is set to HTTP.
   Listener Port	Specify the listener port that is used to receive and forward requests to backend servers. Valid values: 1 to 65535. By default, HTTP uses port 80.
   Tag	Select or enter a tag key and a tag value.
   Advanced Settings	Click Modify to configure advanced settings.
   Scheduling Algorithm	Select a scheduling algorithm. By default, Round-Robin (RR) is selected. Weighted Round-Robin (WRR): Backend servers that have higher weights receive more requests than backend servers that have lower weights. Round-Robin (RR): Requests are distributed to backend servers in sequence. For more information about the scheduling algorithms, see SLB scheduling algorithms.
   Redirection by Listener	Specify whether to redirect traffic from the HTTP listener to an HTTPS listener. To enable traffic redirection, you must also select an HTTPS listener. Note If you disable this feature, the feature can no longer be enabled after the listener is created. To use this feature, you need to create another listener. Before you enable traffic redirection, make sure that an HTTPS listener is created. For more information, see Use CLB to redirect requests from HTTP to HTTPS.
   Session Persistence	Session persistence is disabled by default. After the session persistence feature is enabled, the CLB instance distributes requests that are from the same client to the same backend server. CLB enables persistence of HTTP sessions based on cookies. Cookie Options: Insert cookie: If you select this option, you need to only specify the timeout period of the cookie. CLB inserts a cookie (SERVERID) into the first HTTP or HTTPS response that is sent to a client. The next request from the client contains the cookie, and the listener forwards the request to the recorded backend server. Persistent Timeout: If you select Insert cookie, specify a timeout period for session persistence. Rewrite cookie: If you select this option, you must specify the cookie that you want to insert into an HTTP or HTTPS response. In this case, you must specify the timeout period and lifetime of the cookie on a backend server. After you specify a cookie, CLB overwrites the original cookie with the specified cookie. The next time CLB receives a client request that contains the specified cookie, the listener distributes the request to the recorded backend server. Cookie Name: If you select Rewrite cookie, you must specify a name for the cookie.
   Access Control	Access control is disabled by default. Select an access control method after you enable access control. Then, select 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 IPv6 instances can be associated only with IPv6 ACLs. IPv4 instances can be associated only with IPv4 ACLs. For more information, see Create an ACL.
   Enable Peak Bandwidth Limit	If a pay-by-bandwidth CLB instance is used, you can set the maximum bandwidth of each listener to limit the amount of network traffic forwarded by listeners. The sum of the maximum bandwidth of all listeners that are added to a CLB instance cannot exceed the maximum bandwidth of the CLB instance. By default, this feature is disabled and all listeners share the bandwidth of the CLB instance. Important For example, the maximum bandwidth of an Internet-facing CLB instance is 5 Mbit/s, and you configure two listeners. You allocate 5 Mbit/s of bandwidth to Listener A, and do not allocate bandwidth to Listener B. In this case, 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 unlimited by default.
   Idle Connection Timeout Period	Specify the longest time that a TCP connection between CLB and the client can stay open when no data is transferred over the connection. If no request is received within the specified timeout period, CLB closes the connection. When a request is received, CLB establishes a new connection. Note This timeout period applies to all servers group associated with the listener. If you want to specify another timeout period for a specific backend server, create a separate listener for this backend server and set the timeout period that you want.
   Connection Request Timeout	If no response is received from a backend server within the specified timeout period, CLB returns the HTTP 504 status code to the client. Valid values of this parameter range from 1 to 180 (in seconds).
   GZIP Compression	If you enable GZIP compression, files of specific types are compressed. If you disable GZIP compression, no file is compressed. This feature is 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 the HTTP headers that you want to add. Valid values: X-Forwarded-For: Retrieve Client IP: obtains client IP addresses. Note By default, Layer 7 listeners of CLB use the X-Forwarded-For header to preserve client IP addresses. The header cannot be disabled. If more than one IP address is preserved, the first one is the client IP address. For detailed configuration, see Enable Layer 7 listeners to preserve client IP addresses. SLB-ID: Retrieve SLB ID: obtains the ID of the CLB instance. SLB-IP: Retrieve SLB IP: obtains the IP address of the CLB instance. X-Forwarded-Proto: Retrieve Listener Protocol: obtains the listener protocol.
   Client IP Address Preservation	This feature retrieves client IP addresses and is enabled by default.
   Automatically Enable Listener	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

After the listener is created, you must add backend servers to process client requests. You can use the default server group that is configured for the CLB instance. You can also create a vServer group. For more information, see CLB backend servers.

In this example, backend servers are added to 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, configure the weights of the backend servers.

   Note

   • The default weight is 100. Backend servers with a higher weight receive more requests.

   • If the weight of a backend server is set to 0, no request is distributed to the backend server.

4. Click Add. Specify the port that is used by the backend server to receive requests. Valid values: 1 to 65535.

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

Step 3: Configure health checks

CLB checks the availability of backend servers by performing health checks. The health check feature improves overall service availability and reduces the impact of backend server failures.

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

2. In the Confirm step, check the configurations of the listener. You can click Modify to modify the configurations.

3. Confirm the configurations and click Submit. In the Configuration Successful message, click OK.

   After you configure the listener, you can view the listener on the Listener tab.

FAQs

Why are some HTTP headers removed from responses returned by backend servers that are forwarded by Layer 7 CLB?

To implement session persistence, CLB modifies HTTP headers including Date, Server, X-Pad, and X-Accel-Redirect in responses received from backend servers before forwarding them to clients.

Solutions:

• Add a prefix to custom HTTP headers you configure on backend servers, such as xl-server or xl-date, to bypass header processing by CLB.

• Use Layer 4 listeners.

Why does CLB add the Transfer-Encoding: chunked header to HTTP requests?

Issue:

After I resolved a custom domain name to the IP address of a Layer 7 CLB instance, if I access the custom domain name from my local PC, the Transfer-Encoding: chunked header is added to HTTP requests. This header does not exist if I directly access backend servers from the local PC.

Cause:

Layer 7 CLB instances implement load balancing based on the Tengine reverse proxy. The Transfer-Encoding header indicates how the web server encodes the response message body. For example, Transfer-Encoding: chunked indicates that chunked transfer encoding is used.

How do I configure CLB listeners to support WebSocket?

By default, CLB HTTP listeners support WebSocket. For more information, see Use WebSocket to enable real-time messaging.