nginx закрывает соединение на некоторых картинках


8

Есть проблема с nginx. Он закрывает соединение до того, как клиент завершит загрузку. Это выглядит как:

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

в то же время с небольшими изображениями все в порядке:

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

Это причина, почему эта картинка не может быть нарисована в браузере в полном размере. Я могу видеть только голову этого.

Nginx настроен как front-end, а apache как back-end. Прямая ссылка на Apache работает хорошо, поэтому в nginx есть проблема. Я прав?

Конфигурация nginx:

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

куда мне копать, чтобы исправить эту проблему?


1
Вы пытались выключить sendfile?
VBart

Да, ничего не изменилось.
Раш

Ответы:


9

Главное, что я забыл, это проверить /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"

Так что я установил /var/lib/nginx/proxy/*директории permissions ( sudo chown -R www-data:www-data /var/lib/nginx/proxy/*) и теперь все отлично работает. Спасибо всем за помощь.


Спасибо за это. Кажется очевидным советом, но я тоже не проверял. В моем случае причина была в следующем: [crit] 6 # 6: * 2577 mkdir () "/ var / cache / nginx / proxy_temp / 8" не удалось (28: на устройстве не осталось места) при чтении в восходящем направлении
Дамиан Мур

1

Возможная причина закрытия соединения - медленное и короткое соединение keepalive_timeout. Значение по умолчанию для keepalive_timeout75 с. Если оно слишком короткое и соединение медленное, оно может быть закрыто слишком рано.

http {
    ..
    keepalive_timeout 75;
}

Одна из причин, почему загрузка вашего изображения может быть медленной - это ваше приложение. Если вы используете приложение Ruby-on-Rails с конвейером активов в сочетании с Nginx, загрузка изображений может быть медленной, поскольку вы используете неправильные URL-адреса изображений (без отпечатка пальца, сгенерированного конвейером ресурсов). Помощники Rails asset_path и image_tag генерируют правильные файлы форм URL с отпечатками пальцев, которые можно быстро загрузить.


1

Еще одна очень важная вещь, которую нужно проверить: убедитесь, что на диске осталось свободное место!

Для меня это было похоже на следующее:

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

Для меня nginx не смог записать на диск, что в итоге привело к той же проблеме! Надеюсь, это поможет кому-то!


Пожалуйста, объясните, почему вы думаете, что недостаток дискового пространства может привести к неожиданному закрытию соединения TCP. И как открытие нового TCP-соединения временно решит эту проблему.
kasperd

1
Да, конечно! Вот сценарий: - Nginx работает как прокси-сервер - Он получает файл от Apache - Nginx получает первый кусок файла (код ответа 206) - Он записывает кусок на жесткий диск и отправляет запрос на следующий кусок - Он получает следующий блок и не может записать на жесткий диск, так как не осталось места! - Nginx закрывает соединение с кодом ответа 206. Полный контент не был передан клиенту! Надеюсь, что это проясняет!
Raptor

1
В случае Раша был успешно получен первый фрагмент изображения размером 24 291. Это означает, что nginx может обслуживать до ~ 24 291 непосредственно из памяти. Вот почему следующее изображение размером 21,404 было успешно обработано, так как не требовало записи на жесткий диск.
Raptor

0

Ваша скорость загрузки невероятно низкая. (2,74 КБ / с!). Получаете ли вы тот же результат при запуске wget на той же машине, где находится Nginx? Возможно, Nginx разумно реагирует на запрос по очень медленной ссылке.

В противном случае, я рекомендую изучить различные временные директивы в документации Nginx . Ищите все упоминания о «тайм-ауте» на странице и посмотрите, найдете ли вы подходящее совпадение. Например, вы можете видеть, что время истекает с интервалами в 10 секунд, поэтому любой тайм-аут, составляющий около 10 секунд, должен подвергаться дополнительной проверке.

Например, директива lingering_timeout по умолчанию равна 10 секундам, так что вы можете проверить это.

Вы также должны выяснить, почему соединение с вашим клиентом, по-видимому, так медленно.

Другая идея: попробуйте альтернативный клиент, например curl, и убедитесь, что вы получите тот же результат, что и с wget. Если все curlработает нормально, вы должны подозревать, что есть что-то странное в wgetтом, чтобы сделать запрос


Это не проблема клиента, потому что даже Firefox имеет ту же проблему. Я пробовал это с другой машины в разных геолокациях. Такое же поведение. Кроме того, как вы можете заметить, на маленькой картинке скорость довольно хорошая. пс. На машине, где расположен nginx, все в порядке. Поэтому я попытаюсь покопаться в директиве тайм-аута. имп. Это не проблема сети, потому что прямая apache-ссылка на одно и то же изображение прекрасно работает.
Раш

0

Проверьте значение lingering_time в nginx.conf. По умолчанию будет установлено значение 30 секунд. Итак, что это будет делать, так это то, что nginx будет ждать максимум 30 секунд, пока клиент отправит данные.

Если вы выполняете загрузку или POST файла, который может занять более 30 секунд, то сервер nginx сбросит соединение с клиентом, отправив клиенту пакет RST, если время загрузки превышает 30 секунд.

Чтобы nginx ожидал больше времени для прослушивания данных клиента, установите для этого значения более высокое значение.

Подробную информацию о lingering_time смотрите здесь lingering_time

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.