Statuscode 499: was nginx mit Client Closed Request meint

Was der Statuscode 499 bedeutet

499 Client Closed Request ist nginx-spezifisch und in keinem RFC definiert. Codes über 99 und unter 600 sind allgemein für HTTP-Statuszeilen reserviert, aber 499 ist nginx' eigene Konvention, protokolliert, wenn nginx erkennt, dass die Verbindung des Clients abgebrochen ist, während es noch auf die Antwort der Upstream-Anwendung wartete, oder während es den Antwort-Body noch an den Client zurücksendete. Die häufigste reale Form ist ein langsames Upstream kombiniert mit einem Client, Browser-Tab, oder Load Balancer, dessen eigenes Timeout kürzer ist, als der Server gebraucht hätte, sodass der Client zuerst auflegt.

Wie er sich in Logs zeigt

Sie werden 499 nie als Statuscode sehen, der an irgendeinen Client zurückgegeben wird, Browser, curl, oder sonst was, denn per Definition ist der Client bereits weg, wenn nginx ihn zurücksenden würde. Er existiert nur im eigenen Zugriffslog von nginx:

10.0.0.12 - - [19/Sep/2026:14:02:11 +0000] "GET /api/report HTTP/1.1" 499 0 "-" "python-requests/2.31"

Die Antwortgröße von 0 Bytes und das Timing relativ zur bekannten Antwortzeit Ihres Upstreams sind die zwei nützlichsten Details: Ein 499, das konsequent genau um das Timeout Ihres Upstreams herum auftritt, ohne dass etwas zurückgesendet wurde, deutet klar auf "das Backend war zu langsam, und irgendetwas hat das Warten aufgegeben" hin.

Was einen 499 verursacht

• Eine langsame Upstream-Anwendung. Das Backend braucht länger zum Antworten, als ein Client oder Vermittler bereit ist zu warten, sei es eine langsame Datenbankabfrage, ein externer API-Aufruf, oder eine tatsächlich aufwendige Berechnung.
• Ein clientseitiges Timeout, kürzer als der Server braucht. Ein geschlossener Browser-Tab, eine mobile App, die bei einer wackligen Verbindung aufgibt, oder das eigene Timeout einer HTTP-Client-Bibliothek, das auslöst, bevor die Antwort ankommt.
• Ein Load Balancer oder vorgelagerter Proxy, dessen Timeout zuerst greift. Sitzt etwas zwischen dem eigentlichen Endnutzer und nginx, kann dessen eigenes Timeout einen Verbindungsabbruch auslösen, den nginx als 499 protokolliert, obwohl der echte Endnutzer nie ausdrücklich etwas abgebrochen hat.
• Ein Nutzer navigiert weg oder aktualisiert. Jemand, der von einer langsam ladenden Seite wegklickt, oder ungeduldig neu lädt, schließt die laufende Verbindung, bevor nginx fertig war.
• Timeout-Werte, die über die Kette hinweg inkonsistent sind. Ein Client, ein CDN, ein Load Balancer, und nginx selbst können jeweils ein unterschiedliches Timeout haben, und welches auch immer das kürzeste ist, bestimmt, wann der Abbruch passiert, unabhängig davon, worauf die anderen konfiguriert sind.

Warum er nie in einem Browser erscheint

499 ist keine Antwort, es ist eine Notiz, die sich nginx über eine Antwort macht, die es nie zu Ende senden konnte. Ein Nutzer, dessen Tab in Ihren Logs einen 499 erzeugt hat, sieht überhaupt nichts: keine Fehlerseite, keinen Statuscode, nur eine Seite, die aufgehört hat zu laden, oder einen Spinner, der sich nie auflöst, weil es keine Antwort gab, die der Browser hätte rendern können. Genau deshalb übersieht man das komplett, wenn man sich auf von Nutzern gemeldete Fehler verlässt; der einzige Ort, an dem ein 499 sichtbar ist, ist das eigene Zugriffslog des Servers.

So beheben und reduzieren Sie 499er

Es gibt keine einzelne Einstellung, die 499er beseitigt, da die zugrunde liegende Ursache ein Wettrennen zwischen dem aufgebenden Client und dem fertig werdenden Server ist, und die Lösung davon abhängt, welche Seite dieses Rennens tatsächlich kaputt ist. Beginnen Sie damit festzustellen, ob das Upstream für die betroffene Route durchgehend langsam ist, oder ob sich die Abbrüche um einen bestimmten Client, ein Netzwerk, oder einen Vermittler häufen, da das auf unterschiedliche Lösungen hindeutet.

