Linden Consulting.
Architecture

ALB 502 Bad Gateway: Target-Group- und Health-Check-Fehlkonfigurationen beheben

2026-04-29 · 8 Min. Lesezeit

Ihr Monitoring-Dashboard leuchtet auf. Benutzer melden intermittierende Fehler. Sie prüfen die Application-Load-Balancer-Metriken und sehen einen Anstieg bei HTTPCode_ELB_502_Count. Der ALB gibt 502 Bad Gateway-Antworten an Ihre Benutzer zurück, was bedeutet, dass der Load Balancer die Anfrage erhalten hat, aber keine gültige Antwort von einem Backend-Target bekommen konnte.

Ein 502 von einem ALB ist grundlegend anders als ein 5xx von Ihrer Anwendung. Der ALB generiert den 502 selbst — er bedeutet, dass der ALB versucht hat, die Anfrage an ein Target weiterzuleiten, aber die Verbindung fehlschlug, ablief oder eine ungültige Antwort zurückkam. Ihr Anwendungscode kann völlig in Ordnung sein. Das Problem liegt in der Schicht zwischen dem ALB und Ihren Targets.

So diagnostizieren und beheben Sie ALB 502-Fehler systematisch.

Schritt 1: Die Fehlerquelle bestätigen

Unterscheiden Sie zunächst zwischen 502-Fehlern, die vom ALB generiert werden, und 5xx-Fehlern, die von Ihrer Anwendung zurückgegeben werden. Der ALB verfolgt diese in separaten CloudWatch-Metriken.

# ALB-generierte 502-Fehler vs. Target-generierte 5xx-Fehler prüfen
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name HTTPCode_ELB_502_Count \
  --dimensions Name=LoadBalancer,Value=app/my-alb/abc123 \
  --start-time 2026-04-28T00:00:00Z \
  --end-time 2026-04-29T12:00:00Z \
  --period 300 \
  --statistics Sum \
  --output table

# Mit Target-generierten Fehlern vergleichen
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name HTTPCode_Target_5XX_Count \
  --dimensions Name=LoadBalancer,Value=app/my-alb/abc123 \
  --start-time 2026-04-28T00:00:00Z \
  --end-time 2026-04-29T12:00:00Z \
  --period 300 \
  --statistics Sum \
  --output table

Wenn HTTPCode_ELB_502_Count hoch ist, aber HTTPCode_Target_5XX_Count niedrig oder null, generiert der ALB selbst die Fehler. Die Targets sind entweder nicht erreichbar, unhealthy oder geben fehlerhafte Antworten zurück.

Schritt 2: Target-Health prüfen

Die häufigste Einzelursache für ALB 502-Fehler ist das Fehlen gesunder Targets in der Target Group. Wenn jedes Target unhealthy ist, hat der ALB nirgendwohin, um Anfragen zu senden, und gibt 502 zurück.

# Health-Status aller Targets prüfen
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --query 'TargetHealthDescriptions[*].{
    Target: Target.Id,
    Port: Target.Port,
    Health: TargetHealth.State,
    Reason: TargetHealth.Reason,
    Description: TargetHealth.Description
  }' \
  --output table

Das Reason-Feld sagt Ihnen, warum ein Target unhealthy ist:

  • Elb.RegistrationInProgress — das Target wurde kürzlich registriert und Health Checks sind noch nicht abgeschlossen
  • Target.ResponseCodeMismatch — der Health Check erhielt eine HTTP-Antwort, aber nicht den erwarteten Statuscode
  • Target.Timeout — der Health Check lief ab, ohne eine Antwort zu erhalten
  • Target.FailedHealthChecks — das Target hat die erforderliche Anzahl aufeinanderfolgender Health Checks nicht bestanden

Ursache 1: Health-Check-Pfad gibt nicht 200 zurück

Der ALB-Health-Check sendet eine HTTP-Anfrage an einen bestimmten Pfad und erwartet einen bestimmten Antwortcode. Wenn Ihre Anwendung 301 (Redirect), 404 (Not Found) oder einen anderen nicht übereinstimmenden Code zurückgibt, schlägt der Health Check fehl.

# Aktuelle Health-Check-Konfiguration prüfen
aws elbv2 describe-target-groups \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --query 'TargetGroups[0].{
    HealthCheckPath: HealthCheckPath,
    HealthCheckPort: HealthCheckPort,
    HealthCheckProtocol: HealthCheckProtocol,
    Matcher: Matcher,
    HealthCheckIntervalSeconds: HealthCheckIntervalSeconds,
    HealthCheckTimeoutSeconds: HealthCheckTimeoutSeconds,
    HealthyThresholdCount: HealthyThresholdCount,
    UnhealthyThresholdCount: UnhealthyThresholdCount
  }'

