You can create an HTTPS listener for a CLB instance to forward HTTPS requests from the client. HTTPS is suitable for HTTP applications where data transfer needs to be encrypted.
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 page and click Configure listener in the Operation column of the target instance.
3. Under HTTP/HTTPS listener, click Create and configure the HTTPS listener in the pop-up window.
3.1 Create a listener
Parameter
Description
Example
Name
Listener name.
test-https-443
Listening protocol and port
Listening protocol: In this case, select HTTPS.
Listening port: The port used to receive requests and forward them to a real server. Port range: 1-65535.
A listening port must be unique in the same CLB instance.
HTTPS:443
Enable persistent connection
Once this feature is enabled, persistent connections will be used between a CLB instance and real servers, and the CLB instance will no longer pass through the source IP address that can be obtained from XFF. To ensure normal forwarding, enable the "Allow Traffic by Default" feature in the CLB security group or allow 100.127.0.0/16 in the CVM security group.
Note:
Once this feature is enabled, the number of the connections between a CLB instance and real servers will fluctuate in the range of [QPS,QPS*60], subject to the connection reuse rate. If there is a limit on the maximum number of connections, we recommend you be cautious when enabling this feature. This feature is currently in beta test. To try it out, please submit a ticket.
The IP range 100.64.0.0/10 is already allowed as the health check source IP. You don't need to allow IPs within this range again.
Disabled
Enable SNI
If SNI is enabled, multiple domain names of a listener can be configured with different certificates; if it is disabled, multiple domain names of a listener can be configured with one certificate only.
Disabled
SSL parsing
One-way authentication and mutual authentication are supported. CLB takes over the overheads of SSL encryption and decryption to guarantee the access security.
One-way authentication
Server certificate
You can select an existing certificate in the SSL Certificate Service console or upload a certificate. You can configure two certificates that use different encryption algorithms.
Note: You can configure two certificates only for CLB but not classic CLB. After two certificates are configured, you cannot enable QUIC.
If all domain names of a listener are not matched, the system distributes requests to the default domain name, making default access controllable.
Each listener can be configured with only one default domain name.
Enabled
HTTP 2.0
After HTTP 2.0 is enabled, CLB instances can receive HTTP 2.0 requests. CLB instances access real servers over HTTP 1.1 no matter what HTTP version the client uses to access CLB instances.
For HTTP listeners, CLB supports three scheduling algorithms: weighted round robin (WRR), weighted least connections (WLC), and IP Hash.
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.
IP Hash: This algorithm uses a request source IP address as the Hash key to locate the corresponding server in the static hash table. If a server is available and not overloaded, requests will be distributed to it; otherwise, a null value will be returned.
WRR
Backend Protocol
Backend protocol is used between a CLB instance and a real server:
If HTTP is selected as the backend protocol, the HTTP service must be deployed on the real server.
If HTTPS is selected as the backend protocol, the HTTPS service must be deployed on the real server. In this case, the encryption and decryption of the HTTPS service will consume more resources on the real server.
If gRPC is selected as the backend protocol, the gRPC service must be deployed on the real server. You can select gRPC as the backend forwarding protocol only when HTTP2.0 is enabled and QUIC is disabled.
After session persistence is enabled, a CLB listener will distribute access requests from the same client to the same real server.
TCP session persistence is implemented based on client IP address. The access requests from the same IP address are forwarded to the same real server.
Session persistence can be enabled for WRR scheduling but not WLC scheduling.
Enabled
Hold Time
Session persistence is terminated if there are no new requests in the connection within the specified duration.
Value range: 30-3600 seconds
30 seconds
Step 2. Bind a real server
1. On the Listener management page, select the created listener HTTPS:443. Click + on the left to expand the domain names and URL paths, select the desired URL path, and view the real servers bound to the path 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.
Step 3. Configure a security group (optional)
You can configure a CLB security group to isolate public network traffic. For more information, see Configuring a CLB Security Group.
Step 4. Modify or delete a listener (optional)
If you need to modify or delete a created listener, click the listener on the Listener management page and click
Yes
No
Was this page helpful?