HTTPS Listener Introduction
You can add an HTTPS listener to your CLB instance to forward HTTPS requests from clients. The HTTPS protocol is suitable for HTTP applications that require encrypted transmission.
Configuring an HTTPS Listener
Step 1: Open the Listener Management page
- Log in to the CLB console. In the left sidebar, click LB Instance List.
- On the CLB instance list page, click the target instance ID.
- On the instance details page, click the Listener Management tab page.
Step 2: Configure the listener
In the HTTP/HTTPS Listener module, click Create and configure an HTTPS listener in the pop-up.
1. Create a listener
| Basic Configuration of Listener | Description | Example |
|---|---|---|
| Name | The name of the listener. | test-https-443 |
| Listen Protocol Port | The listener's protocol and listening port. - Listener protocol: The protocols supported by CLB under this listener include HTTP and HTTPS. In this example, HTTPS is selected. - Listening port: The port is used to receive requests and forward them to the backend server. The port range is 1-65535. - The listening ports in the same CLB instance cannot be repeated. |
HTTPS:443 |
| Default Domain Name | You can choose to enable or disable it. - Enable: When the client request does not match any domain name of this listener, CLB will forward the request to the default domain name (Default Server). Each listener can only be configured and is required to be configured with one default domain name. - If your layer-7 listener has been configured with a default domain name, client requests that do not match other rules will be forwarded to the default domain name. - If your layer-7 listener is not configured with a default domain name, client requests that do not match other rules will be forwarded to the first domain name loaded by CLB. Since the loading order may be inconsistent with the console configuration order, the domain name is not necessarily the first one configured by the console. - Disable: Client requests that do not match any domain name of this listener cannot be forwarded. |
Enable |
| Enabling SNI | Enabling SNI means that different certificates can be configured for different domain names under a listener. Not enabling SNI means that multiple domain names under the listener use the same certificate. | Enable |
| SSL Parsing Method | Support one-way authentication and two-way authentication. | One-way Authentication |
| Server Certificate | Select an existing certificate. | Selecting an Existing Certificate |
The specific configuration for creating an HTTPS listener is shown in the figure below.
2. Create forwarding rules
| Basic Configuration of Forwarding Rules | Description | Example |
|---|---|---|
| Domain name | Request a domain name. - Support precise domain names, such as www.example,com. Support wildcard domain names, such as *.example.com or www.example.* , in a single domain name * Can only appear once.- The character sets supported by irregular domain names are as follows: az``0-9``.``-.- Support regular expressions. The character sets that are not supported in regular expressions are as follows: "``{``}``;``\```````~`````Space.- The domain name length limit is 1-120. |
www.example.com |
| Default Domain Name | - When all domain names in the listener are not matched successfully, the system will direct the request to the default access domain name to make the default access controllable. - Only one default domain name can be configured for a listener. |
Enable |
| URL Path | Request path. - The default is /, must be preceded by /.The length limit is 1-120.- Non-regular URL path starts with / . The supported character sets are as follows: a-z``A-Z``0-9``.``-``/``=``? .- Support regular expressions. - Beginning with = indicates an exact match.- Beginning with ^~ indicates that the uri starts with a regular character string, not a regular match.- Beginning with ~ indicates a case-sensitive regular match.- Beginning with ~* indicates a case-insensitive regular match.- / means universal matching. Any request will be matched if there is no other match.- For the regular URL, unsupported character sets are as follows: "``{``}``;``\ ``` ~`````Space. |
/index |
| Balance Mode | In the HTTPS listener, CLB supports three scheduling algorithms: weighted round-robin (WRR), weighted least connections (WLC), and IP Hash. - Polling by Weight: Requests are distributed to different servers in turn based on the weight of the backend servers. Schedule by the weighted round-robin algorithm, based on the number of new connections. The server with a higher weight is rounded more often (high probability), and servers with the same weight handle the same number of connections. - Min. Weighted Connections: The server load is estimated based on the number of active connections currently on the server. For the weighted least connections algorithm, comprehensive scheduling is realized based on the server load and weight. When the weight values are the same, the backend server with fewer current connections will be selected more often (has a higher probability of being selected) in the round-robin scheduling. - IP Hash: Based on the source IP address of the request, use the Hash key to find the corresponding server from the statically allocated hash table. If the server is available and not overloaded, the request is sent to the server; otherwise, it returns nothing. |
Polling by Weight. |
| Backend protocol | The backend protocol refers to the protocol used between CLB and the backend service: - If you select HTTP as the backend protocol, you need to deploy HTTP service for the backend service. - If you select HTTPS as the backend protocol, you need to deploy HTTPS service for the backend service. Encryption and decryption of HTTPS service will consume more resources on the backend service. The backend service needs to be configured with a corresponding SSL certificate. Traditional accounts do not support selecting HTTPS as the backend forwarding protocol. |
HTTPS |
| Obtain Client IP address | Enabled by default. | Enabled |
| Gzip Compression | Enabled by default. | Enabled |
Select the HTTPS listener for which you want to create a forwarding rule, and click Add Rule to create a rule. The basic configuration is as shown below.
3. Health check
| Health Check Configuration | Description | Example |
|---|---|---|
| Health Check | Enable or disable health check. In the HTTPS listener, the CLB instance sends HTTPS requests to the specified server port to perform a health check. | Enable |
| Check Domain Name | Request a domain name. - The default is the access domain name. - Supported character sets include: az``0-9``.``-, length limit is 1-120.- Regular expressions are not currently supported. - When the user fills in the domain name as a wildcard domain name, it is necessary to specify a fixed domain name (non-regular) as the health check domain name. |
Use the default value (that is, www.example.com). |
| Check Directory | Request path. - The default is /, must start with /.- Supported character sets include: az``0-9``.``-, length limit is 1-120.- Regular expressions are not currently supported. - It is recommended to specify a fixed URL path (static page) for a health check. |
Use the default value (that is, /). |
| Detection Interval | - Interval between CLB health checks. - Configurable range: 5-300 seconds, default value is 5 seconds. |
5s |
| Unhealthy Threshold | - If the health check results received for n consecutive times (n is the filled value) are failed, it is identified as unhealthy, and the console displays as Abnormal. - Configurable range: 2-10 times, default value is 3 times. |
3 times |
| Health Threshold | - If the health check results received for n consecutive times (n is the filled value) are successful, it is identified as healthy, and the console displays as Healthy. - Configurable range: 2-10 times, default value is 3 times. |
3 times |
| HTTP Request Method | HTTP request method for the health check. Options: GET or HEAD. The default option is GET. - If the HEAD method is used, the server only returns the HTTP header information, which can reduce backend overhead and improve request efficiency. The corresponding backend service must support HEAD. - If the GET method is used, the backend service only needs to support GET. |
GET |
| HTTP Status Code Detection | When the status code is the selected status code, the backend server is considered alive, that is, the health check is normal. Optional: http_1xx, http_2xx, http_3xx, http_4xx, http_5xx. | Multiple selection: http_1xx, http_2xx, http_3xx, http_4xx |
The specific configuration of the health checks is shown in the figure below.
4. Session persistence
| Session Persistence Configuration | Description | Example |
|---|---|---|
| Session Affinity Status | Enable or disable session persistence. - After session persistence is enabled, the CLB listener will distribute access requests from the same client to the same backend server. - The HTTPS protocol is based on Cookie session persistence, and the CLB embeds Cookies into the client. - Weighted round-robin scheduling supports session persistence, while weighted least connections and IP Hash scheduling do not support session persistence. |
Enable |
| Session Held Time | Session hold time. - When the hold time is exceeded and there is no new request in the connection, the session will be automatically disconnected. - Configurable range 30-3,600 seconds. |
30s |
The specific configuration of session persistence is shown in the following figure.
Step 3: Bind the backend CVM
- On the Listener Management page, click the created listener, click the triangle on the left side to expand the domain name and URL path, select a specific URL path, and view the backend services bound to the path on the right side of the listener.
- Click Bind, select the backend server to be bound in the pop-up, and configure the service port and weight.
- Add port feature: In the Selected CVM box on the right, click Add Port to add multiple ports of the same CVM.
- Default port feature: Fill in Default Port first, then select the CVM. The port of each CVM is the default port.
After completing Step 1 to Step 3, the HTTPS listener rules are configured.
Step 4: Modify/delete listeners (optional)
If you need to modify or delete a created listener, on the Listener Management page, click the created listener/domain name/URL path and select modify or delete to complete the operation.