it-swarm.com.de

Nginx 499 Fehlercodes

Ich bekomme eine Menge von 499 Nginx-Fehlercodes. Ich sehe, dass dies ein clientseitiges Problem ist. Es ist kein Problem mit Nginx oder meinem uWSGI-Stack. Ich notiere die Korrelation in uWSGI-Protokollen, wenn ein 499 erhalten wird.

address space usage: 383692800 bytes/365MB} {rss usage: 167038976
bytes/159MB} [pid: 16614|app: 0|req: 74184/222373] 74.125.191.16 ()
{36 vars in 481 bytes} [Fri Oct 19 10:07:07 2012] POST /bidder/ =>
generated 0 bytes in 8 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1
switches on core 1760)
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request /bidder/ (ip 74.125.xxx.xxx) !!!
Fri Oct 19 10:07:07 2012 - write(): Broken pipe [proto/uwsgi.c line
143] during POST /bidder/ (74.125.xxx.xxx)
IOError: write error

Ich suche nach einer tiefer gehenden Erklärung und hoffe, dass mit meiner Nginx-Konfiguration für uwsgi nichts falsch ist. Ich nehme es für bare Münze ... es ist kein Ich-Problem. Es ist ein Kundenproblem.

Vielen Dank 

77
Tampa

HTTP 499 in Nginx bedeutet, dass der Client die Verbindung geschlossen hat bevor der Server die Anfrage beantwortet hat. In meiner Erfahrung wird in der Regel durch clientseitige Timeoutverursacht. Wie ich weiß, handelt es sich um einen Nginx-spezifischen Fehlercode.

124
mrbo

In meinem Fall war ich ungeduldig und habe das Protokoll falsch interpretiert. 

Tatsächlich war das eigentliche Problem die Kommunikation zwischen nginx und uwsgi und nicht zwischen dem Browser und nginx. Wenn ich die Site in meinen Browser geladen und lange genug gewartet hätte, hätte ich ein "504 - Bad Gateway" erhalten. Aber es hat so lange gedauert, dass ich ständig Sachen ausprobierte und dann im Browser aktualisiere. Also habe ich nie lange genug gewartet, um den Fehler 504 zu sehen. Bei der Aktualisierung im Browser wird die vorherige Anforderung geschlossen und Nginx schreibt dies als 499 in das Protokoll. 

Ausarbeitung

Hier gehe ich davon aus, dass der Leser so wenig weiß wie ich, als ich anfing, herumzuspielen. 

Mein Setup war ein Reverse Proxy, der Nginx-Server, und ein Anwendungsserver, der dahinter liegende uWSGI-Server. Alle Anforderungen des Clients gingen an den Nginx-Server, wurden dann an den uWSGI-Server weitergeleitet, und eine Antwort wurde auf dieselbe Weise zurückgesendet. Ich denke, das ist, wie jeder Nginx/Uwsgi verwendet und es verwenden soll. 

Mein Nginx funktionierte wie es sollte, aber mit dem Uwsgi-Server stimmte etwas nicht. Es gibt zwei Möglichkeiten (möglicherweise mehr), auf die der uwsgi-Server möglicherweise nicht auf den nginx-Server reagiert. 

1) uWSGI sagt: "Ich arbeite gerade, warte einfach und du wirst bald eine Antwort bekommen". nginx hat eine gewisse Zeit, die er warten möchte, dh 20 Sekunden. Danach antwortet der Client mit einem 504-Fehler. 

2) uWSGI ist tot, oder uWSGi stirbt, während nginx darauf wartet. nginx sieht das sofort und gibt in diesem Fall einen Fehler 499 zurück. 

Ich habe mein Setup durch Abfragen im Client (Browser) getestet. Im Browser ist nichts passiert, es hängt einfach weiter. Nach vielleicht 10 Sekunden (weniger als dem Timeout) kam ich zu dem Schluss, dass etwas nicht stimmte (was wahr war) und schloss den uWSGI-Server von der Befehlszeile aus. Dann würde ich zu den uWSGI-Einstellungen gehen, etwas Neues ausprobieren und dann den uWSGI-Server neu starten. Sobald ich den uWSGI-Server geschlossen habe, würde der Nginx-Server einen Fehler 499 zurückgeben. 

Also habe ich weiterhin mit dem 499-Fehler debuggen, das heißt, nach dem 499-Fehler googeln. Aber wenn ich lange genug gewartet hätte, hätte ich den 504-Fehler bekommen. Wenn ich den 504-Fehler erhalten hätte, hätte ich das Problem besser verstehen und dann debuggen können. 

Die Schlussfolgerung ist also, dass das Problem bei uWGSI lag, das ständig hängen blieb ("Warten Sie etwas länger, nur etwas länger, dann habe ich eine Antwort für Sie ..."). 

Wie ich das Problem behoben habe, ich erinnere mich nicht. Ich denke, es könnte durch viele Dinge verursacht werden. 

48
Mads Skjern

Client hat die Verbindung geschlossen bedeutet nicht, dass es sich um ein Browserproblem handelt !? Überhaupt nicht!

Sie können 499 Fehler in einer Protokolldatei finden, wenn Sie einen LB (Load Balancer) vor Ihrem Webserver (Nginx) entweder AWS oder Haproxy (benutzerdefiniert) haben. Das heißt, die LB wird als Kunde von Nginx fungieren. 

Wenn Sie haproxy-Standardwerte für Folgendes ausführen:

    timeout client  60000
    timeout server  60000

