Introduction

Application Load Balancers reuse backend connections aggressively. If the target server closes an idle keepalive socket before ALB expects it, the next reused request can hit a dead connection and return a 502 even though both ALB and the target look healthy most of the time.

Symptoms

  • ALB returns intermittent 502 errors under normal traffic, not only during outages
  • Targets stay healthy in the target group while some requests still fail
  • Backend logs show closed keepalive connections or broken pipes
  • The issue became visible after changing idle timeout or reverse proxy settings

Common Causes

  • Backend keepalive timeout is shorter than ALB connection reuse expectations
  • A reverse proxy or app server closes idle sockets too aggressively
  • Idle timeout changes were applied on one layer but not the other
  • Connection reuse behavior differs between target types or server pools

Step-by-Step Fix

  1. 1.Confirm the 502 pattern and backend connection timing
  2. 2.Look for intermittent failures that correlate with reused idle connections rather than complete target outages.
bash
aws elbv2 describe-target-health --target-group-arn <tg-arn>
  1. 1.Review backend keepalive and idle timeout settings
  2. 2.Check the app server, Nginx, or Apache layer behind ALB for shorter keepalive values than the traffic pattern needs.
nginx
keepalive_timeout 75s;
  1. 1.Align timeouts so the backend stays open long enough
  2. 2.The backend should not close reusable idle sockets before ALB is done with them.
bash
aws elbv2 describe-load-balancers --load-balancer-arns <alb-arn>
  1. 1.Retest with fresh traffic after the timeout change
  2. 2.Watch the ALB 502 rate and backend logs after applying the new keepalive settings.
bash
curl -I https://example.com

Prevention

  • Review idle timeout and keepalive values as one end-to-end path, not per component
  • Document ALB timeout assumptions in backend reverse proxy config
  • Retest intermittent 502 patterns after proxy or app server tuning
  • Monitor ALB 5xx and backend broken-pipe errors together

Verification

After applying the fix, verify the exact symptom that made the incident visible instead of relying on one green log line. Re-run the command, request, deployment, or browser path that failed before the change and capture the new output for the incident record.

  • Confirm the original error message no longer appears in application, platform, or edge logs.
  • Check the affected dependency path from the client side and from the server side when both are available.
  • Watch the next scheduled job, deploy, cache refresh, or certificate renewal cycle so the fix survives the normal operating path.
  • Record the final configuration value, command output, and timestamp in the runbook for AWS ALB Returns 502 Because the Target Closed the Connection First.

Rollback

If the fix changes routing, credentials, certificates, state, cache behavior, or runtime configuration, keep a rollback path ready before applying it to production. Save the previous configuration, identify the owner of the affected service, and define the signal that will trigger rollback.

  1. 1.Restore the last known-good configuration or state reference if validation shows a wider blast radius.
  2. 2.Re-run the same diagnostic checks from the fix section to confirm the rollback returned the system to the previous behavior.
  3. 3.Leave a short note explaining why the attempted fix was reverted so the next responder does not repeat the same change.

Operational Notes

Use this guide as an incident workflow, not as a blind checklist. The safest order is to collect the current state, confirm the narrowest failing component, apply one focused change, and then re-test the same path that failed. Avoid combining unrelated fixes during AWS ALB Returns 502 Because the Target Closed the Connection First; otherwise the team will not know which change restored service or which change caused a later regression.

For production systems, capture command output before and after each change. Include timestamps, hostnames, environment names, account IDs, namespaces, certificate names, or configuration keys when they are relevant. These details make the guide useful during a future incident and help separate a real recurrence from a similar-looking but unrelated failure.

Escalate when the failing path crosses a boundary your team does not own, such as a managed cloud control plane, identity provider, external DNS service, payment gateway, or shared network appliance. Share the exact failing request, correlation ID, command output, and change window with the owning team. Keep customer-facing mitigation separate from root-cause repair: it is often safer to route around the broken dependency first, then schedule the permanent cleanup after traffic is stable.

  • [AWS troubleshooting: Fix IAM Permission Denied - Complete Tro](fix-iam-permission-denied)
  • [AWS cloud troubleshooting: AWS ACM Certificate Pending Validation Because the](aws-acm-certificate-pending-validation-wrong-route53-zone)
  • [AWS cloud troubleshooting: Fix AWS ALB CreateListener TargetGroupNotFound Err](aws-alb-createlistener-targetgroupnotfound)
  • [AWS cloud troubleshooting: Fix Aws Alb Lambda 502 Bad Gateway Issue in AWS](aws-alb-lambda-502-bad-gateway)
  • [AWS cloud troubleshooting: AWS ALB Target Group Returned 503 Service Unavaila](aws-alb-target-group-503-service-unavailable)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "AWS cloud troubleshooting: AWS ALB Returns 502 Because the Target Closed the ", "description": "Professional guide to fix AWS ALB Returns 502 Because the Target Closed the Connection First. AWS cloud troubleshooting with step-by-step solutions. Learn best practices and prevention strategies.", "url": "https://www.fixwikihub.com/aws-alb-502-target-closed-connection-keepalive-timeout-mismatch", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2026-04-10T05:18:00.000Z", "dateModified": "2026-04-10T05:18:00.000Z" } </script>