Hello,
I have an issue when trying to track a connection based on a header, with tcp-request, and with keep alive enable in a listen section. Over the haproxy i have a cdn, which pass the ip of the client at the beginning of the X-Forwarded-For header. All the requests are pass through this cdn. This is the configuration: global maxconn 1000 log 127.0.0.1 local5 info err stats socket /var/run/haproxy.sock mode 0600 level admin pidfile /var/run/haproxy.pid defaults mode http log global retries 3 option redispatch timeout connect 5s timeout client 10s timeout server 10s timeout http-keep-alive 60s timeout http-request 5s listen proxy-http 192.168.1.100:80 mode http maxconn 1000 balance roundrobin stats enable option httplog option http-server-close #option httpclose option forwardfor stick-table type ip size 128m expire 30m store gpc0 tcp-request inspect-delay 5s tcp-request content track-sc0 req.hdr_ip(X-Forwarded-For,1) if HTTP acl rule_marked_deny sc0_get_gpc0 gt 0 use_backend back-deny if rule_marked_deny default_backend back-http backend back-deny server web-deny 192.168.1.133:80 backend back-http server web-http 192.168.1.101:80 With this conf, all the requests with the header X-Forwarded-For are tracked in the sc0 counter with the ip included in it. If the counter of one ip is update to number one, the request will be send to back-deny, this is doing by writing directly in the unix socket from other software. Like the example: # echo "set table proxy-http key 88.64.32.11 data.gpc0 1" | socat stdio /var/run/haproxy.sock Since the moment that this are doing (with keep alive enable) i see that in the log of the web-deny backserver (the log are modified for register the x-forwarded-for ip instead of the real tcp connection): 88.64.32.11 - - [30/Aug/2013:09:08:22 +0200] www.server.com "GET /some/url HTTP/1.1" 301 208 157.55.32.236 - - [30/Aug/2013:09:08:27 +0200] www.server.com "GET /some/url HTTP/1.1" 301 208 88.64.32.11 - - [30/Aug/2013:09:08:27 +0200] www.server.com "GET /some/url HTTP/1.1" 301 208 157.55.32.236 - - [30/Aug/2013:09:08:28 +0200] www.server.com "GET /some/url HTTP/1.1" 301 208 88.64.32.11 - - [30/Aug/2013:09:08:29 +0200] www.server.com "GET /some/url HTTP/1.1" 301 208 157.56.93.186 - - [30/Aug/2013:09:08:31 +0200] www.server.com "GET /some/url HTTP/1.1" 301 208 157.56.93.186 - - [30/Aug/2013:09:08:31 +0200] www.server.com "GET /some/url HTTP/1.1" 301 208 As can see, there are other ips there and only one is with the "1" in the table of the Haproxy. This is a small piece of log, but when i try that in a server with more traffic, the problem is worse, more ips are redirected to this backend without marked for it. But, if i change the listen secion to "option httpclose", all works well, only the marked ips are redirected. Problem solved, but why? The tcp inspect have problems tracking the request when these are passed through the cdn, which route more than one request of various clients in the same tcp connection? Probably the next feature (in the roadmap) http-request track-sc will solve this? Haproxy version: 1.5 dev 19 Some ips have being truncated in the examples. I hope that this help others like me. Thanks, Ricardo F.