Ein häufiger Fehler: Den Health-Check-Pfad auf / setzen, wenn die Anwendung / auf /login oder /dashboard umleitet. Der Health Check erhält einen 302-Redirect, der nicht mit dem erwarteten 200 übereinstimmt, und markiert das Target als unhealthy.

Die Lösung: Entweder den Health Check auf einen dedizierten Health-Endpoint richten:

aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --health-check-path "/health"

Oder den Matcher erweitern, um mehrere Antwortcodes zu akzeptieren:

aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --matcher '{"HttpCode": "200-399"}'

Ursache 2: Health-Check-Port-Mismatch

Standardmäßig führt der ALB Health Checks auf demselben Port durch, der für das Traffic-Routing verwendet wird. Wenn Sie aber den Health-Check-Port überschreiben und er nicht mit dem Port übereinstimmt, auf dem Ihre Anwendung tatsächlich hört, schlägt jeder Health Check fehl.

Dies ist besonders häufig bei ECS mit dynamischem Port-Mapping. Dem Container könnte Port 32768 zugewiesen sein, aber der Health Check ist für Port 8080 konfiguriert.

# Für ECS-Services den tatsächlich registrierten Port prüfen
aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --query 'TargetHealthDescriptions[*].{Id: Target.Id, Port: Target.Port}'

Die Lösung: Den Health-Check-Port auf traffic-port setzen (der Standard):

aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --health-check-port traffic-port

Ursache 3: Security Group blockiert ALB-zu-Target-Verkehr

Der ALB und die Targets benötigen Security Groups, die den Verkehr zwischen ihnen erlauben. Die Security Group des ALB braucht ausgehenden Zugriff auf die Targets, und die Security Group der Targets braucht eingehenden Zugriff vom ALB.

Dies ist eine der am häufigsten übersehenen Konfigurationen. Teams fügen den ALB einer öffentlichen Security Group und ihre Instances einer privaten Security Group hinzu, vergessen aber, die Inbound-Regel zu erstellen, die Verkehr von der Security Group des ALB erlaubt.

# Security Groups des ALB abrufen
aws elbv2 describe-load-balancers \
  --names my-alb \
  --query 'LoadBalancers[0].SecurityGroups'

# Security Groups der Targets abrufen
aws ec2 describe-instances \
  --instance-ids i-0abc123 \
  --query 'Reservations[0].Instances[0].SecurityGroups'

# Prüfen, ob die Target-Security-Group Verkehr von der ALB-Security-Group erlaubt
aws ec2 describe-security-groups \
  --group-ids sg-target123 \
  --query 'SecurityGroups[0].IpPermissions[*].{
    Protocol: IpProtocol,
    FromPort: FromPort,
    ToPort: ToPort,
    Sources: UserIdGroupPairs[*].GroupId
  }'

Die Lösung: Eine Inbound-Regel zur Target-Security-Group hinzufügen:

aws ec2 authorize-security-group-ingress \
  --group-id sg-target123 \
  --protocol tcp \
  --port 8080 \
  --source-group sg-alb456

Ursache 4: Target-Group-Protokoll-Mismatch

Wenn Ihre Target Group mit dem Protokoll HTTP konfiguriert ist, aber Ihre Anwendung nur auf HTTPS hört (oder umgekehrt), kann der ALB keine Verbindung zum Target aufbauen.

Das Symptom ist, dass der Health Check abläuft — der ALB sendet eine HTTP-Anfrage, aber das Target erwartet HTTPS und antwortet nie auf die Klartext-Anfrage.

# Target-Group-Protokoll prüfen
aws elbv2 describe-target-groups \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --query 'TargetGroups[0].{Protocol: Protocol, Port: Port}'

Die Lösung: Sie können das Protokoll einer bestehenden Target Group nicht ändern. Sie müssen eine neue Target Group mit dem korrekten Protokoll erstellen:

# Neue Target Group mit korrektem Protokoll erstellen
aws elbv2 create-target-group \
  --name my-tg-https \
  --protocol HTTPS \
  --port 443 \
  --vpc-id vpc-0abc123 \
  --health-check-protocol HTTPS \
  --health-check-path "/health" \
  --target-type instance

Ursache 5: Langsam startende Container bestehen Health Checks nicht

Während Deployments brauchen neue Container Zeit zum Starten, bevor sie auf Health Checks antworten können. Wenn der ALB sie als unhealthy markiert, bevor sie die Initialisierung abgeschlossen haben, erhalten Sie bei jedem Deployment einen Schub von 502-Fehlern.

Die Lösung: Slow-Start-Modus aktivieren. Dies gibt neuen Targets eine Aufwärmphase:

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --attributes Key=slow_start.duration_seconds,Value=120

Erhöhen Sie auch das Health-Check-Intervall und den Unhealthy-Threshold:

aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --health-check-interval-seconds 30 \
  --unhealthy-threshold-count 5 \
  --healthy-threshold-count 2 \
  --health-check-timeout-seconds 10

Mit diesen Einstellungen hat ein Target 150 Sekunden (5 Checks bei 30-Sekunden-Intervallen) bevor es als unhealthy markiert wird, plus eine 120-Sekunden-Slow-Start-Phase.

Ursache 6: Idle-Timeout überschritten

Der ALB hat ein Idle-Timeout (Standard 60 Sekunden). Wenn das Target länger als 60 Sekunden braucht, um zu antworten, schließt der ALB die Verbindung und gibt 502 zurück.

Dies betrifft typischerweise lang laufende API-Aufrufe, Datei-Uploads oder Report-Generierungs-Endpoints.

# ALB-Idle-Timeout prüfen
aws elbv2 describe-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789:loadbalancer/app/my-alb/abc123 \
  --query 'Attributes[?Key==`idle_timeout.timeout_seconds`]'

Die Lösung: Idle-Timeout erhöhen:

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789:loadbalancer/app/my-alb/abc123 \
  --attributes Key=idle_timeout.timeout_seconds,Value=300

Wichtig: Erhöhen Sie auch das Keep-Alive-Timeout Ihrer Anwendung auf einen höheren Wert als das ALB-Idle-Timeout. Wenn die Anwendung die Verbindung vor dem ALB schließt, sendet der ALB eine Anfrage an eine geschlossene Verbindung und gibt 502 zurück.

Ursache 7: Deregistration Delay während Deployments

Während Rolling Deployments werden alte Targets aus der Target Group deregistriert. Der ALB sendet weiterhin laufende Anfragen an diese Targets während der Deregistration-Delay-Periode (Standard 300 Sekunden). Wenn die alten Targets vor Ablauf des Deregistration Delay herunterfahren, erhalten diese laufenden Anfragen 502-Fehler.

Die Lösung: Stellen Sie sicher, dass Ihre Anwendung SIGTERM ordnungsgemäß behandelt. Setzen Sie den Deregistration Delay passend:

aws elbv2 modify-target-group-attributes \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/my-tg/abc123 \
  --attributes Key=deregistration_delay.timeout_seconds,Value=60

ALB-Access-Logs für tiefgehende Diagnose aktivieren

Wenn die obigen Prüfungen das Problem nicht aufdecken, aktivieren Sie ALB-Access-Logs:

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789:loadbalancer/app/my-alb/abc123 \
  --attributes Key=access_logs.s3.enabled,Value=true \
               Key=access_logs.s3.bucket,Value=my-alb-logs \
               Key=access_logs.s3.prefix,Value=alb

Die Access Logs enthalten Felder wie target_status_code, elb_status_code, target_processing_time und request_processing_time, die genau zeigen, wo der 502 generiert wird.

Die Diagnose-Checkliste

Wenn Sie ALB 502-Fehler sehen, arbeiten Sie diese Checkliste durch:

  1. (1 Min) HTTPCode_ELB_502_Count vs. HTTPCode_Target_5XX_Count prüfen, um die Fehlerquelle zu bestätigen
  2. (2 Min) describe-target-health ausführen, um zu prüfen, ob Targets gesund sind
  3. (2 Min) Health-Check-Konfiguration prüfen — Pfad, Port, Protokoll, Timeout, Threshold
  4. (3 Min) Security Groups verifizieren — ALB-zu-Target-Verkehr erlaubt
  5. (2 Min) Target-Group-Protokoll mit Anwendungsprotokoll abgleichen
  6. (1 Min) ALB-Idle-Timeout für lang laufende Anfragen prüfen
  7. (2 Min) Deregistration Delay und Slow Start für Deployment-bezogene 502er prüfen

Nach meiner Erfahrung werden ca. 40% der ALB 502-Fehler durch Health-Check-Fehlkonfigurationen verursacht, 25% durch Security-Group-Probleme, 20% durch Deployment-bezogene Probleme und 15% durch Timeout- oder Protokoll-Mismatches.

Robustes Load Balancing aufbauen

ALB 502-Fehler sind fast immer Konfigurationsprobleme, keine Infrastruktur-Ausfälle. Aber die richtige Konfiguration hinzubekommen — besonders über mehrere Umgebungen mit verschiedenen ECS-Services, Security Groups und Deployment-Strategien — erfordert sorgfältige Architektur.

Wir helfen Teams, Load-Balancing-Konfigurationen zu entwerfen, die Deployments graceful handhaben, korrekte Health-Check-Endpoints zu implementieren und Monitoring aufzubauen, das 502-Spitzen erkennt, bevor Benutzer sie bemerken. Kontaktieren Sie uns für eine kostenlose AWS-Beratung und lassen Sie uns Ihr ALB-Setup überprüfen.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen