HTTP-5xx-Spike am Edge: Origin Down vs. Network Congestion unterscheiden

Ein HTTP-5xx-Spike am Edge gehört zu den Incident-Situationen, die in einem Provider- oder CDN-Betrieb besonders schnell eskalieren: Kunden sehen „Serverfehler“, Monitoring schlägt an, und im War Room prallen Hypothesen aufeinander. Zwei Ursachen dominieren in der Praxis – und sind operativ sehr unterschiedlich zu behandeln: Origin Down (der Ursprung ist nicht erreichbar oder liefert Fehler) versus Network Congestion (das Netz zwischen Edge und Origin ist überlastet, wodurch Timeouts, Retransmits und Folgefehler entstehen). Wer beide sauber unterscheiden kann, reduziert MTTR deutlich, weil die Maßnahmen entkoppelt sind: Bei Origin Down helfen Stabilisierung am Origin, Fallbacks und Error-Caching; bei Congestion helfen Traffic-Steering, Rate-Limits und Kapazitäts-/Routing-Maßnahmen. Entscheidend ist, dass „5xx“ kein eindeutiges Signal ist: Je nach Architektur kann ein Edge 5xx direkt vom Origin weiterreichen, selbst erzeugen (z. B. Gateway Timeout) oder aus internen Retries und Deadline-Überschreitungen ableiten. Dieser Artikel zeigt, wie Sie in Minuten eine belastbare Diagnose aufbauen, welche Telemetrie wirklich zählt und wie Sie ein RCA so schreiben, dass Ursache, Mechanismus und Mitigation nachvollziehbar getrennt sind.

Warum 5xx am Edge nicht automatisch „Origin kaputt“ bedeutet

Im HTTP-Kontext stehen 5xx für serverseitige Fehler, doch „serverseitig“ ist im CDN-/Provider-Betrieb relativ. Der „Server“ aus Sicht des Clients ist der Edge. Ein 5xx am Edge kann daher drei grundlegend unterschiedliche Ursprünge haben: Der Origin liefert tatsächlich 5xx, der Edge generiert 5xx aufgrund von Upstream-Problemen (z. B. 502/503/504), oder eine Zwischenkomponente (Shield, Proxy, L7-LB) erzeugt den Fehler und der Edge reicht ihn durch. Die Unterscheidung ist wichtig, weil ein Origin Down typischerweise mit klaren Error-Signaturen, Health-Check-Failures und konsistenten Fehlerraten einhergeht, während Congestion oft schleichend beginnt, regional asymmetrisch ist und zunächst als „Latenzproblem“ erscheint, bevor harte Fehler folgen.

• Origin Down: Origin antwortet nicht, antwortet zu langsam oder liefert 5xx aufgrund interner Überlast/Fehler.
• Network Congestion: Pfad Edge↔Origin hat Loss/Queueing; Requests laufen in Timeouts, Retries erhöhen Last.
• Kontroll- vs. Datenebene: DNS/Anycast/Steering kann einzelne PoPs stärker treffen, wodurch das Bild „zufällig“ wirkt.

Begriffe sauber definieren: Origin Down, Congestion und „Error Amplification“

Für eine schnelle Diagnose hilft es, die Mechanik klar zu benennen. Origin Down umfasst sowohl echte Ausfälle (Dienst nicht erreichbar) als auch funktionale Ausfälle (Dienst erreichbar, aber liefert Fehler oder ist so langsam, dass er praktisch unbenutzbar ist). Network Congestion meint eine Überlast auf dem Transportpfad – in ISP-Umgebungen oft auf Interconnects, Peering/Transit, Backbone-Segmenten oder internen Links zwischen Edge und Shield. Ein dritter Begriff verbindet beides: Error Amplification. Sobald Retries im Spiel sind (Client, Edge oder Proxy), kann ein leichter Qualitätsverlust im Netz oder eine moderate Origin-Latenz in einen massiven 5xx-Spike kippen, weil zusätzliche Requests die Situation weiter verschärfen.

