Eu tive um problema similar , não muito tempo atrás - e a causa acabou por ser o SELinux.
Se o HAProxy estiver sendo executado em uma porta privilegiada (abaixo de 1024), mas seus servidores de aplicativos estiverem sendo executados em portas superiores e sem privilégios, o cenário a seguir é bem plausível.
A configuração do SELinux de algumas configurações (por exemplo, um CentOS padrão) impedirá que o Varnish se conecte a uma porta privilegiada. Se você tiver auditd em execução, poderá verificar isso no seu log de auditoria.
Por exemplo, em uma instalação limpa do CentOS 6.2, (quando meu servidor de back-end estiver em execução na porta 81):
grep varnish /var/log/audit/audit.log :
type=AVC msg=audit(1331500393.450:25): avc: denied { name_connect } for pid=1276 comm="varnishd" dest=81 scontext=unconfined_u:system_r:varnishd_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket
O estado atual da aplicação do SELinux pode ser determinado com:
cat /selinux/enforce
(Onde 1 está aplicando e 0 é permissivo).
Se o problema acima parecer ser o seu, configure o SELinux para temporariamente permissivo e confirme:
echo 0 >/selinux/enforce
Se você confirmar que este é, de fato, o seu problema, você pode usar audit2allow -a -w (parte do pacote policycoreutils-python no CentOS) para analisar seu log de auditoria e gerar as regras necessárias, ou você pode tentar o seguinte:
setsebool -P varnishd_connect_any 1