1. Untersuchen Sie zuerst die Upstream-Antwortzeit, da ein langsames Backend die häufigste zugrunde liegende Ursache ist. Sehen Sie sich an, wie lange die betroffenen Anfragen upstream tatsächlich gebraucht haben, nicht nur, dass nginx einen 499 protokolliert hat.
2. Gleichen Sie Timeout-Werte über die gesamte Kette hinweg bewusst ab, statt den Standardwert jeder Schicht unverändert zu lassen: Client, CDN, Load Balancer, und nginx' eigene proxy_read_timeout und proxy_connect_timeout sollten mit einem klaren Verständnis gesetzt werden, welches davon zuerst auslösen soll.
3. Erwägen Sie proxy_ignore_client_abort, falls es für Ihre Anwendung wichtig ist, das Upstream seine Arbeit auch nach der Trennung des Clients beenden zu lassen, zum Beispiel um einen Schreibvorgang abzuschließen, der nicht halb fertig bleiben sollte:

   proxy_ignore_client_abort on;

   Das verhindert nicht den 499-Log-Eintrag für den ursprünglichen Abbruch; es ändert nur, ob nginx die Upstream-Anfrage unabhängig davon weiterlaufen lässt.
4. Beschleunigen Sie die eigentliche Upstream-Arbeit, wo die eigentliche Ursache tatsächlich ein langsamer Endpunkt ist, da keine Menge an Timeout-Feinjustierung ein Backend behebt, das an sich zu lange braucht; profilen Sie die konkreten langsamen Abfragen oder Aufrufe hinter der betroffenen Route.
5. Behandeln Sie eine steigende 499-Rate als echtes Signal, nicht als herauszufilterndes Log-Rauschen, da es meist bedeutet, dass Ihre Anwendung langsamer geworden ist oder Ihre Timeout-Konfiguration irgendwo in der Kette nicht zusammenpasst.

So verhindern Sie, dass daraus ein Ausfall wird

Da 499 den Client nie als sichtbaren Fehler erreicht, kann ein tatsächlich langsamer Endpunkt leicht unbemerkt bleiben, bis jemand die Zugriffslogs liest, während echte Nutzer still ihre Anfragen abbrechen. Eine geplante HTTP-Prüfung misst die tatsächliche Antwortzeit direkt am Endpunkt und alarmiert, wenn sie sich verschlechtert, und erkennt so die Verlangsamung, die die 499er erzeugt, bevor sie zu regelrecht scheiternden Anfragen anwächst. Monitoring von mehreren Standorten hilft außerdem, ein tatsächlich langsames Backend von einem Timeout zu trennen, das nur bei Clients auf einem bestimmten Netzwerkpfad auslöst.

Verwandte Fehler

Siehe 504 Gateway Timeout für das standardisierte, für den Client sichtbare Äquivalent, wenn nginx selbst das Warten auf das Upstream aufgibt, statt dass der Client zuerst aufgibt, die 4xx-Übersicht für die standardisierte Familie der Client-Fehler, und 429 Too Many Requests für eine andere Art Ablehnung, gebunden an Rate statt an Timing.

Häufig gestellte Fragen

Ist 499 ein echter HTTP-Statuscode?

Nein. Es ist nginx' eigene Log-Konvention für einen Client, der die Verbindung getrennt hat, bevor die Antwort fertig war, und er wird nie über die Leitung an irgendeinen Client gesendet, da der Client zu dem Zeitpunkt, an dem er gesendet würde, bereits weg ist.

Warum sieht mein Monitoring-Tool nie einen 499?

Eine Monitoring-Prüfung ist selbst ein Client, und gibt sie selbst bei einer langsamen Antwort auf, meldet sie ihren eigenen Timeout-Fehler, nicht 499, da sie nie eine HTTP-Antwort empfängt, aus der sie einen Statuscode lesen könnte. 499 erscheint ausschließlich im eigenen Zugriffslog-Eintrag des Servers für diese Anfrage.

Bedeutet ein 499, dass mein Server abgestürzt ist?

Nein. Es bedeutet konkret, dass der Server noch arbeitete, oder gerade anfangen wollte zu arbeiten, als der Client die Verbindung trennte. Ein Absturz würde typischerweise stattdessen einen 502 oder 500 erzeugen, sobald etwas doch antwortete.

Kann ich die Upstream-Verarbeitung stoppen, wenn ein Client die Verbindung trennt?

Standardmäßig hört nginx im Allgemeinen auf, auf das Upstream zu warten, sobald der Client weg ist, aber das genaue Verhalten hängt von Ihren Proxy-Einstellungen ab; proxy_ignore_client_abort on sagt nginx, die Upstream-Anfrage weiterlaufen zu lassen, statt sie abzubrechen.

Was ist die häufigste Lösung für wiederkehrende 499er?

Timeout-Werte über Client, jeden dazwischenliegenden Proxy oder Load Balancer, und nginx selbst abzugleichen, kombiniert damit, zu beheben, was das Upstream überhaupt erst langsam macht. Keines von beidem allein löst meist ein anhaltendes Muster.