When configuring listeners, you can enable health check to obtain the availability information of real servers. For more information on health check, see Health Check Overview.

Prerequisites

1. Create a CLB instance. For more information, see Creating CLB Instances.
2. Create a CLB listener.
   • To create a TCP listener, see more information in Configuring a TCP Listener.
   • To create a UDP listener, see more information in Configuring a UDP Listener.
   • To create a TCP SSL listener, see more information in Configuring a TCP SSL Listener.
   • To create an HTTP listener, see more information in Configuring an HTTP Listener.
   • To create an HTTPS listener, see more information in Configuring an HTTPS Listener.

TCP Listener

Layer-4 TCP listeners support three types of health checks, namely the layer-4 TCP health check, layer-7 HTTP health check, and custom protocol health check.

• TCP health checks are conducted with SYN packets, that is, TCP three-way handshakes are initiated to obtain the status information of backend CVM instances.
• HTTP health checks are conducted by sending HTTP requests to obtain the status information of backend CVM instances.
• Custom protocol health checks are conducted by customizing the input and output content of the application layer protocol to obtain the status information of backend CVM instances.

Configuring TCP health check

1. Configure a listener to the step of Health Check as instructed in Prerequisites.
2. In the step of Health Check, select TCP as the protocol.
   

   Parameter	Description
   Health check	It can be enabled or disabled. We recommend enabling it for automatic checks on backend CVM instances and removal of abnormal ports.
   Health check source IP	This is the source IP of health check packets, which is the CLB VIP by default. It can also be the 100.64 IP range, which can solve the container loopback problem in the TKE scenario. This feature is currently in beta stage. To try it out, submit a ticket.
   Protocol	TCP health checks will be conducted if TCP is selected.
   Port	It is optional. We recommend not specifying the port unless you need to check specific ones. The real server port will be checked if the port is not specified here.
   Show advanced options	For more information, see Advanced Options.

Configuring HTTP health check

1. Configure a listener to the step of Health Check as instructed in Prerequisites.
2. In the step of Health Check, select HTTP as the protocol.
   

   Parameter	Description
   Health check	It can be enabled or disabled. We recommend enabling it for automatic checks on backend CVM instances and removal of abnormal ports.
   Health check source IP	This is the source IP of health check packets, which is the CLB VIP by default. It can also be the 100.64 IP range, which can solve the container loopback problem in the TKE scenario. This feature is currently in beta stage. To try it out, submit a ticket.
   Protocol	HTTP health checks will be conducted if HTTP is selected.
   Port	It is optional. We recommend not specifying the port unless you need to check specific ones. The real server port will be checked if the port is not specified here.
   Check domain	Requirements on health check domain names: Length: 1 to 80 characters. It is the forwarding domain name by default. Regular expressions are not supported. If your forwarding domain name is a wildcard one, you need to specify a fixed (non-regular) domain name as the health check domain name. Supported characters: lowercase letters (a to z), digits (0 to 9), decimal points (.), and hyphens (-).
   Path	Requirements on health check paths: Length: 1 to 200 characters. `/` is the default value and should be the first character. Regular expressions are not supported. We recommend specifying a fixed URL (static webpage) for the health check. Supported characters: lowercase letters (a to z), uppercase letters (A to Z), digits (0 to 9), decimal points (.), hyphens (-), underscores (_), forward slashes (/), equal signs (=), and question marks (?).
   HTTP request method	HTTP request method of health checks. Options: GET (default method) and HEAD. If HEAD is selected, the server will only return the HTTP header information, which can reduce backend overheads and improve request efficiency. The real server must support HEAD. If GET is selected, the real server must support GET.
   HTTP version	HTTP version of the real server. If the version supported by the real server is HTTP 1.0, then the host field of the request does not need authentication, that is, the check domain does not need to be configured. If the version supported by the real server is HTTP 1.1, then the host field of the request needs authentication, that is, the check domain needs to be configured, or the error code 404 will be returned.
   Normal status code	If the status code is of the selected ones, the real server is considered as alive (healthy). Options: http_1xx, http_2xx, http_3xx, http_4xx, and http_5xx. You can select multiple ones.
   Show advanced options	For more information, see Advanced Options.

Configuring custom protocol health check

