HTTP 408 Request Timeout: Bedeutung und Behebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Upload-Tool, Synthetic Monitor oder Health Checker erhält 408 Request Timeout.
• Der Fehler kann nur bei einer URL, HTTP-Methode, einem Client, Upload oder Netzwerkpfad auftreten und nicht auf der gesamten Website.
• Eine Anfrage mit Body, etwa ein Upload oder eine Formulareinsendung, kann fehlschlagen, nachdem die Verbindung offen geblieben ist, ohne dass die Anfrage abgeschlossen wurde.
• Response-Header können erkennen lassen, ob ein Proxy, CDN, Load Balancer, WAF oder Origin-Server die Antwort erzeugt hat.
• DNS-Auflösung und TLS-Aushandlung können erfolgreich sein, selbst wenn die anschließende HTTP-Anfrage einen 408 erhält.
• Logs können eine unvollständige Anfrage, eine inaktive Verbindung, ein Timeout beim Einlesen der Anfrage oder ein Timeout zeigen, das erzeugt wurde, bevor die Anfrage die Anwendung erreichte.

Hauptursachen nach Wahrscheinlichkeit

1. Der Client hat das Senden der Anfrage nicht abgeschlossen. Ein langsamer Upload, eine ins Stocken geratene Verbindung, eine unterbrochene Browser-Anfrage oder ein unvollständiger Request-Body kann die Wartezeit des Servers überschreiten.
2. Eine inaktive persistente Verbindung ist abgelaufen. Ein Server oder zwischengeschaltetes System kann eine Keep-Alive-Verbindung schließen, wenn die nächste Anfrage nicht innerhalb des konfigurierten Leerlaufzeitraums eintrifft oder abgeschlossen wird.
3. Ein Proxy, CDN, Load Balancer oder WAF hat zuerst ein Timeout ausgelöst. Verschiedene Schichten können unterschiedliche Limits für Request-Header, Request-Body, Verbindungsleerlauf oder die Gesamtdauer anwenden.
4. Netzwerkinstabilität hat die Zustellung der Anfrage verzögert. Paketverlust, eine unterbrochene Verbindung oder ein problematischer Netzwerkpfad kann verhindern, dass der Endpunkt die vollständige Anfrage empfängt.
5. Anfragedetails lösen eine schichtenspezifische Regel aus. Ein großer Body, ungewöhnliche Header, ein nicht unterstütztes Übertragungsmuster oder eine methodenspezifische Richtlinie kann dazu führen, dass ein zwischengeschaltetes System nicht weiter wartet oder den Anfragepfad ablehnt.
6. Die Antwort wurde falsch klassifiziert oder von einer benutzerdefinierten Infrastruktur erzeugt. Einige Systeme verwenden 408 für einen Timeout-Zustand, der nicht dem standardmäßigen Szenario einer Client-Anfrage entspricht. Daher müssen die erzeugende Komponente und deren Logs geprüft werden.

So behebst du den Fehler

Wenn Sie die Website besuchen

1. Wiederholen Sie die exakte URL einmal, nachdem Sie geprüft haben, ob die Adresse korrekt ist.
2. Wenn Sie eine Datei hochgeladen oder ein Formular gesendet haben, prüfen Sie, ob die Verbindung stabil geblieben ist und ob der Vorgang sicher fortgesetzt werden kann.
3. Wenn für die Anfrage ein Konto erforderlich ist, melden Sie sich über den normalen Ablauf der Website an und versuchen Sie es erneut. Senden Sie ein Formular oder eine Zahlungsanfrage nicht wiederholt, ohne zu prüfen, ob die erste Anfrage abgeschlossen wurde.
4. Wenn der Fehler weiterhin auftritt, notieren Sie die URL, die HTTP-Methode, sofern bekannt, die ungefähre Uhrzeit, den Netzwerktyp und die sichtbare 408-Antwort. Übermitteln Sie diese Angaben an den Website-Betreiber, ohne Passwörter, Cookies, Zahlungsdaten oder API-Keys weiterzugeben.

Wenn Sie den Service entwickeln oder betreiben

