nginx schließt bei einigen Bildern die Verbindung


8

Es gibt ein Problem mit nginx. Die Verbindung wird geschlossen, bevor der Client den Download beendet. Es sieht aus wie:

 $ wget -O /dev/null http://www.site.com/images/theme/front/clean.jpg
--2012-07-11 21:37:03--  http://www.site.com/images/theme/front/clean.jpg
Resolving www.site.com (www.site.com)... 123.234.123.234
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 90707 (89K) [image/jpeg]
Saving to: `/dev/null'

26% [===============>                    ] 24,291      --.-K/s   in 8.7s    

2012-07-11 21:37:12 (2.74 KB/s) - Connection closed at byte 24291. Retrying.

--2012-07-11 21:37:13--  (try: 2)  http://www.site.com/images/theme/front/clean.jpg
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 90707 (89K), 66416 (65K) remaining [image/jpeg]
Saving to: `/dev/null'

53% [+++++++++++++++============>        ] 48,555      --.-K/s   in 8.7s    

2012-07-11 21:37:23 (2.74 KB/s) - Connection closed at byte 48555. Retrying.

--2012-07-11 21:37:25--  (try: 3)  http://www.site.com/images/theme/front/clean.jpg
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 206 Partial Content
Length: 90707 (89K), 42152 (41K) remaining [image/jpeg]
Saving to: `/dev/null'

100%[+++++++++++++++++++++++++++========>] 90,707      --.-K/s   in 0.1s    

2012-07-11 21:37:25 (311 KB/s) - `/dev/null' saved [90707/90707]

Gleichzeitig ist bei kleineren Bildern alles in Ordnung:

 $ wget -O /dev/null http://www.site.com/images/theme/front/grease.jpg
--2012-07-11 21:41:28--  http://www.site.com/images/theme/front/grease.jpg
Resolving www.site.com (www.site.com)... 123.234.123.234
Connecting to www.site.com (www.site.com)|123.234.123.234|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 21404 (21K) [image/jpeg]
Saving to: `/dev/null'

100%[====================================>] 21,404      --.-K/s   in 0.07s   

2012-07-11 21:41:29 (316 KB/s) - `/dev/null' saved [21404/21404]

Dies ist der Grund, warum dieses Bild im Browser nicht in voller Größe gezeichnet werden kann. Ich kann nur den Kopf davon sehen.

Nginx ist als Front-End und Apache als Back-End konfiguriert. Die direkte Verbindung zu Apache funktioniert gut, daher gibt es ein Problem mit Nginx. Habe ich recht?

nginx config:

user satellite;
worker_processes  1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
    multi_accept on;
}