1. Configure a listener to the step of Health Check as instructed in Prerequisites.
2. In the step of Health Check, select Custom Protocol as the protocol.
   

   Parameter	Description
   Health check	It can be enabled or disabled. We recommend enabling it for automatic checks on backend CVM instances and removal of abnormal ports.
   Health check source IP	This is the source IP of health check packets, which is the CLB VIP by default. It can also be the 100.64 IP range, which can solve the container loopback problem in the TKE scenario. This feature is currently in beta stage. To try it out, submit a ticket.
   Protocol	Custom protocol health checks will be conducted if Custom Protocol is selected. This is applicable to non-HTTP protocols in TCP.
   Port	It is optional. We recommend not specifying the port unless you need to check specific ones. The real server port will be checked if the port is not specified here.
   Input format	Text and hexadecimal strings are supported. If Text is selected, the text will be converted into a binary string for sending requests and comparing returned results. If Hexadecimal is selected, the hexadecimal string will be converted into a binary string for sending requests and comparing returned results.
   Check request	This is the custom health check request content, which is required, such as `F13E0100000100000000000003777777047465737403636F6D0774656E63656E7403636F6D0000010001` for DNS service health check.
   Returned check result	When customizing the health check request, you must enter the returned health check result, such as F13E for DNS service health check.
   Show advanced options	For more information, see Advanced Options.

UDP Listener

UDP listeners support UDP health checks, which can be conducted by checking ports and running the Ping command.

Configuring UDP health check - port check

1. Configure a listener to the step of Health Check as instructed in Prerequisites.
2. In the step of Health Check, select Port as the protocol.
   

   Parameter	Description
   Health check	It can be enabled or disabled. We recommend enabling it for automatic checks on backend CVM instances and removal of abnormal ports.
   Health check source IP	This is the source IP of health check packets, which is the CLB VIP by default. It can also be the 100.64 IP range, which can solve the container loopback problem in the TKE scenario. This feature is currently in beta stage. To try it out, submit a ticket.
   Protocol	If Port is selected, UDP detection packets will be sent to the backend CVM instance via the VIP (i.e., the IP address used by a CLB instance to provide service to clients), and the IP of the backend CVM instance will be pinged to obtain the backend CVM instance status.
   Port	It is optional. We recommend not specifying the port unless you need to check specific ones. The real server port will be checked if the port is not specified here.
   Input format	Text and hexadecimal strings are supported. If Text is selected, the text will be converted into a binary string for sending requests and comparing returned results. If Hexadecimal is selected, the hexadecimal string will be converted into a binary string for sending requests and comparing returned results.
   Check request	This is the custom health check request content, such as `F13E0100000100000000000003777777047465737403636F6D0774656E63656E7403636F6D0000010001` for DNS service health check.
   Returned check result	When customizing the health check request, you must configure the returned health check result, such as F13E for DNS service health check.
   Show advanced options	For more information, see Advanced Options.

Configuring UDP health check - Ping command

1. Configure a listener to the step of Health Check as instructed in Prerequisites.
2. In the step of Health Check, select PING as the protocol.
   

   Parameter	Description
   Health check	It can be enabled or disabled. We recommend enabling it for automatic checks on backend CVM instances and removal of abnormal ports.
   Health check source IP	This is the source IP of health check packets, which is the CLB VIP by default. It can also be the 100.64 IP range, which can solve the container loopback problem in the TKE scenario. This feature is currently in beta stage. To try it out, submit a ticket.
   Protocol	If PING is selected, the IP of the backend CVM instance will be pinged to obtain the backend CVM instance status.
   Show advanced options	For more information, see Advanced Options.

TCP SSL Listener

Configuring TCP health check

1. Configure a listener to the step of Health Check as instructed in Prerequisites.
2. In the step of Health Check, select TCP as the protocol.
   

   Parameter	Description
   Health check	It can be enabled or disabled. We recommend enabling it for automatic checks on backend CVM instances and removal of abnormal ports.
   Health check source IP	This is the source IP of health check packets, which is the CLB VIP by default. It can also be the 100.64 IP range, which can solve the container loopback problem in the TKE scenario. This feature is currently in beta stage. To try it out, submit a ticket.
   Protocol	TCP health checks will be conducted if TCP is selected.
   Port	The health check port and listening port of TCP SSL listeners are the same.
   Show advanced options	For more information, see Advanced Options.

Configuring HTTP health check

