How do I troubleshoot and fix failing health checks for Classic Load Balancers?

Short description

Elastic Load Balancing (ELB) supports Application Load Balancers, Network Load Balancers, and Classic Load Balancers. Instances running on Classic Load Balancers might fail health checks for the following reasons:

• Connectivity issues between the load balancer and backend
• Configuration issues with the application
• Not receiving a "200 OK" response from the backend for the health check request
• Problems with SSL, which are causing HTTPS or SSL health checks to fail

Resolution

To troubleshoot and resolve health check related issues, check the following:

Resolve potential connectivity issues between your load balancer and your backend

Be sure that the following are true:

• The backend allows health check traffic. To check your security group rules, see Recommended rules for load balancer security groups. For the backend instance, see Security groups for instances in a VPC.
• The network access control list (ACL) for the subnet with the load balancer or backend allows health check traffic. To check the ACL rules for the subnet with the load balancer and backend, see Network ACLs for load balancers in a VPC.
• Instance-level or OS-level firewalls on the backend allow health check traffic. Be sure that the instance or OS level firewalls on the backend are allowing the health check traffic in and out.
• The resources of the backend instance are not over-utilized. Be sure that memory and CPU utilization are within acceptable limits. If your memory or CPU utilization is too high, add more backends or upgrade the backends to a larger instance type.
• Any additional resources are allowing health check traffic. The health check request might be forwarded to an additional resource by the backend. If the additional dependency fails to respond or takes too long to respond, the health check times out and fails. Be sure that the additional resource is responding to the health check requests.

Resolve potential configuration issues with your application

• The application is running. For example, if you are running Apache on a Linux instance, use the sudo service httpd status command to confirm that Apache is running.
• The application is listening on the health check port. To confirm that the server is in a listening state for the health check port, run the netstat -ant command on the server. Check the application configuration port to verify that it is running. To simulate a TCP connection between the load balancer and backend, run the **telnet <backend private IP> <health-check port>**command on the instance. If the output is "Connected," then the backend is listening on the health check port.
• The application is set to respond to requests with a custom host header. For HTTP and HTTPS health checks, Classic Load Balancers set the header to the private IP address with the primary network interface of the backend, and the user agent to "ELB-HealthChecker/1.0". If the backend only responds to requests with a custom host header or a user agent, then the health check request fails.
• The application is listening on the primary network interface of the backend. Classic Load Balancers connect to the primary network interface of the backend instance. Be sure that the application is listening on the primary network interface of the backend instance, allowing the backend to send a response for the health check requests.

Confirm a "200 OK" response from the backend to a health check request

Be sure that the following are true:

• The ping path is valid. If the file specified in the ping path is not configured on the backend, the backend might respond with a "404 Not Found" response code, and the health check will fail. Note: The default value for the ping path is /index.html. If you do not have an index.html file on the backend, create one, or change the value of the ping path to a file name on the backend.
• Redirection is not configured on the backend. Redirection configured on the backend can result in a 301 or 302 response code, resulting in failed health checks. For example, if you have a redirection from HTTP:80 to HTTPS:443 on the backend, then HTTP health checks on port 80 will fail, unless you change the health check to HTTPS and health check port to 443. Note: You can simulate the health check request sent by the load balancer using the curl -Ivk http[s]://<private-IP-address-of-the-backend-instance>:<health-check-port>/<health-check-target-page> command from an instance in the subnet that is associated with the load balancer.

Resolve any SSL-related issues

Be sure that the following are true:

• All protocols and ciphers match. For HTTPS or SSL health checks, the load balancer and the backend should use the same protocol and cipher. Packet captures taken on the backend instance show the ciphers and protocol supported on the load balancer in the client hello sent by the load balancer. The registered backend instance should support one or more matching ciphers and a protocol sent by the load balancer.
• Server Name Indication (SNI) is not enabled on the backend server. If the health check is HTTPS/SSL and SNI is enabled on the backend instance, the load balancer and backend can't establish the SSL handshake. This is because the backend server sends an RST after the client hello. Disable SNI, or use TCP health checks instead.

Related information

Registered instances for your Classic Load Balancer