With 1.5-dev22, we have a scenario where haproxy is saying the client closed the connection, but really the server is the one that closed it.
Here is the log entry from haproxy: haproxy[12540]: 10.230.0.195:33580 storage_upd storage_upd/storage_upd_2 0/0/0/522/555 0/0/0/0/0 0/0 412/271 200 CD-- 73E3-20FF5 + GET /1/public_link/1BMcSfqg3OM4Ng HTTP/1.1 The log format is defined as: capture request header X-Request-Id len 64 log-format %ci:%cp\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %U/%B\ %ST\ %tsc\ %hrl\ +\ %r Attached is the haproxy config, along with a packet capture between haproxy and the backend server. The packet capture shows that the backend server listening on port 4001 sent a TCP FIN packet to haproxy first. Therefore haproxy shouldn't have logged it with "C---" -Patrick
global
log 127.0.0.1 local0
maxconn 20480
user haproxy
group haproxy
daemon
stats socket /var/run/haproxy.sock
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
timeout connect 5000
timeout client 60000
timeout server 170000
option clitcpka
option srvtcpka
option abortonclose
option splice-auto
stats enable
stats uri /haproxy/stats
stats refresh 5
stats auth user:pass
frontend storage_upd
bind 0.0.0.0:80
bind 0.0.0.0:81 accept-proxy
default_backend storage_upd
maxconn 20000
capture request header X-Request-Id len 64
http-request add-header X-Request-Timestamp %Ts.%ms
log-format %ci:%cp\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\
%ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %U/%B\ %ST\ %tsc\ %hrl\ +\ %r
backend storage_upd
fullconn 20000
server storage_upd_1 127.0.0.1:4000 check
server storage_upd_2 127.0.0.1:4001 check
server storage_upd_3 127.0.0.1:4002 check
server storage_upd_4 127.0.0.1:4003 check
haproxy.pcap
Description: Binary data
