HTTP 502/503/504: Upstream Down, Timeout oder Misroute unterscheiden

HTTP-Fehlercodes werden im Incident-Alltag oft als „App down“ abgetan, dabei sind sie ein sehr präzises Signal – wenn man sie richtig liest. Besonders die Kombination HTTP 502/503/504 sorgt in NOC- und On-Call-Teams regelmäßig für Verwirrung: Ist der Upstream wirklich ausgefallen, ist nur der Load Balancer überlastet, oder werden Requests schlicht falsch geroutet? Die Unterscheidung ist entscheidend, weil sie bestimmt, welches Owner-Team Sie brauchen (Netzwerk, Plattform, SRE, Applikation, CDN/WAF) und welche Mitigation in Minuten wirkt. 502 (Bad Gateway) deutet häufig auf ungültige Antworten oder Verbindungsabbrüche zwischen Proxy und Upstream hin, 503 (Service Unavailable) signalisiert meist geplante oder ungeplante Nichtverfügbarkeit – oft durch Health-Checks, Überlastschutz oder Maintenance –, und 504 (Gateway Timeout) weist auf ausbleibende Antworten innerhalb eines definierten Zeitfensters hin. In der Praxis werden diese Codes jedoch von Gateways, Reverse Proxies, CDNs und Service-Meshes erzeugt, nicht unbedingt von der Anwendung selbst. Genau dort entstehen Missverständnisse: Ein 504 kann ein L7-Timeout sein, aber auch ein L3/L4-Problem, ein falsches Routing, ein Firewall-Drop oder ein überlasteter Upstream, der zwar erreichbar ist, aber zu langsam antwortet. Dieser Artikel liefert ein operatives Vorgehen, das Sie mit Minimaldaten und klaren Checks zuverlässig zur richtigen Diagnose führt – ohne Rätselraten und ohne „wir probieren mal Neustart“ als Standardstrategie.

Wo entstehen 502/503/504 eigentlich? Der wichtigste Kontext im NOC

Bevor Sie Fehlercodes interpretieren, müssen Sie wissen, wer sie generiert. In modernen Architekturen liegt zwischen Client und Anwendung oft eine Kette aus Komponenten, die eigene Timeouts, Health-Checks und Fehlermappings haben.

• Client (Browser, App, SDK): kann eigene Timeout-/Retry-Logik haben, sieht aber nur den HTTP-Code.
• CDN/WAF: terminiert TLS, cached, routet, blockt und kann 5xx selbst erzeugen.
• Load Balancer / Reverse Proxy (z. B. NGINX, Envoy, HAProxy): verbindet zum Upstream und liefert bei Fehlern 502/503/504.
• Service Mesh: Sidecars agieren als L7-Proxies mit eigenen Retries/Timeouts.
• Upstream (API, App-Server): liefert oft eigene 5xx (500/502/503), kann aber auch „gesund“ wirken, wenn der Proxy gar nicht mehr bis zur App kommt.

Operative Konsequenz: Ein 502/503/504 ist häufig ein Signal über die Strecke zwischen Proxy und Upstream – nicht zwingend über die Business-Logik. Deshalb ist der erste Schritt immer: Identifizieren, welches Gateway den Code zurückgibt (Header, Server-Signatur, Logs, Request-ID).

Quick-Triage: So unterscheiden Sie Upstream Down, Timeout und Misroute in 5 Minuten

Wenn es brennt, brauchen Sie eine kurze Entscheidungskette. Diese Checks sind bewusst so gewählt, dass sie ohne Spezialtools funktionieren und dennoch zuverlässig trennen.

• 1) Ist der Fehlercode vom Edge oder vom internen Proxy? Prüfen Sie Response-Header wie Server, Via, CDN-spezifische Header sowie eine Request-ID-Kette. Unterschiedliche Pfade liefern oft unterschiedliche Codes.
• 2) Tritt es für alle Endpoints auf oder nur für einzelne Routen? Wenn nur bestimmte Pfade betroffen sind, ist Misroute/Upstream-Spezifik wahrscheinlicher als globaler Ausfall.
• 3) Gibt es eine Korrelation zu Deployments/Config-Changes? 503 nach Change spricht oft für Health-Check- oder Routing-Fehler, 502 nach TLS/Cert-Change häufig für Upstream-Handshake-Probleme.
• 4) Ist der Upstream aus Sicht des Proxys erreichbar? Interne Synthetics aus derselben Zone/VPC/Node-Pool sind aussagekräftiger als Tests „von außen“.
• 5) Sehen Sie Timeouts oder Connection Errors in Proxy-Metriken? Upstream connect errors → 502; Upstream response timeouts → 504; keine Upstreams verfügbar → 503.