1. Configure a listener to the step of Health Check as instructed in Prerequisites.
2. In the step of Health Check, select HTTP as the protocol.
   

   Parameter	Description
   Health check	It can be enabled or disabled. We recommend enabling it for automatic checks on backend CVM instances and removal of abnormal ports.
   Health check source IP	This is the source IP of health check packets, which is the CLB VIP by default. It can also be the 100.64 IP range, which can solve the container loopback problem in the TKE scenario. This feature is currently in beta stage. To try it out, submit a ticket.
   Protocol	HTTP health checks will be conducted if HTTP is selected.
   Port	The health check port and listening port of TCP SSL listeners are the same.
   Check domain	Requirements on health check domain names: Length: 1 to 80 characters. It is the forwarding domain name by default. Regular expressions are not supported. If your forwarding domain name is a wildcard one, you need to specify a fixed (non-regular) domain name as the health check domain name. Supported characters: lowercase letters (a to z), digits (0 to 9), decimal points (.), and hyphens (-).
   Path	Requirements on health check paths: Length: 1 to 200 characters. `/` is the default value and should be the first character. Regular expressions are not supported. We recommend specifying a fixed URL (static webpage) for the health check. Supported characters: lowercase letters (a to z), uppercase letters (A to Z), digits (0 to 9), decimal points (.), hyphens (-), underscores (_), forward slashes (/), equal signs (=), and question marks (?).
   HTTP request method	HTTP request method of health checks. Options: GET (default method) and HEAD. If HEAD is selected, the server will only return the HTTP header information, which can reduce backend overheads and improve request efficiency. The real server must support HEAD. If GET is selected, the real server must support GET.
   HTTP version	HTTP version of the real server. Only the HTTP 1.1 is supported. The real server needs to authenticate the host field of the request, that is, the check domain needs to be configured, or the error code 404 will be returned.
   Normal status code	If the status code is of the selected ones, the real server is considered as alive (healthy). Options: http_1xx, http_2xx, http_3xx, http_4xx, and http_5xx. You can select multiple ones.
   Show advanced options	For more information, see Advanced Options.

HTTP Listener

Configuring HTTP health check

1. Configure a listener to the step of Health Check as instructed in Prerequisites.
   

   Parameter	Description
   Health check	It can be enabled or disabled. We recommend enabling it for automatic checks on backend CVM instances and removal of abnormal ports.
   Health check source IP	This is the source IP of health check packets, which is the CLB VIP by default. It can also be the 100.64 IP range, which can solve the container loopback problem in the TKE scenario. This feature is currently in beta stage. To try it out, submit a ticket.
   Check domain	Requirements on health check domain names: Length: 1 to 80 characters. It is the forwarding domain name by default. Regular expressions are not supported. If your forwarding domain name is a wildcard one, you need to specify a fixed (non-regular) domain name as the health check domain name. Supported characters: lowercase letters (a to z), digits (0 to 9), decimal points (.), and hyphens (-).
   Path	The health check path can be set as the root directory of the real server or a specified URL. The requirements are as follows: Length: 1 to 200 characters. `/` is the default value and should be the first character. Regular expressions are not supported. We recommend specifying a fixed URL (static webpage) for the health check. Supported characters: lowercase letters (a to z), uppercase letters (A to Z), digits (0 to 9), decimal points (.), hyphens (-), underscores (_), forward slashes (/), equal signs (=), and question marks (?).
   Response timeout	Maximum response timeout for a health check. If a real server fails to respond within the timeout, it is considered as abnormal. Value range: 2-60 seconds.
   Check interval	Interval between two health checks. Value range: 5-300 seconds.
   Unhealthy threshold	If the health check result is failed for n (a customizable value) times, it is considered that the backend CVM instance is unhealthy, and the status displayed in the console is Abnormal. Value range: 2-10 times.
   Healthy threshold	If the health check result is successful for n (a customizable value) times, it is considered that the backend CVM instance is healthy, and the status displayed in the console is Healthy. Value range: 2-10 times.
   HTTP request method	HTTP request method of health checks. Options: GET (default method) and HEAD. If HEAD is selected, the server will only return the HTTP header information, which can reduce backend overheads and improve request efficiency. The real server must support HEAD. If GET is selected, the real server must support GET.
   Normal status code	If the status code is of the selected ones, the real server is considered as alive (healthy). Options: http_1xx, http_2xx, http_3xx, http_4xx, and http_5xx. You can select multiple ones.

HTTPS Listener

Note：

If HTTP is selected as the backend protocol of the HTTPS listener's forwarding rules, HTTP health checks will be conducted; if HTTPS is selected, HTTPS health checks will be conducted.

For the health check configuration of HTTPS listeners, see HTTP Listener.

Advanced Options

Relevant Documentation

• Health Check Overview
• Configuring Alarms