AWS Load Balancer Troubleshooting: 502, 503 and 504 Errors Explained
Learn how to troubleshoot AWS Application Load Balancer 502, 503 and 504 errors by checking target health, security groups, ports, health checks, timeouts, DNS and backend applications. URL Slug
AWS Application Load Balancers are commonly used to distribute HTTP and HTTPS traffic across multiple backend servers. When everything is configured correctly, the load balancer routes requests to healthy targets automatically.
But when the backend application is unavailable, unhealthy, incorrectly configured or too slow to respond, users may encounter errors such as 502 Bad Gateway, 503 Service Unavailable and 504 Gateway Timeout.
These errors can look similar from the user's perspective, but they usually point to different stages of the request path.
This guide explains what 502, 503 and 504 errors mean and provides a practical troubleshooting process for AWS Application Load Balancers.
Understanding the AWS Load Balancer Architecture
Before troubleshooting an error, understand how traffic moves through the architecture.
Internet
|
v
DNS / Route 53
|
v
Application Load Balancer
|
Target Group
|
+---------+---------+
| |
v v
EC2 #1 EC2 #2
| |
v v
Application Application
The ALB receives the request, evaluates its listener and routing rules, selects a target from the target group and forwards the request to the backend application.
502 vs 503 vs 504: What's the Difference?
| Error | Common Meaning | Where to Investigate |
|---|---|---|
| 502 | Bad response or connection problem between ALB and target | Backend application, port, protocol, connection |
| 503 | No suitable healthy target is available | Target health, target group, health checks |
| 504 | Backend target did not respond within the expected time | Application latency, networking, timeout configuration |
These are general troubleshooting patterns. The exact cause should be confirmed using target health information, ALB access logs, application logs and network configuration.
1. AWS ALB 502 Bad Gateway
A 502 response from an Application Load Balancer commonly indicates that the load balancer could not successfully complete communication with the target or received an invalid response from it.
Common causes include:
- Backend application is not running.
- Application is listening on the wrong port.
- Target is closing the connection unexpectedly.
- Backend protocol configuration is incorrect.
- Security group rules prevent communication.
- Target returns an invalid or unexpected response.
- Backend connection is reset.
Check Whether the Application Is Running
SSH into the EC2 instance and check the application process.
sudo systemctl status nginxIf your application is running through another service, replace the command with the appropriate service name.
Also check listening ports:
sudo ss -lntpFor example, if the target group expects port 8080 but the application is listening on port 3000, the ALB will not be able to communicate with the application correctly.
2. Check the Target Group Port
The target group's configured port must match the port on which the application is reachable.
ALB
|
| HTTP :80
v
Target Group
|
| HTTP :8080
v
EC2 Application
Verify the target group configuration in the AWS Console or using the AWS CLI.
aws elbv2 describe-target-groupsThen check registered targets:
aws elbv2 describe-target-health \
--target-group-arn <target-group-arn>3. Test the Backend Directly
One of the most useful troubleshooting techniques is testing the application directly from the target server or another host that can reach it.
curl -v http://127.0.0.1:8080/If this works locally but the ALB still returns errors, investigate the network path between the ALB and target.
If this fails locally, the problem is probably inside the application or the EC2 instance rather than the ALB itself.
4. AWS ALB 503 Service Unavailable
A 503 response commonly occurs when the load balancer does not have a suitable healthy target available to handle the request.
This makes target health one of the first things you should check.
aws elbv2 describe-target-health \
--target-group-arn <target-group-arn>Look for target states such as:
- healthy
- unhealthy
- initial
- draining
Common Reasons for 503
- All registered targets are unhealthy.
- No targets are registered.
- Targets are still starting their health checks.
- Targets have been deregistered.
- Health-check configuration does not match the application.
5. Check ALB Health Checks
Health checks determine whether a target is eligible to receive traffic.
A typical configuration might look like:
Protocol: HTTP
Port: traffic-port
Path: /health
Success Code: 200
If the application does not provide the configured health-check path or returns an unexpected status code, the target can become unhealthy.
Test the Health Endpoint
curl -i http://127.0.0.1:8080/healthConfirm that the endpoint responds as expected.
6. Health Check Path Is Wrong
Consider an application where the health endpoint is:
/api/healthbut the target group checks:
/healthThe application may be perfectly healthy while the ALB considers the target unhealthy.
Always test the exact configured health-check URL.
7. AWS ALB 504 Gateway Timeout
A 504 generally indicates that the load balancer did not receive a response from the target within the required time.
Common causes include:
- Backend application is taking too long.
- Database queries are slow.
- External API calls are hanging.
- Network connectivity to a dependency is failing.
- Application is overloaded.
- Connection handling is incorrect.
8. Find Slow Backend Requests
If an ALB returns 504 errors, check the application logs around the same timestamp.
sudo tail -f /var/log/application.logYou can also test the application directly:
time curl -v http://127.0.0.1:8080/apiIf the request itself takes a long time, investigate the application and its dependencies rather than changing the ALB configuration immediately.
9. Database Queries Causing 504 Errors
A common real-world scenario is:
User Request
|
v
ALB
|
v
Application
|
v
Database
|
X
Slow Query
The application may wait for the database, causing the request to exceed the load balancer's timeout.
Check:
- Database CPU utilization.
- Database connections.
- Slow queries.
- Locks.
- Connection pool exhaustion.
- Application timeout settings.
Increasing a timeout can hide the symptom without fixing the underlying performance problem.
10. Security Groups and ALB Connectivity
Security groups are a common cause of connectivity problems between an ALB and EC2 targets.
A common configuration is:
Internet
|
v
ALB Security Group
|
| TCP 8080
v
EC2 Security Group
|
v
Application
The EC2 security group should allow the required application port from the appropriate ALB security group.
Avoid unnecessarily opening the backend application port to the entire internet.
11. Check the EC2 Operating System Firewall
AWS security groups can be configured correctly while the operating system firewall still blocks traffic.
On Linux, check the firewall configuration:
sudo ufw statusDepending on the Linux distribution and firewall technology, you may also need to inspect nftables or iptables rules.
sudo iptables -L -nThe exact commands depend on how the server is configured.
12. Check Whether the Application Is Listening on the Correct Interface
An application can be running but still be unreachable from the ALB if it only listens on localhost.
For example:
127.0.0.1:8080means the service is listening only on the local loopback interface.
Check the listening address:
sudo ss -lntp | grep 8080The application must listen on an interface reachable through the EC2 network interface for remote ALB traffic.
13. Check ALB Listener Configuration
The listener receives incoming connections on a configured port and protocol.
For example:
HTTPS :443
|
v
Listener Rule
|
v
Target Group
|
v
EC2 :8080
Check that:
- The listener is running on the expected port.
- The listener protocol is correct.
- The listener has the expected routing rules.
- The rule forwards requests to the correct target group.
- Listener conditions match the requested hostname or path.
14. Check ALB Routing Rules
Application Load Balancers can route traffic based on host headers, paths, HTTP methods, headers and other conditions.
For example:
example.com/api/*
|
v
API Target Group
example.com/*
|
v
Web Target Group
Incorrect listener rules can send traffic to the wrong target group or leave a request without the expected forwarding action.
15. Check DNS Configuration
If users cannot reach the ALB at all, DNS may be part of the problem.
Test DNS resolution:
dig example.comVerify that the DNS record points to the intended load balancer or routing configuration.
Remember that DNS problems and ALB backend problems are different troubleshooting layers.
16. Check ALB Access Logs
ALB access logs can provide useful information about incoming requests and responses.
When troubleshooting an incident, correlate:
- Request timestamp
- Client IP
- Request path
- HTTP status
- Target information
- Response timing
Combining ALB logs with application logs is especially useful because it allows you to compare what the load balancer saw with what the backend application experienced.
17. Use CloudWatch Metrics
CloudWatch provides useful ALB metrics for troubleshooting.
Depending on your workload, monitor metrics such as:
- RequestCount
- HTTPCode_ELB_4XX_Count
- HTTPCode_ELB_5XX_Count
- HTTPCode_Target_4XX_Count
- HTTPCode_Target_5XX_Count
- TargetResponseTime
- HealthyHostCount
- UnHealthyHostCount
These metrics can help distinguish between errors generated at the load balancer layer and errors returned by backend targets.
18. ELB 5xx vs Target 5xx
This distinction is extremely useful when troubleshooting.
ALB
|
+---------+---------+
| |
ELB-generated Target-generated
errors errors
| |
v v
ALB problem Application
problem
If the load balancer itself is generating errors, investigate the ALB, listeners, target availability and connection behavior.
If the target is returning HTTP 5xx responses, investigate the application and backend services.
19. Test the Target From Inside the VPC
If possible, test the backend from another EC2 instance in the same VPC or an appropriate network location.
curl -v http://10.0.2.15:8080/healthIf this connection fails, investigate:
- Security groups
- Network ACLs
- Route tables
- Operating system firewall
- Application listener
20. Quick Troubleshooting Flow
ALB Error
|
+---------+---------+
| | |
502 503 504
| | |
v v v
Connection Target Slow /
/ Response Health Timeout
| | |
v v v
App / Port Health App /
/ Protocol Check Database
| | |
+---------+---------+
|
v
Security Groups
|
v
Network
|
v
Application Logs
|
v
CloudWatch / ALB Logs
21. AWS CLI Troubleshooting Commands
The following commands are useful when diagnosing ALB problems:
# List load balancers
aws elbv2 describe-load-balancers
# List target groups
aws elbv2 describe-target-groups
# Check target health
aws elbv2 describe-target-health \
--target-group-arn <target-group-arn>
# List listeners
aws elbv2 describe-listeners \
--load-balancer-arn <load-balancer-arn>
# List listener rules
aws elbv2 describe-rules \
--listener-arn <listener-arn>22. Practical 502 Troubleshooting Checklist
- Check whether the application is running.
- Verify the target port.
- Check the application listening address.
- Test the application locally with curl.
- Check the ALB-to-target security group rules.
- Check the operating system firewall.
- Verify the target protocol.
- Check application logs.
- Check ALB access logs.
23. Practical 503 Troubleshooting Checklist
- Check target group health.
- Verify that targets are registered.
- Check health-check path.
- Check health-check port.
- Check expected health-check response code.
- Verify application availability.
- Check security group rules.
- Check NACL configuration if relevant.
- Check whether targets are being deregistered.
24. Practical 504 Troubleshooting Checklist
- Check backend response time.
- Check application logs.
- Check database performance.
- Check external API dependencies.
- Check connection pools.
- Check application resource utilization.
- Check ALB timeout-related configuration.
- Determine whether increasing a timeout actually addresses the root cause.
Common Mistakes When Fixing ALB Errors
Restarting Everything Without Investigation
Restarting EC2 instances, applications or load balancers may temporarily hide symptoms without identifying the actual cause.
Opening Security Groups to 0.0.0.0/0
Broad security-group rules may make troubleshooting appear easier, but they can introduce unnecessary exposure. Restrict access to the appropriate source whenever possible.
Changing Timeouts Before Checking Application Performance
Increasing a timeout may reduce visible 504 errors while allowing slow database queries or application bottlenecks to remain unresolved.
Ignoring Health Checks
If the ALB cannot verify that targets are healthy, traffic may not be routed to them correctly.
Checking Only the ALB
The ALB is only one component in the request path. Always check the backend application, database, security groups and network configuration as well.
Recommended Production Architecture
Internet
|
v
Route 53
|
v
Application Load Balancer
|
+-------+-------+
| |
v v
Target Group Target Group
| |
+---+---+ +---+---+
| | | |
EC2 EC2 EC2 EC2
| | | |
+-------+-------+-------+
|
v
Database
|
v
CloudWatch / Logs
Final Thoughts
AWS ALB errors become much easier to troubleshoot when you understand where the request is failing.
502 usually requires investigation of the connection or response between the ALB and target. 503 should immediately make you check target availability and health checks. 504 points you toward slow backend processing, networking or dependencies that are taking too long to respond.
The most effective troubleshooting process is to work from the outside in:
DNS
↓
ALB Listener
↓
Listener Rules
↓
Target Group
↓
Target Health
↓
Security Groups
↓
Network
↓
Application Port
↓
Application
↓
Database / Dependencies
Instead of immediately changing configuration, collect evidence from target health, CloudWatch metrics, ALB logs, application logs and direct connectivity tests. This makes it much easier to identify the real root cause and apply a targeted fix.