Schon diese fünf Punkte liefern in vielen Incidents eine klare Richtung und verhindern, dass Teams in der falschen Schicht debuggen.

HTTP 502: Bad Gateway – typische Ursachen, Signale und Beweise

HTTP 502 bedeutet im Kern: Das Gateway/der Proxy hat eine ungültige Antwort vom Upstream erhalten oder konnte den Dialog nicht sauber abschließen. Im NOC ist 502 häufig der Code für „Verbindung zum Upstream ist instabil oder die Antwort ist nicht interpretierbar“.

Häufige Ursachen für 502 in Produktion

• Upstream-Verbindungsabbrüche: TCP-Reset, abruptes Close, Prozess-Crash, Out-of-Memory-Kills.
• TLS-/Handshake-Probleme: Zertifikatskette, SNI-Mismatch, Cipher-Suite-Mismatch zwischen Proxy und Upstream (bei mTLS besonders häufig).
• Protokoll-/Header-Fehler: ungültige HTTP-Response, fehlerhafte Chunked-Encoding-Frames, falsche Content-Length, kaputte gzip-Streams.
• HTTP/2- und gRPC-Edge-Cases: Stream-Reset, GOAWAY, falsche ALPN-Aushandlung.
• Misroute mit „falschem“ Upstream: Proxy spricht mit einem Dienst, der zwar antwortet, aber nicht im erwarteten Protokoll (z. B. HTTPS erwartet, HTTP geliefert).

Wie Sie 502 operativ belegen, statt zu raten

• Proxy-Logs: Suchen Sie nach „upstream prematurely closed connection“, „connection reset by peer“, „SSL handshake failed“ oder „invalid header“ (je nach Proxy).
• Upstream-Health vs. Errorrate: Wenn Upstream-CPU/RAM am Limit ist und gleichzeitig 502 steigt, sind Prozessabbrüche plausibel.
• Vergleich HTTP/HTTPS: Wenn nur HTTPS betroffen ist, ist TLS-Handshaking wahrscheinlicher als reine App-Logik.
• Packet Capture/SYN-ACK: Bei harten Fällen zeigt ein kurzer Capture, ob Verbindungen aufgebaut werden und wer Resets sendet.

Ein guter Merksatz: 502 ist oft „Dialog kaputt“ – nicht „Upstream ist langsam“. Wenn Latenz das Hauptsymptom ist, sind 504 oder 503 (durch Schutzmechanismen) statistisch häufiger.

HTTP 503: Service Unavailable – Überlastschutz, Health-Checks und „keine Backends“

HTTP 503 wird oft erzeugt, wenn der Proxy entscheidet: „Ich kann oder will diesen Request jetzt nicht zum Upstream senden.“ Das kann korrekt sein (Maintenance, Circuit Breaker), oder es kann eine Fehlkonfiguration sein (Health-Checks schlagen fälschlich fehl, Pool leer, falsche Route).

Häufige Ursachen für 503

• Keine gesunden Upstreams: Alle Backends sind „unhealthy“ markiert (Health-Check Fail), Pool ist leer.
• Rate Limiting / Overload Protection: WAF/CDN/Proxy blockt oder drosselt, z. B. bei Traffic-Spikes.
• Geplante Maintenance: Explizite 503-Auslieferung mit Retry-After (sauber implementiert).
• Circuit Breaker im Service Mesh: Requests werden abgewiesen, bevor sie den Dienst erreichen.
• Fehlkonfiguration: falscher Health-Check-Pfad, falsche Host-Header-Anforderung, mTLS-Policy verhindert Health-Checks.

Der schnellste 503-Check: Health-Check-Kette und Pool-Status

• Pool-Mitglieder: Sind überhaupt Backends registriert? Passt die Service Discovery?
• Health-Check-Ergebnisse: Welche Probe schlägt fehl – TCP, HTTP, HTTPS, gRPC? Was ist der erwartete Statuscode?
• Header-Anforderungen: Muss der Health-Check einen Host-Header senden? Braucht er Auth? Wird er durch WAF geblockt?
• Rollback-Faktor: Wenn 503 nach einem LB-/Ingress-Change beginnt, ist ein Rollback oft die schnellste Stabilisierung.

