Counter issues on 1.8.29


We’re using some restrictions like this:

stick-table type ip size 1m expire 30s store gpc0,conn_cur,conn_rate(3s),http_req_rate(10s),http_err_rate(30s) peers mypeers

# Reject over 50 concurrent connections per ip
tcp-request connection reject if { src_conn_cur ge 50 }
# Reject if more than 30 connections in 3 seconds
tcp-request connection reject if { src_conn_rate ge 30 }
# Reject more than 30 http requests in 10 seconds
tcp-request content reject if { src_http_req_rate ge 30 }
# Reject if more than 10 http errors in 30 seconds
tcp-request content reject if { src_http_err_rate ge 10 }

While they’re not terribly nice, they used to work as expected. After upgrading to 1.8.29 we do get connection reset at normal browsing, a few requests from a browser, definitely none of the above limits being hit. There are two proxies in peering.

Downgraded back to 1.8.28 restored the expected behaviour. There was no configuration change.


Yes, this is a known a new regression in the latest bugfix releases, patches have been posted and committed to 2.2 tree, other backports will follow:

All supported stable branches now have the fix.

You can git clone from the 1.8 branch, or get get the backported patches here manually:;a=patch;h=bfba403a925c954daf6f43a3239429044681316b;a=patch;h=491b86ed0acdb4f3a1673f9357240176da930548

(both are necessary). Tomorrows 1.8 snapshot haproxy-ss-20210325.tar.gz will also contain those fixes.

I’ve also filed a tracking issue at github:

1 Like

Thanks Lukas, 1.8.29 plus the two patches is working fine.

Do you happen to have an estimate as to when the fixes might be available as a new release for the 2.2 version (as 2.2.12)?

Asking because I’m using prebuilt packages and can’t easily patch anything manually.

2.2.12: probably early next week to still give some time for last issues
to be reported.

An alternative is 2.3.8, although that is not a LTS branch.

1 Like