Opened 8 weeks ago

Last modified 7 weeks ago

#1472 accepted enhancement

Downloads stop after 1GB depending of network

Reported by: nudgegoonies@… Owned by:
Priority: minor Milestone:
Component: nginx-module Version:
Keywords: proxy Cc:
uname -a: Linux NAME 4.9.0-0.bpo.5-amd64 #1 SMP Debian 4.9.65-3+deb9u2~bpo8+1 (2017-01-05) x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.12.2 built by gcc 4.9.2 (Debian 4.9.2-10) built with OpenSSL 1.0.1t 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/ --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'


we tried nginx version 1.6.2 till version 1.12.2 and have a problem when used as proxy before artifactory. Downloads get interrupted at 1GB.

This behavior depends on the internal VLAN. On one VLAN this always happens. On an other VLAN it never happens. This is size limited, not time limited. From some network it stops after 30 seconds and from one other slow network it stops after 13 minutes.

We made a minimal proxy setup with apache and this works with all VLANs. This is why we expect it has something to do with nginx or the combination of nginx and TCP/IP stack of linux.

In wireshark we see "TCP Dup ACK" on the client side sent to the nginx server.

Wget fails with connection closed at byte 1083793011 but continues download with partial content. docker can't handle this and our customers can't download docker images with layers greater 1 GB.

The following text shows two anonymized minimal configs. The nginx config that is problematic and the apache config that works:

NGINX config:
server {
    listen *:80;
    server_name NAME;
    client_max_body_size 3G;
    access_log /var/log/nginx/NAME.access.log;
    error_log /var/log/nginx/NAME.error.log;

    if ($request_uri !~ /artifactory/) {
        rewrite ^ $scheme://NAME/artifactory/ permanent;

    location /artifactory {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://ARTIFACTORY:PORT;
        proxy_pass_header Server;
        proxy_read_timeout 90s;

APACHE config:
<VirtualHost *:80>
    ServerName NAME
    ServerAdmin NAME

    ErrorLog ${APACHE_LOG_DIR}/error.log

    LogLevel warn

    ProxyRequests Off
    <Proxy *>
      Order allow,deny
      Allow from All

    ProxyPass / http://ARTIFACTORY:PORT/
    ProxyPassReverse / http://ARTIFACTORY:PORT/

Change History (3)

comment:1 Changed 7 weeks ago by mdounin

The 1GB limit suggests that the problem is due to proxy_max_temp_file_size. It is one gigabyte by default, and if the limit is reached, nginx will stop reading from the backend till all disk-buffered data are sent to the client. This in turn can result in a send timeout on the backend side.

Please check nginx and your backend logs to see what happens here. Likely there are something like "upstream prematurely closed connection" in nginx error log, and send timeouts in your backend logs. Alternatively, just check if proxy_max_temp_file_size 0; helps (this will disable disk buffering completely).

If the above suggestion is true, the two possible solutions are:

  • Tune proxy_max_temp_file_size. Consider either configuring the limit above the size of all expected responses, or small enough for your backend to don't time out. In particular, proxy_max_temp_file_size 0; might be a good choice when proxying large files.
  • Tune your backend timeouts appropriately.

comment:2 Changed 7 weeks ago by nudgegoonies@…

This was it! Thank you very much for your answer!

We used the first solution and raised the limit.

We were so confused because the circumstances with the different networks. We already tried throttleing and stuff to reproduce it.

comment:3 Changed 7 weeks ago by mdounin

  • Status changed from new to accepted
  • Type changed from defect to enhancement
  • Version 1.12.x deleted

Ok, thanks for the confirmation.

For the record, this seems to be more or less typical problem, reported from time to time (see here for an example). While this behaviour is not a bug, we might consider doing some improvements to make such timeouts less likely to happen. In particular, reviving and improving the p->cyclic_temp_file feature (currently disabled in all modules) might be the way to go.

Note: See TracTickets for help on using tickets.