nginx cierra la conexión en algunas fotos

8

Hay un problema en esta nginx. Cierra la conexión antes de que el cliente finalice la descarga. Parece que:

 $ 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]

al mismo tiempo con imágenes más pequeñas, todo está bien: 

 $ 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]

Esta es la razón por la cual esta imagen no se puede dibujar a tamaño completo en el navegador. Solo puedo ver la cabeza.

Nginx está configurado como front-end y apache como back-end. El enlace directo a apache funciona bien, por lo que hay un problema en nginx. Estoy en lo cierto?

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;
            }
    }

¿Dónde debo cavar para solucionar este problema?

nginx  web-server 
— prisa
fuente
1
¿Intentaste apagar sendfile?
— VBart
Sí, nada ha cambiado.
— prisa el

Respuestas:

9

Lo principal que olvidé es verificar /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"

Así que arreglé los /var/lib/nginx/proxy/*permisos de directorios ( sudo chown -R www-data:www-data /var/lib/nginx/proxy/*) y ahora todo funciona muy bien. Gracias a todos por la ayuda.

— prisa
fuente
Gracias por esto. Parece un consejo obvio, pero tampoco lo había comprobado. En mi caso, la causa fue la siguiente: [crit] 6 # 6: * 2577 mkdir () "/ var / cache / nginx / proxy_temp / 8" falló (28: No queda espacio en el dispositivo) mientras se leía el flujo ascendente
— Damian Moore
1

Una posible razón para el cierre de la conexión es una conexión lenta y corta keepalive_timeout. El valor predeterminado para el keepalive_timeoutes 75s. Si es demasiado corto y la conexión es lenta, entonces podría cerrarse demasiado pronto.

http {
    ..
    keepalive_timeout 75;
}

Una razón por la cual la descarga de su imagen podría ser lenta es su aplicación. Si está utilizando una aplicación Ruby-on-Rails con una canalización de activos en combinación con Nginx, entonces la descarga de la imagen podría ser lenta porque está utilizando las URL de imagen incorrectas (sin huella digital generada por la canalización de activos). Los ayudantes de Rails asset_path y image_tag generan los archivos de formulario de URL correctos con huella digital que se pueden descargar rápidamente.

— 0x4a6f4672
fuente
1

Otra cosa muy importante para verificar es: ¡Asegúrese de que le quede espacio en el disco!

Para mí fue como lo siguiente:

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

¡Para mí, nginx no pudo escribir en el disco y finalmente causó el mismo problema! Espero que ayude a alguien!

— Rapaz
fuente
Explique por qué cree que la falta de espacio en disco puede hacer que una conexión TCP se cierre inesperadamente. Y cómo abrir una nueva conexión TCP resolverá temporalmente ese problema.
— kasperd el
1
¡Si seguro! Aquí hay un escenario: - Nginx funciona como un servidor Proxy - Está recibiendo un archivo de Apache - Nginx recibe el primer fragmento del archivo (código de respuesta 206) - Escribe el fragmento en el disco duro y envía la solicitud para el siguiente fragmento - ¡Recibe el siguiente fragmento y falla la escritura en el disco duro ya que no queda espacio! - Nginx cierra la conexión con el código de respuesta 206. ¡El contenido completo no se entregó al cliente! Espero que eso aclare!
— Raptor
1
En el caso de Rush, se recibió con éxito la primera porción de imagen del tamaño 24,291. Lo que significa que nginx puede servir hasta ~ 24,291 directamente desde la memoria. Es por eso que la siguiente imagen con un tamaño de 21,404 se sirvió con éxito, ya que no requería escritura en HDD.
— Raptor
0

Su velocidad de descarga es increíblemente baja. (2.74 KB / s!) ¿Obtiene el mismo resultado cuando ejecuta wget en la misma máquina donde se encuentra Nginx? Podría ser que Nginx esté reaccionando razonablemente a una solicitud a través de un enlace muy lento.

De lo contrario, recomiendo explorar las diversas directivas de tiempo en los documentos de Nginx . Busque cada mención de "tiempo de espera" en la página y vea si encuentra que es una buena coincidencia. Por ejemplo, puede ver que está agotando el tiempo en lo que parecen ser intervalos de 10 segundos, por lo que cualquier tiempo de espera de unos 10 segundos debería recibir un escrutinio adicional.

Por ejemplo, la directiva lingering_timeout está predeterminada en 10 segundos, por lo que puede verificar eso.

También debe investigar por qué la conexión con su cliente es aparentemente tan lenta.

Otra idea: pruebe con un cliente alternativo, como curl, y vea que obtiene el mismo resultado que con wget. Si curlfunciona bien, debe sospechar que hay algo extraño en wgethacer la solicitud.

— Mark Stosberg
fuente
Eso no es problema del cliente, porque incluso Firefox tiene el mismo problema. Lo probé desde diferentes máquinas en diferentes geolocalizaciones. El mismo comportamiento. Además, como puedes mencionar, la velocidad es bastante buena en imágenes pequeñas. PD. En la máquina donde se encuentra nginx, todo está bien. Así que intentaré profundizar en la directiva de tiempo de espera. pps. Eso no es un problema de red, porque el enlace directo de apache a la misma imagen funciona perfectamente.
— prisa el
0

Compruebe el lingering_time valor en nginx.conf. Esto se establecerá por defecto en 30 segundos. Entonces, lo que esto hará es que nginx esperará un máximo de 30 segundos para que el cliente envíe datos.

Si está realizando una carga o POST de un archivo que puede tardar más de 30 segundos en completarse, entonces el servidor nginx restablecerá la conexión al cliente enviando un paquete RST al cliente si el tiempo de carga supera los 30 segundos.

Para que nginx espere más tiempo para escuchar los datos del cliente, establezca este valor en un valor más alto.

Para obtener información detallada sobre lingering_time, míralo aquí lingering_time

— Sanath Holla
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.