Configure and manage CLB health checks - Server Load Balancer

When backend servers fail, Classic Load Balancer (CLB) needs a way to detect the failure and stop sending traffic to them. Health checks solve this: CLB periodically probes each backend server, removes unhealthy ones from the server group, and re-adds them when they recover. This keeps your application available even when individual servers go down.

Prerequisites

Before you configure health checks, make sure that:

The relevant services are deployed and running on your backend servers.
The service is listening on the expected port.

Usage notes

The listener protocol determines which health check protocols you can use:

Listener protocol	Supported health check protocols
TCP	TCP, HTTP
UDP	TCP, UDP, HTTP
HTTP or HTTPS	HTTP

Configure a health check

You can configure health checks as part of the listener setup. The default health check settings work for most scenarios.

Log on to the CLB console.
In the top menu bar, select the region of your instance.
Find the target instance and click its instance ID.
Click the Listeners tab, and then click Add Listener or click Modify in the Actions column of an existing listener.
Follow the configuration wizard until you reach the Health Check page. Health checks are enabled by default.
Click Modify and configure the health check parameters described in the following table.
Click Next to complete the listener configuration.

Parameter	Applies to	Description
Health check protocol	All	Protocol used for probes. TCP sends a SYN packet to check port availability. UDP sends a UDP packet and checks for a response. HTTP sends a HEAD or GET request to verify application health.
Health check method	HTTP	Request method: HEAD (default) or GET. Use GET if the server does not support HEAD. GET responses longer than 8 KB are truncated, but this does not affect the result.
Health check port	All	Port that CLB probes. Default: the backend server port. If servers in the group use different ports, leave this blank. CLB uses each server's own port.
Health check path	HTTP	URL path for HTTP health checks. Default: `/`. Specify a custom path if your health check endpoint is not the root. Use a static page when possible.
Health check domain name(Optional)	HTTP	Value added to the `Host` header in health check requests. If left blank, the `Host` header is omitted. Configure this if your application validates the `Host` header, otherwise health checks may fail. When performing a health check, CLB ignores forwarding rules and checks the path that is configured for the listener. By default, the root path is used. If your backend service responds differently based on the request path, health checks may fail if they use the default path or a mismatched path. You can configure the health check path in the forwarding rules of the listener as required.
Health Check Status Codes	HTTP	HTTP status codes that indicate a healthy backend. Default: `http_2xx` and `http_3xx`. Options also include `http_4xx` and `http_5xx`. Including 4XX or 5XX codes can delay removal of faulty instances. For example, if you accept `http_5xx`, a server returning 500 is still considered healthy. Only add 4XX/5XX after careful evaluation. Warning Adding 4xx or 5xx codes to the list of healthy status codes can prevent the timely removal of genuinely faulty instances. For example, if a backend server returns a 500 Internal Server Error and you have configured http_5xx as a healthy status code, the unhealthy instance will still be considered healthy and continue to receive traffic. Use this configuration only after a thorough evaluation. We recommend that you prioritize fixing backend services to return correct 2xx or 3xx status codes. Common scenarios that cause 4xx status codes: 404 error: The health check path does not exist, the backend service is not correctly deployed, there are domain name binding issues, or the HEAD method is not supported. 403 error: The backend service denies access, there are IP-based access restrictions, or permission verification fails. 400 error: The Host header is missing, the HTTP protocol version is incompatible, or there are request format issues.
Health check response timeout	All	Maximum time (in seconds) to wait for a health check response. If the backend server does not respond in time, the check fails.
Health check interval	All	Time (in seconds) between consecutive checks. Each CLB node checks independently, so backend servers may observe probes at irregular intervals.
Healthy threshold	All	Number of consecutive successful checks before an unhealthy server is marked healthy.
Unhealthy threshold	All	Number of consecutive failed checks before a healthy server is marked unhealthy.
Health check request	UDP	Request payload sent during UDP health checks (for example, `youraccountID`).
Health Check Result	UDP	Expected response payload (for example, `slb123`). Implement matching logic on your backend — when it receives the request payload, it returns the expected response. This maximizes UDP health check reliability.

View health check status

Log on to the CLB console.
In the top menu bar, select the region of your instance.
Find the target instance and click its instance ID.
Click the Listener tab to see health check status for each listener.

Status	Description
Initializing	The list of backend servers for health checks is being initialized.
Normal	All backend servers passed health checks.
Abnormal	One or more backend servers failed health checks.
Disabled	Health checks are turned off for this listener.

5. Click Abnormal or Initializing to view details, including the affected listener, server group, server IP and port, and failure reason.

Disable health checks

Important

Disabling health checks means CLB cannot detect backend failures. Traffic continues to flow to all servers, including unhealthy ones, which can cause partial service outages. Instead of disabling health checks, consider reducing the check frequency or increasing the interval.

Log on to the CLB console.
In the top menu bar, select the region of your instance.
Find the target instance and click its instance ID.
Click the Listener tab, and then click Add Listener or click Modify in the Actions column of the target listener.
Follow the configuration wizard until you reach the Health Check page.
Turn off the Health Check toggle, click Next, and confirm.

Health check source IP range

CLB probes backend servers from the 100.64.0.0/10 IP range. All health check traffic originates from this range.

Make sure this range is allowed in:

Security group inbound rules
iptables or firewall rules
Network ACLs

If this traffic is blocked, CLB marks the backend servers as unhealthy and stops forwarding requests to them — even when the servers are running normally.

Health check best practices

Use a dedicated health check endpoint. Create an endpoint such as /health that returns HTTP 200. Avoid using business paths (for example, /) because they may return 4XX due to authentication, missing resources, or other conditions.
Fix backend issues instead of broadening status codes. When health checks fail, investigate the root cause. Accepting 4XX or 5XX as healthy keeps faulty servers in the rotation.
Configure the health check domain. If your application validates the Host header, set the health check domain so that CLB includes the correct Host value.
Allow the CLB health check IP range. Make sure 100.64.0.0/10 is not blocked by iptables, security groups, or network ACLs on your backend servers.
Use static pages for HTTP health checks. Static pages respond faster and more predictably, reducing false negatives.

Server Load Balancer:Configure and manage CLB health checks