Greetings. I've joined this list after bringing this problem to the haproxy IRC channel and it being suggested that I try here.
I've got haproxy and apache on separate VMs in the same environment. When I download slowly (naturally across the internet or artificially with curl --limit-rate) I often get a connection failure near the end of the transfer. Usually at 99%, rarely as early as 87% on especially slow connections. If I make my download request directly to the apache server then there are no failures. Here is the tail end of a tcpdump on the haproxy server during such a failure: 12:09:59.719048 IP HAPROXYIP.http > CLIENTIP.64339: Flags [.], seq 25815027:25817831, ack 128, win 220, options [nop,nop,TS val 334759695 ecr 1732745683], length 2804 12:09:59.719057 IP HAPROXYIP.http > CLIENTIP.64339: Flags [.], seq 25817831:25820635, ack 128, win 220, options [nop,nop,TS val 334759695 ecr 1732745683], length 2804 12:09:59.719065 IP HAPROXYIP.http > CLIENTIP.64339: Flags [.], seq 25820635:25823439, ack 128, win 220, options [nop,nop,TS val 334759695 ecr 1732745683], length 2804 12:09:59.719072 IP HAPROXYIP.http > CLIENTIP.64339: Flags [.], seq 25823439:25826243, ack 128, win 220, options [nop,nop,TS val 334759695 ecr 1732745683], length 2804 12:09:59.723855 IP CLIENTIP.64339 > HAPROXYIP.http: Flags [.], ack 25812223, win 1037, options [nop,nop,TS val 1732745686 ecr 334759695], length 0 12:09:59.724240 IP CLIENTIP.64339 > HAPROXYIP.http: Flags [.], ack 25820635, win 512, options [nop,nop,TS val 1732745686 ecr 334759695], length 0 12:09:59.923407 IP HAPROXYIP.http > CLIENTIP.64339: Flags [.], seq 25826243:25827645, ack 128, win 220, options [nop,nop,TS val 334759746 ecr 1732745686], length 1402 12:09:59.923465 IP HAPROXYIP.http > CLIENTIP.64339: Flags [R.], seq 25827645, ack 128, win 220, options [nop,nop,TS val 334759746 ecr 1732745686], length 0 12:09:59.923905 IP CLIENTIP.64339 > HAPROXYIP.http: Flags [.], ack 25826243, win 1213, options [nop,nop,TS val 1732745882 ecr 334759695], length 0 12:09:59.923933 IP HAPROXYIP.http > CLIENTIP.64339: Flags [R], seq 4290808590, win 0, length 0 Here is the haproxy log entry for that same transfer: lb02/messages:Sep 8 12:09:58 lb02 haproxy[19704]: CLIENTIP:64339 [08/Sep/2014:12:05:53.211] LISTEN LISTEN/SERVER 0/0/0/2/245710 200 25978565 - - ---- 40/40/21/5/0 0/0 "GET /path/to/25MBfile HTTP/1.1" 25978565 is the correct size for the file. 25827273 is how many bytes the client received. It seems like the haproxy logging facility thinks that the transfer was successful (hence the ---- status result and correct file size in the log entry). However, something that I can't identify is initiating that tcp reset before all the bytes go across the network. I'd like to figure out what.
