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

Resolution

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

Connectivity issues between the load balancer and the backend

• Make sure that 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 virtual private cloud (VPC).
• The network access control list (network ACL) for the subnet with the load balancer and backend must allow health check traffic. To check the network ACL rules, see Network ACLs for load balancers in a VPC.
• Instance-level or operating system-level firewalls on the backend must allow health check traffic in and out.
• The memory and CPU utilization for the backend instance must be within acceptable limits. If your memory or CPU utilization is too high, then add more backends or upgrade the backends to a larger instance type.
• Additional resources must allow health check traffic. The backend might forward the health check request to an additional resource. If the additional dependency fails to respond or takes too long to respond, then the health check times out and fails. Be sure that the additional resource responds to the health check requests.

Configuration issues with your application

• Make sure that the application is running. For example, if you're running Apache on a Linux instance, then use the sudo service httpd status command to confirm that Apache is running.
• The application must be 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's 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 must be 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. They also set the user agent to ELB-HealthChecker/1.0. If the backend responds only to requests with a custom host header or a user agent, then the health check request fails.
• The application must be listening on the primary network interface of the backend. Classic Load Balancers connect to the primary network interface of the backend instance. Make sure that the application is listening on the primary network interface of the backend instance. This allows the backend to send a response for the health check requests.

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

• The ping path must be valid. If you don't configure the file that's specified in the ping path on the backend, then the backend might respond with 404 Not Found. This causes the health check to fail.
  Note: The default value for the ping path is /index.html. If you don't have an index.html file on the backend, then create one. Or, you can change the value of the ping path to a file name on the backend.
• You didn't correctly configure redirection on the backend. An incorrectly configured redirection can result in a 301 or 302 response code and 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 fail. You must change the health check to HTTPS and the health check port to 443. 
  Note: You can simulate the health check request that the load balancer sends. Use the following curl command from an instance in the subnet that's associated with the load balancer:

  curl -Ivk http[s]://<private-IP-address-of-the-backend-instance>:<health-check-port>/<health-check-target-page>

Problems with SSL

• All protocols and ciphers must match. For HTTPS or SSL health checks, the load balancer and the backend must use the same protocol and cipher. Packet captures that are taken on the backend instance show the ciphers and protocol that are supported on the load balancer. This is found in the client hello that the load balancer sends. The registered backend instance must support one or more matching ciphers and a protocol that the load balancer sends.
• The Load balancer doesn't send the Server Name Indication (SNI) header when it performs a health check. For example, the health check is HTTPS/SSL. If the backend instance is configured to respond to the SSL handshake based on the specific SNI information, then the SSL handshake fails. This is because the server sends an RST after the client hello. Configure the backend server to respond regardless of the SNI. Or, you can use TCP health check instead.

Related information

Registered instances for your Classic Load Balancer