it-swarm.com.de

Nginx uwsgi (104: Verbindung wurde von Peer zurückgesetzt), während der Antwortheader aus dem Upstream gelesen wird

Umgebung ist Nginx + uwsgi.

Nginx-Fehler bei bestimmten GET-Anforderungen wurde von 502 wegen eines fehlerhaften Gateways gemeldet Scheint auf die Länge der URL bezogen zu sein. In unserem speziellen Fall war es eine lange Liste von GET-Parametern. Kürzen Sie die GET-Parameter und keinen 502-Fehler.

Aus dem nginx/error.log

[error] 22113#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.100, server: server.domain.com, request: "GET <long_url_here>"

Keine Informationen im uwsgi-Fehlerprotokoll.

39
user3470130

Nachdem ich viel Zeit damit verbracht hatte, fand ich es endlich heraus. Es gibt viele Verweise auf Nginx und das Zurücksetzen der Verbindung durch Peer. Die meisten von ihnen schienen mit PHP verwandt zu sein. Ich konnte keine Antwort finden, die spezifisch für Nginx und Uwsgi war.

Ich fand schließlich einen Verweis auf fastcgi und einen fehlerhaften 502-Gateway-Fehler ( https://support.plesk.com/hc/en-us/articles/213903705 ). Das hat mich veranlasst, nach einer Puffergrößenbegrenzung in der uwsgi-Konfiguration zu suchen, die als buffer-size existiert. Der Standardwert ist 4096. In der Dokumentation heißt es:

Wenn Sie große Anfragen mit vielen Kopfzeilen erhalten möchten, können Sie diesen Wert auf bis zu 64.000 (65535) erhöhen.

Es gibt viele Möglichkeiten, uwsgi zu konfigurieren. Ich verwende zufällig eine .ini-Datei. Also habe ich in meiner .ini-Datei versucht:

buffer-size=65535

Das Problem wurde behoben. Sie können das nach Geschmack einstellen. Beginnen Sie vielleicht mit dem Maximum und arbeiten Sie zurück, bis Sie einen akzeptablen Wert haben, oder lassen Sie es einfach auf das Maximum.

Es war frustrierend, das aufzuspüren, da auf der Uwsgi-Seite keine Fehler aufgetreten sind.

74
user3470130

Ich habe den gleichen Nginx-Fehler erhalten und es gab auch keine Informationen in uwsgi log. Das Problem war, dass die Anwendung in einigen Fällen nicht den gesamten Anforderungskörper verbrauchte, wie in http://uwsgi-docs.readthedocs.org/de/latest/ThingsToKnow.html empfohlen.

Wenn eine HTTP-Anforderung einen Textkörper enthält (wie eine POST Anforderung, die von einem Formular generiert wird), müssen Sie sie in Ihrer Anwendung lesen (verbrauchen). Wenn Sie dies nicht tun, kann der Kommunikationssockel Ihres Webservers beeinträchtigt werden. Wenn Sie faul sind, können Sie die Nachpufferungsoption verwenden, die automatisch Daten für Sie liest. Bei Rack-Anwendungen ist dies automatisch aktiviert.

Natürlich ist dies in Ihrem Fall kein Problem, aber es kann für andere nützlich sein, die denselben Nginx-Fehler erhalten.

3
Rinas

Danke, die gleiche Lösung wird im Fall eines PHP Servers verwendet. Wir müssen nur den Attributwert "output_buffering" in php.ini auf einen größeren Wert wie 65535 oder einen anderen geeigneten Wert erhöhen.

3
Eduan Lenine

Wenn wir eine Nachricht wie (104: Connection reset by peer) while reading response header from upstream erhalten, könnten wir meistens die Upstream-Seite dieser Art von Fehler beschuldigen.

Wie beschrieben, wurde die Verbindung vom Upstream-Peer zurückgesetzt, nicht von Nginx selbst. Nginx kann als Kunde kaum etwas dagegen tun.

Ich vermute, ob das Ändern der Puffergröße die Magie bewirkt. Grundsätzlich ändert der Befehl die Puffergröße, in der Antwort-Header zwischengespeichert werden. Dies würde wirksam werden, wenn der Antwortheader zu groß ist. In diesem Fall erhalten Sie eine Nachricht mit der Aufschrift upstream sent too big header while reading response header from upstream. Dies ist eine völlig andere Sache als connection reset by peer.

Da diese Art von Fehler zufällig ausgelöst wird, sollten Sie prüfen, ob nginx keepalive verwendet, wenn Sie mit Upstreams sprechen. Wenn dies der Fall war, wurde die Verbindung möglicherweise vom Upstream-Server zurückgesetzt, wenn das Zeitlimit überschritten wurde, während nginx keine Ahnung hatte, dass die Verbindung getrennt wurde. 

Es gibt keine elegante Lösung, so weit ich weiß. Sie können versuchen, den Wert des Upstream-Verbindungspools in nginx erneut mit dem Wert keepalive_timeout zu versehen, um das Problem zu vermeiden.

referenzierung:

Apache HttpClient-Zwischenfehler: NoHttpResponseException

http://tengine.taobao.org/document/http_upstream_keepalive_timeout.html

0
bjrara

--post-buffering 32768 arbeitete für mich wie vorgeschlagen (und entmutigt) hier NGINX + uWSGI Connection Reset by Peer

Momentan habe ich keine Zeit, das Thema genauer zu untersuchen (Quick-Prototyping-Modus :), aber da ich lange gebraucht habe, um diesen Hack zu finden, könnte es sich lohnen, hier zu posten.

0