Das bedeutet, dass LB nach 60000ms ausfällt, wenn nginx keine Antwort gibt. Zeitüberschreitungen können für viel beschäftigte Websites oder Skripts auftreten, die mehr Zeit für die Ausführung benötigen. Sie müssen ein Timeout finden, das für Sie funktionieren wird. Zum Beispiel erweitern Sie es auf:

    timeout client  180s
    timeout server  180s

Und du wirst wahrscheinlich eingestellt sein.

Abhängig von Ihrem Setup wird in Ihrem Browser möglicherweise ein Timeout-Fehler des Gateway 504 angezeigt, der darauf hinweist, dass mit php-fpm etwas nicht stimmt. Dies ist jedoch bei 499 Fehlern in Ihren Protokolldateien nicht der Fall.

13
mrki

In meinem Fall habe ich 499 erhalten, als die Client-API die Verbindung geschlossen hat, bevor sie eine Antwort erhält. Wörtlich eine POST gesendet und sofort die Verbindung geschlossen .. _. Dies wird mit der Option gelöst

proxy_ignore_client_abort am

Nginx doc

4
DerSkythe

Während Sie auf 499 zeigen, protokolliert der Nginx einen Verbindungsabbruch. In der Regel wird dies jedoch erzeugt, wenn Ihr Back-End-Server zu langsam ist und ein anderes Proxy-Timeout zuerst auftritt oder die Benutzersoftware die Verbindung abbricht. Prüfen Sie also, ob uWSGI schnell antwortet oder nicht, ob uWSGI/Database Server ausgelastet ist.

In vielen Fällen gibt es einige andere Proxys zwischen dem Benutzer und Nginx. Einige können sich in Ihrer Infrastruktur befinden, z. B. ein CDN, ein Load Balacer, ein Varnish-Cache usw. Andere können sich auf der Benutzerseite befinden, z. B. ein Caching-Proxy usw.

Wenn sich auf Ihrer Seite Proxys wie LoadBalancer/CDN befinden, sollten Sie die Zeitüberschreitungen so einstellen, dass zuerst das Backend und nach und nach die anderen Proxys für den Benutzer Zeitüberschreitungen auftreten.

Wenn Sie haben:

user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI

Ich empfehle Ihnen Folgendes einzustellen:

  • n Sekunden bis zum uWSGI-Timeout
  • n+1 Sekunden bis zum Nginx-Timeout
  • `n + 2 'dauert bis zum Timeout für Load Balancer
  • n+3 Sekunden Zeitüberschreitung zum CDN.

Wenn Sie einige Zeitüberschreitungen (wie CDN) nicht einstellen können, suchen Sie nach der Zeitüberschreitung und passen Sie die anderen entsprechend an (n, n-1...).

Dies stellt eine korrekte Kette von Zeitüberschreitungen bereit. und du wirst wirklich finden, wem das Timeout gibt und den richtigen Antwortcode an den Benutzer zurücksendet.

3
bartomeu

... kam hier von einer Google-Suche 

Ich habe die Antwort anderswo hier gefunden -> https://stackoverflow.com/a/15621223/1093174

was die Verbindungsleerzeit meines elastischen AWS-Lastverteilers erhöhen sollte!

(Ich hatte eine Django-Site mit nginx/Apache-Reverse-Proxy eingerichtet, und ein wirklich wirklich wirklich protokollierter Backend-Job/View hatte ein Timeout)

2
David Lam

Dieser Fehler lässt sich mit der Standard-Nginx-Konfiguration mit PHP-Fpm sehr einfach reproduzieren. 

Wenn Sie die Taste F5 auf einer Seite gedrückt halten, werden Dutzende Aktualisierungsanforderungen an den Server erstellt. Jede vorherige Anfrage wird vom Browser bei einer neuen Aktualisierung abgebrochen. In meinem Fall habe ich Dutzende von 499 in der Protokolldatei meines Online-Shops gefunden. Aus der Sicht von Nginx: Wenn die Antwort nicht an den Client übermittelt wurde, bevor die nächste Aktualisierungsanforderung den Fehler 499 protokolliert.

mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:32 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)

Wenn die php-fpm-Verarbeitung länger dauert (wie eine schwere Seite WP), kann dies natürlich Probleme verursachen. Ich habe zum Beispiel von Abstürzen von php-fpm gehört, aber ich glaube, sie können verhindert werden, dass Dienste ordnungsgemäß konfiguriert werden, z.

2
karvonen

Ich bin auf dieses Problem gestoßen und die Ursache war auf das Plugin von Kaspersky Protection im Browser zurückzuführen. Wenn Sie dies feststellen, deaktivieren Sie Ihre Plugins und prüfen Sie, ob das Problem dadurch behoben wird.

0
EGN

Ein Grund für dieses Verhalten könnte sein, dass Sie http für uwsgi anstelle von socket verwenden. Verwenden Sie den folgenden Befehl, wenn Sie uwsgi direkt verwenden. 

           uwsgi --socket :8080 --module app-name.wsgi

Der gleiche Befehl in der INI-Datei lautet

          chdir = /path/to/app/folder
          socket = :8080
          module = app-name.wsgi
0
Penkey Suresh

Nachdem ich 499 "Request wurde von Antivirus verboten" als AJAX http-Antwort erhalten (falsch positiv von Kaspersky Internet Security mit leichter heuristischer Analyse, tiefe heuristische Analyse wusste, dass nichts falsch war).

0
TeeJay