How to Fix AWS ALB-502
Quick Fix Summary
TL;DRCheck target group health status and verify backend instances are responding on the correct port.
AWS ALB returns a 502 Bad Gateway error when it cannot establish a successful connection to a registered target. This indicates the load balancer received an invalid response from the backend.
Diagnosis & Causes
Recovery Steps
Step 1: Diagnose Target Health in AWS Console
Immediately check the health status of all targets in your ALB's target group. Unhealthy targets are the primary cause.
# 1. Navigate to EC2 Console > Target Groups
# 2. Select your ALB's target group
# 3. Click the 'Targets' tab
# 4. Review the 'Status' column for any 'unhealthy' instancesStep 2: Verify Backend Connectivity and Logs
SSH into an unhealthy target and verify the application process is running, listening on the correct port, and check logs for crashes.
# Check if your app is listening on the target group port (e.g., 8080)
sudo netstat -tlnp | grep :8080
# Check application service status
sudo systemctl status your-application-service
# Tail application logs for errors
sudo tail -100f /var/log/your-app/error.logStep 3: Validate Network Security (Security Groups & NACLs)
Ensure the ALB's security group allows outbound traffic to the target instances, and the target's security group allows inbound traffic FROM the ALB.
# On TARGET Security Group, verify inbound rule exists:
Type: Custom TCP, Port: [Your App Port], Source: [ALB Security Group ID]
# Test connectivity from ALB subnet using VPC Reachability Analyzer or:
# (From a test instance in ALB subnet) telnet <target-private-ip> <app-port>Step 4: Adjust Timeouts and Enable Access Logs
If the application is slow, increase the ALB's idle timeout. Enable ALB Access Logs to see detailed 502 error reasons from the ALB's perspective.
# Modify Target Group Attributes (via CLI)
aws elbv2 modify-target-group-attributes --target-group-arn <TG_ARN> --attributes Key=deregistration_delay.timeout_seconds,Value=60
# Enable Access Logs (Console: ALB > Attributes > Edit)
aws elbv2 modify-load-balancer-attributes --load-balancer-arn <ALB_ARN> --attributes Key=access_logs.s3.enabled,Value=true Key=access_logs.s3.bucket,Value=your-log-bucket Key=access_logs.s3.prefix,Value=ALBArchitect's Pro Tip
"For containerized targets (ECS/EKS), a 502 often means the task failed its health check and was terminated. Check the 'Stopped Tasks' tab in ECS for the exit code, which points to the root cause."
Frequently Asked Questions
My targets show as healthy but I still get 502 errors. Why?
This is often a race condition or application-level issue. The health check passed, but the application crashed or timed out *during* the actual request. Enable ALB Access Logs and check the `error_reason` field (e.g., 'backend_connection_error'). Also, verify your application's keep-alive settings aren't conflicting with the ALB's idle timeout.
What's the difference between an ALB 502 and an NLB 502?
An ALB 502 originates at the ALB itself (Layer 7), meaning it received a TCP RST, timeout, or invalid HTTP response from the target. An NLB 502 is a TCP reset sent to the client because the NLB (Layer 4) could not establish a connection to the target, often due to security groups or a non-listening port.