Warum Retries die Lage kippen lassen

Viele Systeme retryen automatisch: Browser, SDKs, CDNs, Load Balancer. Wenn dabei die Retry-Policy zu aggressiv ist oder kein „circuit breaker“ greift, steigt die effektive Last. Eine einfache Denkformel für die Lastverstärkung ist der Retry-Faktor:

$\mathrm{LoadFactor}=\mathrm{BaseRequests}\times (1+\mathrm{RetryRate}\times \mathrm{AvgRetries})$

Selbst eine moderate RetryRate kann in einem Congestion-Szenario die Links weiter füllen und damit Loss/Queueing verschlimmern – was wiederum mehr Timeouts erzeugt.

Symptom-Muster: Welche 5xx-Codes eher für Origin Down sprechen

Bestimmte Codes sind statistisch häufiger bei echten Origin-Problemen, andere eher bei Pfadproblemen. Das ist keine Regel ohne Ausnahmen, aber ein hilfreicher Startpunkt.

• HTTP 500/503 vom Origin: Häufig ein Hinweis auf Applikations- oder Plattformprobleme (Crash, Dependency-Failure, Overload).
• HTTP 502 (Bad Gateway): Oft von Proxies/Edges erzeugt, wenn Upstream-Verbindungen fehlschlagen oder ungültige Antworten kommen.
• HTTP 504 (Gateway Timeout): Klassiker bei Timeouts – kann Origin-Slow oder Network Congestion bedeuten; Kontext entscheidet.
• HTTP 521/522/524 (provider-spezifisch): Je nach CDN/WAF signalisieren diese Codes Erreichbarkeits- oder Timeout-Probleme zum Origin.

In der Praxis ist der Mix entscheidend: Ein Anstieg von 500/503 bei stabilen RTTs spricht eher für Origin Down. Ein Anstieg von 502/504 zusammen mit steigenden RTTs, Loss oder Retransmits spricht eher für Congestion oder Pfadinstabilität.

Symptom-Muster: Woran Sie Network Congestion erkennen, obwohl „nur“ 5xx sichtbar sind

Congestion ist tückisch, weil sie selten überall gleich aussieht. Sie ist oft regional, zeitlich fluktuierend und kann einzelne Pfade stärker treffen. Außerdem kann Congestion auf Layer 3/4 stattfinden, während der Edge die Folgen als Layer-7-Fehler präsentiert.

• Regionale Asymmetrie: Bestimmte PoPs oder Regionen sehen deutlich mehr 5xx als andere.
• Vorläufer-Signale: Erst steigen Latenz und 499/408/Client-Abbrüche (je nach Plattform), danach 502/504.
• Backbone-/Interconnect-Korrelation: 5xx-Spike korreliert mit Link-Auslastung, Queue-Drops oder ECN-Markierungen.
• Jitter und Burstiness: Fehler treten in Wellen auf (Queue-Build/Drain), nicht als konstant flaches Plateau.

Der wichtigste Unterschied im Zeitverlauf

Origin Down zeigt häufig einen klaren „Step-Change“: ab Zeitpunkt X ist die Fehlerrate hoch und bleibt es, bis ein Fix greift. Congestion zeigt oft einen „Sägezahn“: Phasen mit hoher Latenz und Fehlern wechseln mit scheinbarer Erholung, besonders wenn Traffic Engineering oder adaptive Routing-Mechanismen aktiv sind.

Die 10-Minuten-Diagnose: Minimal-Set an Checks, die fast immer reichen

Wenn es schnell gehen muss, sollten Sie nicht „alles“ prüfen, sondern wenige, hoch aussagekräftige Signale. Ziel ist eine belastbare Entscheidung: Arbeiten wir primär am Origin oder primär am Netz?