Operativ ist 503 häufig ein Geschenk: Es sagt Ihnen, dass die Infrastruktur bewusst nicht weiterleitet oder nichts zum Weiterleiten hat. Das ist meist schneller zu fixen als ein „mysteriöser“ 504, der viele Ursachen haben kann.

HTTP 504: Gateway Timeout – Timeout ist nicht gleich Netzwerkproblem

HTTP 504 entsteht, wenn das Gateway innerhalb eines konfigurierten Zeitfensters keine vollständige Antwort vom Upstream erhält. Das klingt eindeutig, ist es aber nicht: Der Upstream kann komplett „down“ sein, er kann erreichbar aber extrem langsam sein, oder der Weg dorthin kann Pakete droppen. Außerdem existieren oft mehrere Timeouts in Serie: Client, CDN, Ingress, Mesh, App.

Typische Ursachen für 504

• Upstream ist zu langsam: Datenbank hängt, Threadpool erschöpft, GC-Pausen, Lock-Contention, externe Abhängigkeit langsam.
• Netzpfad-/L4-Probleme: Paketverlust, MTU/Fragmentierung, asymmetrisches Routing durch Stateful Firewall, Security-Policy-Drops.
• DNS-/Service-Discovery-Flapping: Der Proxy versucht wechselnde Backends, Verbindungen werden nicht stabil aufgebaut.
• Timeout-Mismatch: Proxy-Timeout ist kürzer als App-Processing; lange Requests werden systematisch abgebrochen.
• Retry-Stürme: Clients/Proxies retrien aggressiv, Upstream wird noch langsamer, 504 eskaliert.

Timeout-Kette sichtbar machen

Im Incident ist es hilfreich, die Timeout-Kette als Minimum zu verstehen: Der kürzeste Timeout gewinnt und bestimmt den beobachteten Fehler. Wenn Sie Timeouts abstimmen wollen, hilft eine einfache Regel: äußere Schichten (Client/CDN) sollten etwas länger warten als innere, damit Fehler möglichst nah an der Ursache entstehen und sauber geloggt werden.

$T\_\mathrm{client}>T\_\mathrm{edge}>T\_\mathrm{ingress}>T\_\mathrm{upstream}$

Diese Ungleichung ist keine harte Vorschrift, aber ein nützliches Designprinzip: Wenn der Ingress nach 15 Sekunden abbricht, der Client aber 60 Sekunden wartet, sehen Sie 504 am Ingress (gut) statt „Client Timeout“ ohne Kontext (schlecht).

Misroute vs. Upstream Down vs. Timeout: Die drei häufigsten Verwechslungen

In der Praxis sind 502/503/504 weniger „Codes“, sondern Fehlermodelle. Die häufigsten Verwechslungen lassen sich mit wenigen Checks auflösen.

Misroute: Requests landen beim falschen Ziel

• Indiz: Nur bestimmte Pfade/Hosts betroffen, oft nach Ingress-/Routing-Change.
• Signal: 502 bei Protokoll-Mismatch (HTTP vs. HTTPS), 404/301 an unerwarteter Stelle, falsche Header im Response.
• Beweis: Vergleich der Route-Konfiguration (Host/Path), Upstream-Service-Name, SNI/Host-Header. Ein Trace zeigt, dass Requests an einen anderen Service gehen.
• Mitigation: Route korrigieren, Canary-Rollback, klare Host-Header-Regeln, Tests pro Route.

Upstream Down: Dienst nicht verfügbar oder nicht erreichbar

• Indiz: 503 „no healthy upstream“ oder 502 „connect failed“; Health-Checks schlagen breit fehl.
• Signal: Connect-Errors, SYN ohne SYN-ACK, oder sofortige Resets.
• Beweis: Upstream-Pod/VM down, Prozess nicht listening, Security Group blockt Port, Deployment hat 0 Replicas.
• Mitigation: Skalieren/Restart, Listener/Port fixen, Security Policy korrigieren, Traffic umleiten.

Timeout: Upstream antwortet nicht rechtzeitig

• Indiz: 504 steigt mit wachsender Latenz, oft parallel zu Queue-/Threadpool-Metriken.
• Signal: Upstream nimmt Verbindungen an, aber Response bleibt aus oder kommt zu spät.
• Beweis: Upstream-Request-Duration in Tracing hoch, DB-Latenz hoch, externe API langsam; Proxy-Timeout exakt bei X Sekunden.
• Mitigation: Backpressure, Circuit Breaker, gezielte Timeouts, Caching, Skalierung, Abhängigkeiten stabilisieren.