1. Erfassen Sie die exakte Anfrage. Protokollieren Sie Methode, URL-Pfad, Merkmale der Request-Größe, relevante Header, ob ein Body gesendet wurde, den Response-Status, Response-Header und einen Zeitstempel. Schwärzen Sie Zugangsdaten, Cookies, Authorization-Werte und personenbezogene Daten.
2. Reproduzieren Sie dieselben Bedingungen. Vergleichen Sie eine normale Anfrage mit der fehlschlagenden Methode, dem Client, der Upload-Größe, dem Verbindungstyp und dem Verhalten des Request-Bodys. Dass ein einfacher GET erfolgreich ist, schließt ein Timeout bei einem POST, Upload, Streaming-Request oder einer anderen Methode nicht aus.
3. Ermitteln Sie die Schicht, die die Antwort erzeugt hat. Prüfen Sie Response-Header sowie Request- oder Trace-IDs und gleichen Sie den Zeitstempel in den Logs von CDN, WAF, Load Balancer, Reverse Proxy, Webserver und Anwendung ab. Die erste Schicht, die das Timeout protokolliert, ist in der Regel der beste Ausgangspunkt.
4. Prüfen Sie Einstellungen für das Einlesen von Requests und für Inaktivitäts-Timeouts. Untersuchen Sie die relevanten Server- und Einstellungen zwischengeschalteter Systeme für unvollständige Header, langsame Request-Bodies, Keep-Alive-Verbindungen und die Gesamtdauer der Anfrage. Vergleichen Sie diese mit dem erwarteten Upload- und Client-Verhalten der Anwendung.
5. Prüfen Sie Netzwerkpfad und Client-Verhalten. Achten Sie auf Verbindungsabbrüche, Paketverlust, stockende Uploads, Proxy-Änderungen oder einen Client, der eine Verbindung öffnet, das Senden der Anfrage jedoch nicht abschließt.
6. Vergleichen Sie kürzliche Änderungen. Prüfen Sie Deployments und Änderungen an Routing, Proxy-/CDN-Einstellungen, WAF-Regeln, Request-Größenlimits, Authentifizierungs-Middleware und Verbindungsverwaltung. Behandeln Sie Authentifizierung oder Autorisierung als nachrangige Untersuchung, sofern Logs nicht zeigen, dass die Anfrage diese Logik erreicht hat.
7. Wenden Sie die engste autorisierte Korrektur an. Ändern Sie nur das verantwortliche Timeout oder die zuständige Regel zur Request-Verarbeitung oder korrigieren Sie das Client-Verhalten. Deaktivieren Sie Sicherheitskontrollen nicht pauschal und erhöhen Sie nicht jedes Timeout, ohne Auswirkungen auf Kapazität und Missbrauchsrisiken zu verstehen.
8. Testen Sie erneut und überwachen Sie den Vorgang. Wiederholen Sie die ursprüngliche Anfrage sicher, prüfen Sie, ob der erwartete Status zurückgegeben wird, und kontrollieren Sie angrenzende Routen und Methoden. Verwenden Sie bei nicht idempotenten Requests einen freigegebenen Testfall oder bestätigen Sie das Ergebnis des Vorgangs, bevor Sie ihn erneut senden.

Vorbeugung und Überprüfung der Lösung

• Überwachen Sie HTTP-Statusraten nach Route, Methode, Clienttyp und Deployment, damit ein anfragespezifisches Timeout nicht in einer aggregierten Metrik verborgen bleibt.
• Dokumentieren Sie die Timeout-Einstellungen von CDN, WAF, Load Balancer, Reverse Proxy, Webserver und Anwendung und versionieren Sie sie, sofern unterstützt.
• Testen Sie langsame Uploads, unvollständige Anfragen, Keep-Alive-Verhalten und wichtige API-Methoden in einer kontrollierten Umgebung.
• Legen Sie Request- und Connection-Timeouts bewusst fest und wägen Sie dabei legitimes Client-Verhalten gegen Ressourcenverbrauch und Missbrauchsrisiken ab.
• Bewahren Sie synchronisierte Zeitstempel sowie Request- oder Trace-IDs über die Netzwerkschichten hinweg auf.
• Machen Sie das Wiederholungsverhalten von Clients eindeutig, insbesondere bei nicht idempotenten Requests wie Formulareinsendungen, Bestellungen oder Zahlungen.
• Halten Sie ausreichend bereinigte Logs und Metriken vor, um einen 408 der Komponente zuzuordnen, die ihn ausgegeben hat.

Häufig gestellte Fragen