• Edge-Logs nach Upstream-Timing: Connect-Time, TLS-Handshake-Time, TTFB, Total-Time – getrennt nach Region/PoP.
• Origin-Health und Error-Raten: 5xx/timeout am Origin selbst, Health Checks, Saturation (CPU, Threads, Queue).
• Backbone/Interconnect-Qualität: Loss, Drops, Retransmits, Queueing, Interface-Auslastung auf relevanten Links.
• Vergleich zweier Pfade: Ein Test aus zwei PoPs oder via zwei Transits/Peers: gleiches Verhalten spricht eher für Origin, unterschiedliches eher für Netz.
• Cache/Shield-Status: Treffen Fehler nur bei Origin-Fetches auf? Sind Cache-Hits stabil, aber Misses fehlerhaft?

Edge-Telemetrie richtig lesen: Timing-Daten statt reiner Statuscodes

Statuscodes sind Ergebnis, Timing ist Ursache. Moderne Edges, Proxies und Load Balancer liefern Metriken, die die Upstream-Kommunikation zerlegen: DNS-Lookup, TCP-Connect, TLS-Handshake, Time-to-First-Byte (TTFB), Download-Time. Diese Zerlegung ist Gold wert: Bei Congestion steigen oft Connect- und Transferzeiten (und Varianz), während bei Origin Down TTFB und Upstream-5xx dominieren.

Heuristik: Welche Timing-Komponente kippt zuerst?

• Connect/TLS steigen stark: Hinweis auf Pfadprobleme, SYN-Loss, Überlast am Interconnect oder Stateful Devices.
• TTFB steigt bei stabiler Connect-Zeit: Hinweis auf Origin-Slow oder Overload im Origin-Stack.
• Total-Time steigt, Download-Time dominiert: Hinweis auf Congestion während der Datenübertragung (Loss/Queueing).

Origin-Sicht: Wie Sie „Down“ von „Slow“ unterscheiden

Ein Origin kann „up“ sein, aber funktional ausfallen, weil Ressourcen erschöpft sind oder Dependencies klemmen (DB, Cache, Auth). Für die Edge sieht das wie Timeouts aus – also ähnlich wie Congestion. Deshalb ist ein zweiter Blick nötig: Messen Sie am Origin die Warteschlangen und Sättigung, nicht nur HTTP-Status.

• Queue Depth / Thread Pools: Wenn Warteschlangen wachsen, steigen TTFB und Timeouts.
• 5xx ohne Netzindikatoren: Wenn Netzwerkmetriken stabil sind, ist Origin wahrscheinlicher.
• Dependency-Fehler: Wenn der Origin 503 wegen Downstream-Services liefert, ist das ein Origin-seitiger Ausfallmechanismus.

Netz-Sicht: Congestion lokalisieren, ohne sich im Routing zu verlieren

Bei Congestion ist das Ziel nicht sofort „perfektes Routing“, sondern schnelle Schadensbegrenzung. Dafür brauchen Sie eine schnelle Lokalisierung: Ist es ein einzelner Interconnect, ein Transit, ein Backbone-Segment oder ein internes Link-Bündel?

• Top-Talker-Flow-Analyse: Welche Ziele (Origin-IP/Prefix) dominieren? Ist es ein einzelner Hostname/Service?
• Interface-Fehler und Drops: Drops/Discards auf wenigen Links sind ein starkes Signal.
• Pfad-Asymmetrie: Forward ok, Return congested (oder umgekehrt) – zeigt sich oft als „nur manche Regionen“.
• ECN/Queueing: Wenn verfügbar, sind ECN-Markierungen frühe Indikatoren vor harten Drops.

Mitigation, wenn der Origin down ist: Stabilisieren und Edge schützen

Bei Origin Down ist die wichtigste Maßnahme, den Origin zu entlasten und gleichzeitig den Kunden eine kontrollierte Degradation zu liefern. Blindes Retryen ist hier gefährlich.