Welche Daten müssen ins Ticket? Standardisierte „Minimal Evidence“

Damit Sie schnell das richtige Owner-Team bekommen, brauchen Sie reproduzierbare Fakten. Diese Liste ist bewusst kurz und reicht in vielen Fällen, um die Richtung eindeutig zu machen.

• Betroffene URL(s): Host, Pfad, Methode; ob nur ein Endpoint oder viele.
• Fehlercode: 502/503/504 plus Häufigkeit und Startzeit.
• Wo erzeugt?: CDN/WAF, Ingress, Mesh, Upstream (Header/Logs/Request-ID).
• Latenzprofil: P50/P95/P99 und ob vor Fehlern Latenz steigt.
• Upstream-Pool-Status: healthy/unhealthy count; Health-Check-Reason.
• Letzter Change: Deploy, Routing, TLS, Policy, Autoscaling – mit Timestamp.

Ein Ticket, das diese Punkte enthält, ist für SRE/Plattform deutlich schneller bearbeitbar als „502 überall“.

Fehlercode-zu-Owner-Team: Praktische Zuordnung für Eskalationen

Die Owner-Zuordnung hängt nicht am Code allein, sondern am Erzeuger und am begleitenden Signal. Trotzdem lassen sich typische Muster benennen:

• 502 + TLS-Handshake-Fehler: Plattform/Ingress/PKI (oder Mesh), ggf. App bei mTLS-Konfiguration.
• 502 + Connection Reset / Premature Close: App-Team (Crash/Process), Runtime/Node-Team, manchmal Netzwerk bei Firewall/Idle-Timeout.
• 503 + no healthy upstream: Plattform/Ingress/SRE, Service Discovery, Deployment/Autoscaling.
• 503 + Rate Limit: Edge/WAF/CDN oder API-Gateway-Team; ggf. Produkt/Traffic-Management.
• 504 + Proxy-Timeout exakt bei X Sekunden: Timeout-Konfiguration (Ingress/Mesh) plus Upstream-Performance (App/DB).
• 504 + nur bestimmte Region: CDN/Edge-POP, regionales Routing, WAN/Peering oder zonenspezifischer Cluster.

Diese Zuordnung verhindert, dass 504 reflexartig als „Netzwerk“ eskaliert wird, obwohl es meist eine Performance-/Backpressure-Frage im Upstream ist.

Retry- und Timeout-Fallen: Warum 502/503/504 sich selbst verstärken können

Ein häufiger Grund, warum Incidents eskalieren, ist die Kombination aus Retries und kurzen Timeouts. Wenn Clients bei 502/503/504 sofort mehrfach retrien, steigt die Last auf Proxy und Upstream, wodurch noch mehr Timeouts entstehen. Das Ergebnis ist ein negativer Feedback-Loop.

• Symptom: QPS steigt parallel zur Fehlerquote, obwohl Nutzerzahl konstant ist.
• Ursache: Retries ohne Jitter/Backoff, Retry auf nicht-idempotente Requests, zu aggressive Client-SDKs.
• Mitigation: Exponentielles Backoff mit Jitter, Retries nur auf idempotente Methoden, Circuit Breaker, klare Budgetierung der Retry-Last.

Operativ hilfreich ist die Trennung von „Fehler durch fehlende Kapazität“ (503/Overload) und „Fehler durch Langsamkeit“ (504). Retries sind bei 503 oft kontraproduktiv, bei transienten 502 unter Umständen hilfreich – aber nur kontrolliert.

Outbound-Links für belastbare Referenzen

• HTTP Semantics (RFC 9110) für Definitionen von Statuscodes und HTTP-Grundlagen.
• HTTP Caching (RFC 9111) für Cache-Verhalten, das 5xx-Symptome beeinflussen kann.
• NGINX Proxy Module Dokumentation für Upstream-Fehler, Timeouts und typische Log-Meldungen.
• Envoy Upstream Architecture für Timeouts, Retries und Failure-Modes in proxybasierten Architekturen.
• HAProxy Configuration Manual für Health-Checks, Backend-States und Error-Handling.
• MDN: HTTP Status Codes als praxisnahe Übersicht inkl. 502/503/504.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.