Varnish 3.0.5 round robin diretor sem balanceamento

Question

Eu tenho uma arquitetura com dois servidores de verniz na frente de 5 webheads. Cada servidor de verniz é configurado com um diretor backend de round robin, mas em tempos de verniz de carga moderada a alta parece estar favorecendo strongmente o primeiro backend definido na lista.

Versão do verniz é 3.0.5.

Se o primeiro back-end estiver marcado como doente, o segundo back-end da lista será muito favorecido, e assim por diante.

varnish> backend.list
200
Backend name                   Refs   Admin      Probe
web1(************,,8080)       102    probe      Healthy 8/8
web2(************,,8080)       17     probe      Healthy 8/8
web3(************,,8080)       9      probe      Healthy 8/8
web4(************,,8080)       17     probe      Healthy 8/8
web5(************,,8080)       12     probe      Healthy 8/8

Algumas partes da VCL que podem ser pertinentes:

probe healthcheck {
   .request =
         "GET /LICENSE.txt HTTP/1.1"
         "Host: **********.co.uk"
         "Connection: close";
   .interval = 120s;
   .timeout = 90s; # High values due to expected slow responses
   .window = 8;
   .threshold = 3;
   .initial = 3;
   #.expected_response = 200; # Still want the Magento maintenance page to display so no response code check
}

backend web1 {
    .host = "************";
    .port = "8080";
    .connect_timeout = 240s; # High values due to expected slow responses
    .first_byte_timeout = 240s; # High values due to expected slow responses
    .between_bytes_timeout = 240s; # High values due to expected slow responses
    .probe = healthcheck;
}
backend web2 {
    .host = "************";
    .port = "8080";
    .connect_timeout = 240s; # High values due to expected slow responses
    .first_byte_timeout = 240s; # High values due to expected slow responses
    .between_bytes_timeout = 240s; # High values due to expected slow responses
    .probe = healthcheck;
}
backend web3 {
    .host = "************";
    .port = "8080";
    .connect_timeout = 240s; # High values due to expected slow responses
    .first_byte_timeout = 240s; # High values due to expected slow responses
    .between_bytes_timeout = 240s; # High values due to expected slow responses
    .probe = healthcheck;
}
backend web4 {
    .host = "************";
    .port = "8080";
    .connect_timeout = 240s; # High values due to expected slow responses
    .first_byte_timeout = 240s; # High values due to expected slow responses
    .between_bytes_timeout = 240s; # High values due to expected slow responses
    .probe = healthcheck;
}
backend web5 {
    .host = "************";
    .port = "8080";
    .connect_timeout = 240s; # High values due to expected slow responses
    .first_byte_timeout = 240s; # High values due to expected slow responses
    .between_bytes_timeout = 240s; # High values due to expected slow responses
    .probe = healthcheck;
}

director backend_director round-robin {
    { .backend = web1; }
    { .backend = web2; }
    { .backend = web3; }
    { .backend = web4; }
    { .backend = web5; }
}

sub vcl_recv {
    set req.backend = backend_director;

    # loads more stuff
}

Alguém pode esclarecer por que o diretor do round robin favoreceria tão strongmente o primeiro backend definido, ou o que poderia causar um bypass do diretor completamente? Eu já assegurei que return(pipe) não é usado em vcl_recv.