• Circuit Breaker: Retries reduzieren, Fail-Fast aktivieren, damit der Origin nicht durch Retry-Wellen kollabiert.
• Stale-Serving: Wenn Inhalte cachebar sind, stale-while-revalidate und stale-if-error nutzen.
• Fallback-Origins: Failover auf sekundäre Origins oder statische Degraded-Responses (je nach Serviceklasse).
• Gezieltes Rate Limiting: Nicht Kunden pauschal drosseln, sondern teure Endpoints begrenzen.
• Lastreduktion durch Feature Flags: Kritische Pfade priorisieren, nicht-kritische Features temporär deaktivieren.

Mitigation, wenn Network Congestion das Problem ist: Traffic steuern, nicht „mehr Errors“ produzieren

Bei Congestion ist die Mitigation oft netzseitig und kurzfristig: Traffic weg von Hotspots, Last auf mehrere Pfade verteilen, und Fetch-/Retry-Verhalten kontrollieren. Wichtig ist, nicht gleichzeitig Origin und Netz zu „stress testen“.

• Traffic Steering: Edge/PoP-Auswahl ändern, Shield-Tier anpassen, regionale Overflows gezielt lenken.
• Rate-Limits für Origin-Fetches: Besonders bei Cache Misses; verhindert, dass Fill-Traffic das Netz flutet.
• QoS/Priorisierung: Kritische Services schützen, Hintergrund-Fills oder große Downloads niedriger priorisieren.
• Temporäre Kapazitätsmaßnahmen: Zusätzliche Links aktivieren, LAG-Mitglieder prüfen, TE-Policies schärfen.
• Retry-Policy entschärfen: Exponentielles Backoff, Jitter, begrenzte Max-Retries.

Der Klassiker: Origin und Congestion gleichzeitig – wie Sie die Kette aufdröseln

In großen Outages ist es häufig nicht „entweder/oder“. Ein Origin wird langsam, dadurch steigen Retries, dadurch wächst Traffic, dadurch entsteht Congestion, wodurch der Origin noch schlechter erreichbar ist. Um diese Kette zu entwirren, hilft ein chronologisches Vorgehen: Welches Signal kippte zuerst?

• Wenn Origin-Metriken zuerst kippen: Ursache eher originseitig, Congestion ist Folge.
• Wenn Netzmetriken zuerst kippen: Ursache eher transportseitig, Origin-Probleme sind Folge der Erreichbarkeit.
• Wenn beides gleichzeitig kippt: Prüfen Sie Change-Events (Deploy, Purge, Routing-Change) und regionale Unterschiede.

RCA sauber schreiben: Welche Belege wirklich überzeugen

Ein gutes RCA für einen HTTP-5xx-Spike am Edge trennt eindeutig zwischen Beobachtung, Ursache und Maßnahme. Besonders wichtig ist, dass Sie nicht nur „5xx hoch“ dokumentieren, sondern die Mechanik: Timing, Retry-Verhalten, Pfadqualität und Origin-Sättigung.

• Symptom: Welche Codes (502/503/504), welche Regionen, welche Endpoints, welcher Zeitraum?
• Primärursache: Origin Down (welcher Failure Mode) oder Network Congestion (welcher Pfad/Link)?
• Kausalität: Zeitliche Reihenfolge der Metriken (zuerst RTT/Loss oder zuerst Origin-Queues/5xx?).
• Amplifikation: Welche Retry-/Fetch-Mechanismen haben Last verstärkt?
• Mitigation: Was hat messbar geholfen (Hit-Rate hoch, Origin-Fetch runter, Loss runter, 5xx runter)?
• Prevention: Guardrails (Canary, SLO-basierte Rollbacks, Retry-Policy, Capacity/Steering).

Outbound-Links: Relevante Standards und praxisnahe Referenzen

• HTTP Semantics (RFC 9110) – Statuscodes, Semantik und Interaktionen
• HTTP Caching (RFC 9111) – Freshness, Validierung und Caching-Regeln
• HTTP-Statuscodes im Überblick – praktische Interpretation und Bedeutung
• QUIC (RFC 9000) – Transportverhalten, das Diagnosen beeinflussen kann

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.