Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm getting intermittent guru meditations in varnish (as in I fire 50 requests off and 3 come back bad). In varnishlog it says

   15 VCL_return   c hash
   15 HitPass      c 1394372109
   15 VCL_call     c pass pass
   15 Backend      c 17 default default
   15 TTL          c 1394372164 RFC 0 -1 -1 1384590297 0 1384590291 0 0
   15 VCL_call     c fetch
   15 TTL          c 1394372164 VCL 120 -1 -1 1384590297 -0
   15 VCL_return   c hit_for_pass
   15 ObjProtocol  c HTTP/1.1
   15 ObjResponse  c OK
   15 ObjHeader    c Date: Sat, 16 Nov 2013 08:24:51 GMT
   15 ObjHeader    c Server: Apache
   15 ObjHeader    c Accept-Ranges: bytes
   15 ObjHeader    c Cache-Control: max-age=0, no-cache
   15 ObjHeader    c Vary: Accept-Encoding
   15 ObjHeader    c X-Mod-Pagespeed:
   15 ObjHeader    c Content-Encoding: gzip
   15 ObjHeader    c Content-Type: text/html; charset=utf-8
   15 Gzip         c u F - 3755 13624 80 0 0
   15 FetchError   c TestGunzip error at the very end
   15 VCL_call     c error deliver
   15 VCL_call     c deliver deliver
   15 TxProtocol   c HTTP/1.1
   15 TxStatus     c 503
   15 TxResponse   c Service Unavailable

You can see the 15 FetchError c TestGunzip error at the very end which is the problem. I'm not sure how to interpret the line above Gzip c u F - 3755 13624 80 0 0 and I can't see why this is a problem. The site did not have any reported problem loading pages before we put varnish in front.

In an assumption that varnish is just being more strict about gzip than the browsers are, I attempted to turn off the gzip handling, so I set http_gzip_support to off in /etc/defaults/varnish:

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m \
             -p http_gzip_support=off"

This has failed to make any difference. I've now run out of ideas, any help would be greatly appreciated.

share|improve this question

This is the fix

if (beresp.status == 301 || beresp.status == 302) {
  if (beresp.http.Content-Encoding ~ "gzip") {
    if (beresp.http.Content-Length == "0") {
      unset beresp.http.Content-Encoding;
share|improve this answer
Some more explanation would be appreciated in this answer. – kasperd Aug 20 '15 at 12:57
if (req.http.Accept-Encoding) {
    if (req.http.Accept-Encoding ~ "gzip") {
      # If the browser supports it, we'll use gzip.
      #set req.http.Accept-Encoding = "gzip";
      unset req.http.Accept-Encoding;
    else if (req.http.Accept-Encoding ~ "deflate") {
      # Next, try deflate if it is supported.
      set req.http.Accept-Encoding = "deflate";
    else {
      # Unknown algorithm. Remove it and send unencoded.
      unset req.http.Accept-Encoding;

I put the unset Accept-Encoding and when the response comes back from the backend it doesn't try to TestGunZip it. Thats what it seems like. This is my fix i have because i too have had the same issues.

share|improve this answer

Sometimes the various backends need more time to load a response for varnish, simply increasing the following usually helps:

backend default {
  .host = "x";
  .port = "x";
  .connect_timeout = 30s;
  .first_byte_timeout = 30s;
  .between_bytes_timeout = 30s;
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.