Menu
Elastic Load Balancing
Application Load Balancers

Troubleshoot Your Application Load Balancers

The following information can help you troubleshoot issues with your Application Load Balancer.

A registered target is not in service

If a target is taking longer than expected to enter the InService state, it might be failing health checks. Your target is not in service until it passes one health check. For more information, see Health Checks for Your Target Groups.

Verify that your instance is failing health checks and then check for the following:

A security group does not allow traffic

The security group associated with an instance must allow traffic from the load balancer using the health check port and health check protocol. You can add a rule to the instance security group to allow all traffic from the load balancer security group. Also, the security group for your load balancer must allow traffic to the instances.

A network access control list (ACL) does not allow traffic

The network ACL associated with the subnets for your instances must allow inbound traffic on the health check port and outbound traffic on the ephemeral ports (1024-65535). The network ACL associated with the subnets for your load balancer nodes must allow inbound traffic on the ephemeral ports and outbound traffic on the health check and ephemeral ports.

The ping path does not exist

Create a target page for the health check and specify its path as the ping path.

The connection times out

First, verify that you can connect to the target directly from within the network using the private IP address of the target and the health check protocol. If you can't connect, check whether the instance is over-utilized, and add more targets to your target group if it is too busy to respond. If you can connect, it is possible that the target page is not responding before the health check timeout period. Choose a simpler target page for the health check or adjust the health check settings.

The target did not return a successful response code

By default, the success code is 200, but you can optionally specify additional success codes when you configure health checks. Confirm the success codes that the load balancer is expecting and that your application is configured to return these codes on success.

Clients cannot connect to an Internet-facing load balancer

If the load balancer is not responding to requests, check for the following:

Your Internet-facing load balancer is attached to a private subnet

Verify that you specified public subnets for your load balancer. A public subnet has a route to the Internet Gateway for your virtual private cloud (VPC).

A security group or network ACL does not allow traffic

The security group for the load balancer and any network ACLs for the load balancer subnets must allow inbound traffic from the clients and outbound traffic to the clients on the listener ports.

The load balancer sends requests to unhealthy targets

If there is at least one healthy registered target for your load balancer, the load balancer routes requests only to its healthy registered targets. If there are only unhealthy registered targets, the load balancer routes requests to all registered targets.

The load balancer generates an HTTP error

The following HTTP errors are generated by the load balancer. The load balancer sends the HTTP code to the client, saves the request to the access log, and increments the HTTPCode_ELB_4XX_Count or HTTPCode_ELB_5XX_Count metric.

HTTP 400: Bad Request

Possible causes:

  • The client sent a malformed request that does not meet the HTTP specification.

  • The request header exceeded 16K per request line, 16K per single header, or 64K for the entire header.

HTTP 403: Forbidden

This response occurs if you have configured an AWS WAF web access control list (web ACL) to monitor requests to your Application Load Balancer and it blocks a request.

HTTP 460

This response occurs when the load balancer received a request from a client, but the client closed the connection with the load balancer before the idle timeout period elapses.

Check whether the client timeout period is greater than the idle timeout period for the load balancer. Ensure that your target provides a response to the client before the client timeout period elapses, or increase the client timeout period to match the load balancer idle timeout, if the client supports this.

HTTP 502: Bad Gateway

Possible causes:

  • The load balancer received a TCP RST from the target when attempting to establish a connection.

  • The target closed the connection with a TCP RST or a TCP FIN while the load balancer had an outstanding request to the target.

  • The target response is malformed or contains HTTP headers that are not valid.

  • A new target group was used but no targets have passed an initial health check yet. A target must pass one health check to be considered healthy.

HTTP 503: Service Unavailable

This response occurs when the target groups for the load balancer have no registered targets.

HTTP 504: Gateway Timeout

Possible causes:

  • The load balancer failed to establish a connection to the target before the connection timeout expired (10 seconds).

  • The load balancer established a connection to the target but the target did not respond before the idle timeout period elapses.

  • The network ACL for the subnet did not allow traffic from the targets to the load balancer nodes on the ephemeral ports (1024-65535).

  • The target returns a content-length header that is larger than the entity body. The load balancer timed out waiting for the missing bytes.

A target generates an HTTP error

The load balancer forwards valid HTTP responses from targets to the client, including HTTP errors. The HTTP errors generated by a target are recorded in the HTTPCode_Target_4XX_Count and HTTPCode_Target_5XX_Count metrics.