Server Load Balancer:Configure and manage CLB health checks

Prerequisites

Before you configure health checks, make sure that the relevant services are deployed on your backend servers.

Limits

The listener protocol and health check protocol must comply with the following rules:

• TCP listeners support only TCP or HTTP health check protocols.

• UDP listeners support TCP, UDP, or HTTP health check protocols.

• HTTP and HTTPS listeners support only the HTTP health check protocol.

Configure health checks

You can configure health checks when you add a listener. In most cases, the default health check settings are sufficient.

1. Log on to the CLB console.

2. In the top menu bar, select the region where your instance is located.

3. On the Instances page, locate the target instance and click its instance ID.

4. On the instance details page, click the Listener tab. Click Add Listener, or click Modify Listener in the Actions column of the target listener.

5. Follow the configuration wizard to the Health Check step. Health checks are enabled by default.

6. Click Advanced Settings, and then click Edit on the right to configure the health check settings.

   Health Check Configuration	Description
   Health Check Protocol	Select a protocol for health checks. TCP health checks operate at the network layer by sending SYN handshake messages to verify whether the server port is active. UDP health checks use UDP messages to obtain status information. HTTP health checks send HEAD or GET requests to simulate browser access and verify whether the server application is healthy.
   Health Check Method (Supported only for the HTTP health check protocol)	You can select the HEAD or GET method. By default, the HEAD method is used. Note If the HEAD method is not supported or is disabled, use the GET method instead. If you use the GET method, responses that are longer than 8 KB are truncated. This does not affect the health check result.
   Health Check Port	The port that is used for health checks on backend servers. By default, CLB uses the port of each backend server. Note If the backend servers in a server group use different ports, do not specify a health check port. In this case, CLB uses the port of each backend server for health checks.
   Health Check Path (Supported only for the HTTP health check protocol)	By default, CLB sends an HTTP request to the default index page of your application for health checks. If the page that is used for health checks is not the default index page of your application, specify the exact path. We recommend that you use a static page for health checks.
   Health Check Domain Name (Optional) (Supported only for the HTTP health check protocol)	When you configure a health check domain, CLB sets the Host field in the request header to the domain. If no domain is configured, the Host field is omitted. Some application servers validate the Host field. If a domain is not configured, requests may be rejected, which can cause health check failures. If your server validates the Host field, you must configure a health check domain to ensure that health checks are successful. Note The load balancer's health check ignores forwarding rules and uses the listener's configured health check path (the root path by default). If your backend service requires a specific path, a health check to the default path will fail. To resolve this, configure a specific health check path in the forwarding rule.
   Healthy Status Codes (Supported only for the HTTP health check protocol)	Select the HTTP status codes that indicate a healthy backend server. The default values are http_2xx and http_3xx. You can select http_2xx, http_3xx, http_4xx, or http_5xx. By default, CLB considers only HTTP 2xx and 3xx status codes as healthy. If your backend server returns a 4xx status code, such as 400, 403, or 404, or a 5xx status code, such as 500, 502, or 503, the health check fails. Then, CLB marks the backend server as abnormal and stops forwarding traffic to the server. Warning If you accept 4xx or 5xx status codes as healthy, faulty instances may not be promptly removed from the backend server pool. For example, if a backend server returns a 500 error and you have configured http_5xx as a normal status code, CLB continues to route traffic to the faulty instance. Use this setting only after careful evaluation. We recommend that you make sure your backend server returns a 2xx or 3xx status code whenever possible. Common causes of 4xx errors: 404 error: The health check path does not exist, the backend service is not correctly deployed, a domain binding issue exists, or the HEAD method is not supported. 403 error: The backend server denies access, IP address-based restrictions are in place, or permission verification fails. 400 error: The Host header is missing, the HTTP version is incompatible, or the request is malformed.
   Health Check Response Timeout	The maximum period of time to wait for a response to a health check. If a backend server does not return a response within the specified timeout period, the health check fails.
   Health Check Interval	The interval at which health checks are performed. All nodes in the CLB cluster independently perform health checks at the specified interval. Because the health checks from different nodes are not synchronized, the health check requests that a backend server receives may not be evenly spaced. By default, HTTP health checks use the HEAD method. HEAD requests return only the HTTP status code and headers, not the full page content. Therefore, each health check imposes a minimal load on backend servers. If you shorten the interval, the number of health check requests increases. However, the overhead is typically negligible compared with normal service traffic.
   Healthy Threshold	The number of consecutive successful health checks required for a failed Elastic Compute Service to be considered healthy.
   Unhealthy Threshold	The number of consecutive failed health checks after which an Elastic Compute Service instance is considered unhealthy.
   Health Check Request and Health Check Result (Supported only for the UDP health check protocol)	When you configure health checks for a UDP listener, enter the request content (for example, youraccountID) in the Health Check Request field and the expected response (for example, slb123) in the Health Check Result field. Also, add logic to your backend application to handle health check responses, such as configuring it to respond with slb123 to requests that contain youraccountID. CLB considers a health check successful only if it receives the correct response. This method maximizes the reliability of UDP health checks.

7. Click Next until the listener is configured.

View health check status

1. Log on to the CLB console.

2. In the top menu bar, select the region where your instance is located.

3. On the Instances page, find the target instance and click its instance ID.

4. On the instance details page, click the Listener tab to view the health check status of each listener.

   The health check status can be one of the following:

   • Initializing: The backend server list is being initialized for health checks.

   • Normal: All backend servers are healthy.

   • Abnormal: One or more backend servers are abnormal.

   • Disabled: Health checks are not enabled.

5. Click Error or Initializing next to a listener to view details, including the affected listener or forwarding rule, server group, ECS instance and port, health status, and failure reason.

Disable health checks

You can disable health checks. However, if a backend ECS instance becomes abnormal after you disable health checks, CLB continues to route requests to the instance. This causes partial service unavailability. Therefore, we recommend that you do not disable health checks.

1. Log on to the CLB console.

2. In the top menu bar, select the region where your instance is located.

3. On the Instances page, find the target instance and click its instance ID.

4. On the instance details page, click the Listener tab. Click Add Listener, or click Modify Listener in the Actions column of the target listener.

5. Follow the configuration wizard until you reach the Health Check step.

6. Turn off the health check toggle, click Next, and then confirm the changes.

Health check best practices

To ensure accurate and reliable health checks, we recommend that you follow these best practices:

• Create a dedicated health check endpoint: Create a dedicated health check endpoint on your backend server, such as /health, that always returns an HTTP 200 status code. Avoid using business paths, such as /, for health checks because they may return 4xx status codes due to permission checks or missing resources.

• Prioritize fixing backend issues: If health checks return unexpected status codes, first diagnose and fix the backend service issues to make sure that the health check path returns a 2xx or 3xx status code. Do not simply relax the criteria for normal status codes.

• Simulate health checks using curl: When you troubleshoot issues, you can log on to a backend server and run the following command to simulate CLB health checks:

  curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://127.0.0.1:80/health_path

  In this command, HEAD is the health check method, your-domain.com is the health check domain, and /health_path is the health check path. If a domain is not configured, omit the -H parameter.

• Make sure that the CIDR blocks of CLB are not blocked: CLB uses the 100.64.0.0/10 CIDR block to communicate with backend servers for health checks. Make sure that this CIDR block is not blocked by iptables or other firewall rules.

References

• If you are not familiar with the health check mechanism of CLB, see CLB health checks.

• If you encounter issues with CLB health checks, see CLB health check FAQ for troubleshooting.

• You can use the health check log feature of CLB to analyze health check logs of servers. For more information, see Store and download health check logs.