http {
    include       /etc/nginx/mime.types;
    access_log  /var/log/nginx/access.log;

    sendfile        on;
    keepalive_timeout  0;
    tcp_nodelay        on;

    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    client_max_body_size 100m;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
    server {
            listen 123.234.123.234:80;
            server_name site.com www.site.com;
            location ~* ^/(admin/|dump/|webmail/|myadmin/|webim/) {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_redirect http://site.com:8080/ /;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
            }
            location / {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_redirect http://site.com:8080/ /;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_cache ino;
                    proxy_cache_valid 12h;
                    proxy_hide_header "Set-Cookie";
                    proxy_ignore_headers "Cache-Control" "Expires";
            }
            location ~* ^.+\.(jpg|swf|flv|ico|txt|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
                    access_log /home/satellite/logs/site.com.nginx.access.log;
                    error_page 404 = @fallback;
                    if ( $host ~* ^((.*).site.com)$ ) {
                            set $proot /home/satellite/www/$1;
                            break;
                    }
                    if ( $host = "www.site.com" ) {
                            break;
                    }
                    if ( $host = "site.com" ) {
                            break;
                    }

                    root /home/satellite/www/site.com;
            }
            location @fallback {
                    proxy_pass http://123.234.123.234:8080;
                    proxy_set_header Host $host;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                    proxy_set_header X-Real-IP $remote_addr;
            }
    }

Wo sollte ich graben, um dieses Problem zu beheben?


1
Haben Sie versucht, abzuschalten sendfile?
VBart

Ja, nichts hat sich geändert.
Eile

Antworten:


9

Die Hauptsache, die ich vergessen habe, ist zu überprüfen /var/log/nginx/error.log.

2012/07/12 08:46:44 [crit] 24074#0: *3 open() 
"/var/lib/nginx/proxy/1/00/0000000001" failed (13: Permission denied) 
while reading upstream, client: 109.173.96.30, server: site.com, request: 
"GET /images/theme/front/clean.jpg HTTP/1.1", upstream: 
"http://123.234.123.234:8080/images/theme/front/clean.jpg", 
host: "www.site.com", referrer: "http://www.google.com"

Also habe ich die /var/lib/nginx/proxy/*Verzeichnisberechtigungen ( sudo chown -R www-data:www-data /var/lib/nginx/proxy/*) korrigiert und jetzt funktioniert alles super. Vielen Dank für die Hilfe.


Danke dafür. Scheint ein offensichtlicher Rat zu sein, aber ich hatte es auch nicht überprüft. In meinem Fall war die Ursache folgende: [krit] 6 # 6: * 2577 mkdir () "/ var / cache / nginx / proxy_temp / 8" ist fehlgeschlagen (28: Kein Platz mehr auf dem Gerät) beim Lesen im Upstream
Damian Moore

1

Ein möglicher Grund für das Schließen der Verbindung ist eine langsame und eine kurze Verbindung keepalive_timeout. Der Standardwert für keepalive_timeoutist 75s. Wenn es zu kurz ist und die Verbindung langsam ist, wird sie möglicherweise zu früh geschlossen.

http {
    ..
    keepalive_timeout 75;
}

Ein Grund, warum Ihr Bilddownload langsam sein kann, ist Ihre Anwendung. Wenn Sie eine Ruby-on-Rails-Anwendung mit einer Asset-Pipeline in Kombination mit Nginx verwenden, kann der Bilddownload langsam sein, da Sie die falschen Bild-URLs verwenden (ohne von der Asset-Pipeline generierten Fingerabdruck). Die Rails-Helfer asset_path und image_tag generieren die richtigen URLs aus Dateien mit Fingerabdruck, die schnell heruntergeladen werden können.


1

Eine weitere sehr wichtige Sache, die Sie überprüfen sollten, ist: Stellen Sie sicher, dass noch Speicherplatz vorhanden ist!

Für mich war es wie folgt:

[user@server]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        30G   29G     0 100% /

Für mich war nginx nicht in der Lage, auf die Festplatte zu schreiben, was schließlich das gleiche Problem verursachte! Hoffe es hilft jemandem!


Bitte erläutern Sie, warum Ihrer Meinung nach ein Mangel an Speicherplatz dazu führen kann, dass eine TCP-Verbindung unerwartet geschlossen wird. Und wie das Öffnen einer neuen TCP-Verbindung dieses Problem vorübergehend löst.
Kasperd

1
Ja sicher! Hier ist ein Szenario: - Nginx arbeitet als Proxyserver - Es empfängt eine Datei von Apache - Nginx empfängt den ersten Block der Datei (Antwortcode 206) - Es schreibt den Block auf die Festplatte und sendet eine Anforderung für den nächsten Block - Es empfängt den nächsten Block und kann nicht auf die Festplatte schreiben, da kein Speicherplatz mehr vorhanden ist! - Nginx schließt die Verbindung mit dem Antwortcode 206. Der vollständige Inhalt wurde dem Client nicht bereitgestellt! Hoffe das klärt sich!
Raptor

1
In Rushs Fall wurde der erste Bildblock der Größe 24.291 erfolgreich empfangen. Dies bedeutet, dass bis zu ~ 24.291 von nginx direkt aus dem Speicher bedient werden können. Aus diesem Grund wurde das nächste Bild mit der Größe 21.404 erfolgreich bereitgestellt, da kein Festplattenschreiben erforderlich war.
Raptor

0

Ihre Download-Rate ist unglaublich niedrig. (2,74 KB / s!). Erhalten Sie das gleiche Ergebnis, wenn Sie wget auf demselben Computer ausführen, auf dem sich Nginx befindet? Es kann sein, dass Nginx über eine sehr langsame Verbindung angemessen auf eine Anfrage reagiert.

Ansonsten empfehle ich, die verschiedenen Zeitanweisungen in den Nginx-Dokumenten zu untersuchen . Suchen Sie nach jeder Erwähnung von "Timeout" auf der Seite und prüfen Sie, ob dies eine gute Übereinstimmung darstellt. Sie können beispielsweise sehen, dass das Zeitlimit in Intervallen von 10 Sekunden überschritten wird. Daher sollte jedes Zeitlimit, das etwa 10 Sekunden beträgt, einer zusätzlichen Prüfung unterzogen werden.

Die Direktive " verweilen_zeitüberschreitung" beträgt beispielsweise standardmäßig 10 Sekunden. Sie können dies also überprüfen.

Sie sollten auch untersuchen, warum die Verbindung zu Ihrem Client anscheinend so langsam ist.

Eine andere Idee: Probieren Sie einen alternativen Client aus curlund sehen Sie, dass Sie das gleiche Ergebnis erzielen wie mit wget. Wenn es gut curlfunktioniert, sollten Sie vermuten, wgetdass die Anfrage etwas Seltsames ist.


Das ist kein Client-Problem, denn selbst Firefox hat das gleiche Problem. Ich habe es von verschiedenen Maschinen in verschiedenen Geolokalisierungen versucht. Das gleiche Verhalten. Wie Sie bereits erwähnen können, ist die Geschwindigkeit auf kleinen Bildern ziemlich gut. ps. Auf einer Maschine, auf der sich Nginx befindet, ist alles in Ordnung. Also werde ich versuchen, mich mit der Timeout-Richtlinie zu befassen. pps. Das ist kein Netzwerkproblem, denn die direkte Apache-Verbindung zum selben Image funktioniert perfekt.
Eile

0

Überprüfen Sie den Wert für verweilende_Zeit in der Datei nginx.conf. Dies ist standardmäßig auf 30 Sekunden eingestellt. Dies bedeutet also, dass nginx maximal 30 Sekunden auf das Senden von Daten durch den Client wartet.

Wenn Sie einen Upload oder POST einer Datei durchführen, dessen Abschluss länger als 30 Sekunden dauern kann, setzt der Nginx-Server die Verbindung zum Client zurück, indem er ein RST-Paket an den Client sendet, wenn die Zeit zum Hochladen 30 Sekunden überschreitet.

Damit der Nginx länger auf das Abhören von Clientdaten wartet, setzen Sie diesen Wert auf einen höheren Wert.

Detaillierte Informationen zu verweilende_Zeit finden Sie hier verweilende_Zeit

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.