499 ist ein nginx-spezifischer Code, der im Access-Log erscheint, wenn der Client die Verbindung geschlossen hat, während nginx die Anfrage noch verarbeitete. Es wird keine Antwort gesendet, weil niemand mehr da ist, der sie empfangen könnte.
Meist bedeutet das, dass die Anwendung im Upstream zu langsam war: Der Nutzer hat die Seite verlassen, ein Load Balancer oder API-Client ist in sein eigenes Timeout gelaufen, oder ein Health-Check hat aufgegeben. Eine Häufung von 499-Einträgen mit langen Anfragezeiten deutet auf ein langsames Backend hin, während einige 499 von Nutzern, die das Laden einer Seite abbrechen, normal sind.
Läuft ein vor nginx geschalteter Proxy zuerst in ein Timeout, protokolliert nginx 499, während der Proxy seinen eigenen Fehler meldet, etwa 504 oder 524 von Cloudflare.
Beispielantwort
# The client gave up before nginx had a response; nothing is sent.
# nginx access.log (last field: $request_time in seconds)
198.51.100.23 - - [06/Nov/2026:10:15:32 +0000] "GET /report?year=2026 HTTP/1.1" 499 0 "-" "Mozilla/5.0" 30.001SEO und Weiterleitungsprüfung
Crawler erhalten nie einen 499. Gibt der Googlebot aber das Warten auf eine langsame Seite auf, zeigen Ihre Logs 499 für seine Anfragen. Das ist ein Zeichen für langsame Server-Antwortzeiten, die den Umfang des Crawlings durch Google verringern. Auch Redirect-Checker brechen bei sehr langsamen Hops mit einem Timeout ab; der Weiterleitungs-Latenztest zeigt, welcher Hop langsam ist.
Häufige Ursachen und Einsatzzwecke
- Das Anwendungs-Backend braucht länger, als Client, CDN oder Load Balancer zu warten bereit sind.
- Nutzer brechen eine langsame Seite ab oder verlassen sie, bevor sie geladen ist.
- Monitoring und Health-Checks verwenden kurze Timeouts.