Varnish sending incomplete responses when nuking objects

James Mathiesen jmathiesen at
Mon Dec 11 14:10:25 UTC 2017

I have caching turned off at the moment because of this (not a big deal -- the cache hit rate would be very low regardless).

It's a bit awkward to work around and this is the only case I can think of where varnish would cause a request that would otherwise succeed to fail.

I'm planning to have multiple caches (small object cache + large object cache for example) but this would not be possible if the response used chunked transfer encoding.

Setting nuke limit very high would work with chunked transfers but also makes it possible for a single response to evict everything else in the cache.


From: varnish-misc < at> on behalf of Carlos Abalde <carlos.abalde at>
Date: Monday, December 11, 2017 at 4:11 AM
To: Radu Moisa <rmoisa at>
Cc: varnish-misc <varnish-misc at>
Subject: Re: Varnish sending incomplete responses when nuking objects

On 11 Dec 2017, at 07:51, Radu Moisa <rmoisa at<mailto:rmoisa at>> wrote:


Thanks a lot for the hint!

Just so that I understand it better, nuke_limit is the "Maximum number of objects we attempt to nuke in order to make space for a object body."
If I set it to something like 9999999, varnish will throw out only the number of objects needed to make room for the new request, not the nuke_limit number of objects, right?

Yes, that's right. While trying to store an object in the cache, if not enough free space is available, Varnish will nuke up to 'nuke_limit' objects. This will happen incrementally, while the object is being fetched from the backend, stored in the cache, and eventually also being streamed to one or more clients. If the 'nuke_limit' is reached the object won't be cached and client responses will be closed (and therefore clients will end up with a truncated response).


Carlos Abalde

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the varnish-misc mailing list