Skip to content

Troubleshooting HAProxy

Fabrizio Salmi edited this page Sep 6, 2026 · 1 revision

Troubleshooting HAProxy

Nothing gets blocked

Requests that should trigger a rule, including obvious directory traversal, pass straight through to the backend.

Cause. The ACL is matching against the literal path of the file instead of loading the patterns from it. These two lines look similar and behave completely differently:

# Wrong: compares the request against the string "/etc/haproxy/waf/waf.acl"
acl waf_attack path_reg /etc/haproxy/waf/waf.acl

# Right: loads the patterns from the file with -f
acl waf_match path,url_dec -m reg -i -f /etc/haproxy/waf/waf.acl

The same applies to the bot list:

acl bad_bot hdr(User-Agent) -m reg -i -f /etc/haproxy/waf/bots.acl
http-request deny deny_status 403 if waf_match || bad_bot

Reported in #14, which also led to fixes in owasp2json.py, json2haproxy.py and import_haproxy_waf.py.

"unknown keyword 'include' in 'frontend' section"

[ALERT] config : parsing [haproxy.cfg:53] : unknown keyword 'include' in 'frontend' section

Cause. HAProxy has no include directive inside a frontend. Configuration is not composed the way it is in Nginx or Apache.

Fix. Externalise the patterns, not the configuration: keep the acl lines in haproxy.cfg and point them at the generated files with -f, as above. That is what the shipped ACL archives are designed for.

Before you open a new issue

haproxy -c -f /etc/haproxy/haproxy.cfg
haproxy -v

Include the exact acl and http-request lines you used. In this backend the difference between working and silently passing everything is a single flag, so the configuration snippet matters more than the description.

Clone this wiki locally