Hi,
>> Can you tell us more about this server? What OS is running? Any firewalls
>> (software or hardware)? Any other "security" product in between?
>> The server is announcing 1380 Byte MSS to me here as well, so this was
>> not something on your client side, but this is server side and thats not
>> very common. There must be some 'interesting' detail about this server
>> that we don't know yet.
>
> Not that I know of.
>
> It's all virtual servers, running CentOS 6. we have lots of servers with
> websites, running in the same environment - without ever having seen
> this issue :(
>
> These are behind a hardware firewall, in dmz (which nat's to the
> internal address) - but that's it.
The TCP handshake on the capture (server side) you sent me completes within
0,1ms. So what your firewall is doing is intercepting the tcp session. Its not
just "source nat and destination nat".
I assume you never see the real client's IP address in your log files?
But thats not the real problem. The real problem is that HAProxy sends the
"408 Request Time-out" response to the client 31ms after the TCP handshake
("tcp.stream eq 32" in with-http-client-timeout.pcap), prior to the client
sendings its request, although it should only sends this error after 10
seconds. Is it possible that your OS is jumping forwards and backwards in
time?
Try reproducing the 408 while running through "strace -tt" to confirm this.
Checkout [1] for advise on timejumps in a VM.
Regards,
Lukas
[1]
http://stackoverflow.com/questions/117422/how-can-i-resolve-the-drifting-clock-for-my-virtual-machine
