We're excited to announce the release of HAProxy Enterprise 3.4, which gives customers more control over how HAProxy Enterprise behaves under constant change and attack.
UDP load balancing becomes programmable, and whole backends can be published dynamically through the HAProxy Runtime API or the HAProxy Data Plane API. The HAProxy Enterprise WAF gains configurable inspection limits that tune efficiency under heavy load, with the inspection verdict unchanged, and bot management gains self-hosted CAPTCHA options with a local audit trail.
This release builds on the industry-leading flexibility, performance, security, and resilience that HAProxy Enterprise is known for. All of it runs in line, on customer infrastructure, and inside the perimeter. No traffic leaves for a third-party scrubbing network, and the same configuration language and APIs drive every capability.
To dive deeper into the changes and enhancements in HAProxy Enterprise 3.4, we encourage you to join our upcoming HAProxy Enterprise 3.4 webinar.
What is HAProxy Enterprise?
HAProxy Enterprise load balancer provides high-performance load balancing for TCP, UDP, QUIC, and HTTP-based applications, high availability, an API/AI gateway, Kubernetes application routing, SSL processing, DDoS protection, bot management, global rate limiting, and the HAProxy Enterprise WAF.
HAProxy Enterprise combines the performance, reliability, and flexibility of our open-source core (HAProxy, the most widely used software load balancer) with ultra-low-latency security layers and world-class support. HAProxy Enterprise benefits from full-lifecycle management, monitoring, and automation (provided by HAProxy Fusion), and security layers powered by threat intelligence from HAProxy Edge and enhanced by machine learning.
Together, this flexible data plane, scalable control plane, and secure edge network form HAProxy One: the world's fastest application delivery and security platform that is the G2 category leader in Load Balancing, API Management, Container Networking, DDoS Protection, and Web Application Firewall (WAF).
To learn more, contact our sales team for a demonstration or request a free trial.
New in HAProxy Enterprise 3.4
Feature | Benefit | Impact |
Flexibility | ||
Programmable UDP load balancing | Per-datagram rules to filter, route, track, and rate-limit, plus protocol-aware health checks | HTTP-grade traffic control for UDP traffic such as DNS, RADIUS, NTP, and syslog |
Runtime backend lifecycle | Publish whole backends through the HAProxy Runtime API or HAProxy Data Plane API, with no reload | Dynamic provisioning for high-churn and multi-tenant platforms |
Remote certificate store | crt-store fetches and refreshes certificates and JWE key material from a remote source | No manual rotation step, and lower risk of a stale key |
Security | ||
WAF inspection limits and efficiency tuning | Configure Intelligent WAF Engine inspection limits globally or per WAF profile | More efficient inspection under load, with the inspection verdict unchanged |
Optimized buffer size for payload inspection | The WAF and Bot Management modules select the buffer size automatically, so larger payloads are inspected without raising the size for every request | More traffic inspected, with memory use sized to the workload |
XML request body inspection (experimental) | The WAF parses XML request bodies and applies rules for problems specific to XML | Inspection coverage for APIs that accept XML |
Compact WAF logging | A compact binary log format for the WAF (CBOR) | Smaller WAF logs that are faster to process and resistant to format changes |
Separate WAF log destination | WAF logs can be configured to be sent to a different log destination | Security teams feed a SIEM, SOAR, or audit archive without application logs |
Native Altcha and Cap support | Self-hosted CAPTCHA options that keep the challenge inside the customer perimeter | Bot management data-flow is simpler, lower impact on data sovereignty and privacy reviews |
CAPTCHA events in the access log | Challenge outcomes written to the access log | Bot management policy tuned on evidence from logs already collected |
QUIC data fetches | Sample fetches and a converter expose QUIC transport parameters, negotiated version, and connection-ID lengths | Actionable QUIC data for client-identification logic |
Resilience | ||
Broader GSLB record coverage | TXT, CAA, NAPTR, RDATA, and PTR records, plus a cold-check mode | Multi-site DNS load balancing kept in one stack |
High-availability state in JSON | Machine-readable VRRP status | Failover automation without text parsing |
Management and observability | ||
Native OpenTelemetry | Traces, logs, and metrics from the data plane | Telemetry integrates into an existing observability stack |
Compliance and administration | ||
FIPS-ready builds | HAProxy Enterprise built against AWS-LC in FIPS mode | Regulated procurement without a separate appliance |
External authentication on OVA images | RADIUS, LDAP/LDAPS, Active Directory, ADFS, Kerberos, OIDC/OAuth2, and SAML pre-installed | Directory-backed management access from first boot |
Ready to upgrade?
When you are ready to start the upgrade procedure, go to the upgrade instructions for HAProxy Enterprise.
Flexibility
Programmable UDP load balancing
UDP services like DNS, RADIUS, NTP, and syslog sit underneath everything else. A reachability check cannot flag when one of these services hangs while the host stays up. Catching it takes checks and rules that understand the protocol.
The goal was to bring UDP services up to parity with TCP and HTTP services in traffic control and health awareness.
HAProxy Enterprise 3.4 makes UDP load balancing programmable. New udp-request content rules act on each datagram: filter traffic, select a server, set variables, track, and rate-limit. A new track keyword adds stick-table counters for UDP and cross-protocol server-status tracking. Protocol-aware UDP health checks confirm DNS, RADIUS, NTP, and syslog services are answering.
Silent UDP failures become detected failures, and traffic moves to healthy servers. Per-datagram rate limiting helps limit targeted UDP abuse at the load balancer, without a separate appliance or application-level workaround.
To get started, see the UDP load balancing documentation.
Per-datagram UDP routing and protocol-aware health checks with HAProxy Enterprise
Configuration example: DNS over UDP with health checks
This example balances DNS over UDP, applies per-datagram rules, rate-limits connections, and builds a smart health check that validates the remote applications and lets HAProxy Enterprise mark each server as up or down.
| backend st_udp | |
| stick-table type ip size 100k expire 60s store conn_rate(5s),http_req_rate(5s),gpc0 | |
| udp-lb udp_dns_qat | |
| dgram-bind 10.20.110.21:53 name lst_admin | |
| dgram-bind 10.20.120.21:53 name lst_net2 | |
| dgram-bind 10.20.130.22:53 name lst_net3 | |
| balance roundrobin | |
| use-server dns_admin if { src 10.20.110.0/24 } | |
| udp-check send-binary 0002010000010000000000000377777706676f6f676c6503636f6d0000010001 | |
| udp-check expect rbinary 0002 | |
| udp-request track-sc0 src table st_udp | |
| udp-request reject if { src 10.20.120.0/24 10.20.130.0/24 } { sc_conn_rate(0) gt 10 } | |
| server dns_admin 10.20.110.3:53 check | |
| server dns_pub1 1.1.1.1:53 check | |
| server dns_pub2 8.8.8.8:53 check | |
| server dns_pub3 9.9.9.9:53 check |
The st_udp stick table keeps one entry per client source address. In this example, we’ll use the st_udp stick table to store and retrieve the connection rate for each client.
The udp-check send-binary directive sends a full DNS query instead of an empty probe. The 32-byte payload is a standard 32-byte A-record lookup encoded in hexadecimal.
DNS header (12 bytes)
Bytes | Field | Meaning |
| Transaction ID | Matches each response to its query |
| Flags | Standard query, recursion desired |
| Questions | One question in the packet |
| Answer, authority, and additional records | All empty in a query |
DNS question section (20 bytes)
Bytes | Field | Meaning |
| Label www | Length 3, then three bytes |
| Label google | Length 6, then six bytes |
| Label com | Length 3, then three bytes |
| Terminator | Ends the domain name |
| Query type | A record, IPv4 address |
| Query class | IN, internet |
As shown in the "DNS header" table above, udp-check expect rbinary 0002 matches the response payload against the transaction ID. DNS servers echo that ID at the start of the response header, so a match confirms the server received, processed, and replied to this specific health check query.
Meanwhile, udp-request track-sc0 src adds the client source address to the stick table, and stores the number of times a connection request was received from the client over a five-second window.
The udp-request reject line drops datagrams from 10.20.120.0/24 and 10.20.130.0/24 once a client exceeds ten connections in five seconds.
This example uses DNS, but the same pattern applies to other UDP protocols.
Dynamic backends at runtime
For platforms that update services constantly, i.e. add and remove backends, every change used to require a configuration update. We wanted to remove this operational friction that particularly affects enterprises with multi-tenant platforms, per-customer backends, and CI-driven environments.
HAProxy Enterprise 3.4 creates, updates, and deletes whole backends at runtime, with no reload. It covers full backends, including mode tcp, driven through the HAProxy Runtime API or HAProxy Data Plane API. This capability comes from the open-source HAProxy 3.4 release and is fully available in HAProxy Enterprise 3.4.
High-churn platforms can now publish and unpublish backends dynamically using the same APIs and Infrastructure as Code (IaC) tooling they already use to automate HAProxy Enterprise, including CI/CD pipelines. This cuts operational overhead and shortens the time needed to bring a new tenant or environment online.
Refresh certificates from a remote store
The crt-store section can now fetch and refresh certificate material from a remote source. In this release, it covers JWE key material as well as certificates; more may be added in future versions.
Key material for JWT and bearer-token validation rotates on the issuer's schedule rather than the user's. Remote refresh removes the operational burden of rotation and reduces the risk of an expired or stale key reaching production.
Security
WAF inspection limits and efficiency tuning
The next-generation HAProxy Enterprise WAF, powered by the Intelligent WAF Engine, provides exceptional balanced accuracy of 99.65% and ultra-low latency with 100% local processing. Advanced threat detection powered by threat intelligence from HAProxy Edge, enhanced by machine learning, virtually eliminates false negatives and false positives with almost zero performance impact on legitimate traffic.
HAProxy Enterprise 3.4 builds on this market-leading foundation with improved performance efficiency under heavy load. Inspection limits and tuning options allow enterprises to optimize WAF performance and resource consumption, even under conditions that stress the processing and log-writing capabilities of a typical WAF. All of this is possible without affecting the inspection verdict.
HAProxy Enterprise 3.4 makes the inspection limits of the Intelligent WAF Engine configurable. Users set them globally, per WAF profile, or inline on a single rule. The limits bound four things: how many arguments a request carries, how long an argument name may be, how much content is inspected, and how many JSON arguments are read.
Those limits bound what one request can do. They can:
Stop processing once a request reaches its match budget
Stop capturing matches past a threshold, while still counting them
Cap the log lines a single request can produce
Inspection depth no longer has to be set by the strictest application, so a low-risk static site and a high-risk API can be tuned differently on the same instance. Users can also choose which built-in rules write log lines, and request normalization is more thorough before matching.
Configuration example: setting WAF inspection limits for the Intelligent WAF Engine
This example tunes inspection for two applications, a strict profile for an API and a lighter one for a static site. It sets the three caps first, then the per-application limits.
This configuration is for performance tuning only; users do not need to configure WAF detection rules when using the non-signature-based detection of the Intelligent WAF Engine.
| waf-global | |
| iwe max-matches-captured 50 | |
| iwe max-matches-logged 20 | |
| iwe max-matches-processed 100 | |
| waf-profile api-strict | |
| iwe rules-file /etc/hapee-3.4/waf.rules | |
| iwe body-limit 65536 | |
| iwe name-limit 256 | |
| iwe content-limit 8192 | |
| iwe args-limit 100 | |
| iwe json-args-limit 100 | |
| iwe log | |
| waf-profile static # small JSON bodies, few args | |
| iwe body-limit 16384 | |
| iwe json-args-limit 50 | |
| ... | |
| frontend fe | |
| http-request waf-evaluate w1 profile api-strict |
The defaults still work untouched, so nothing changes for a user that never opens these settings. What v3.4 adds is headroom for the users who need it. Per-profile limits protect the simple default rather than replacing it.
Optimized buffer size for payload inspection
HAProxy 3.4 introduced a large-buffer pool in the open-source core. HAProxy Enterprise 3.4 extends it to the Enterprise modules, such as the HAProxy Enterprise WAF and Bot Management Module. The modules select the optimal buffer size automatically, so the size does not have to be raised globally for every request. Memory use tracks the workload rather than the largest possible request. Body limits stay tunable per WAF profile, so each application gets the inspection depth it needs.
XML request body inspection (experimental)
HAProxy Enterprise 3.4 adds experimental XML request body inspection to the HAProxy Enterprise WAF. The WAF parses XML request bodies as a stream, item by item, and applies rules for problems specific to XML. APIs that accept XML are inspected directly.
The feature ships as experimental in 3.4 and is turned off by default.
Compact WAF logs, separate destinations
The HAProxy Enterprise WAF now supports the CBOR log format. CBOR logs are compact, faster to process, and resilient to format changes.
WAF logs can also go to a different destination from HAProxy Enterprise traffic logs. Security teams typically route WAF logs to a SIEM or SOAR platform, and to a log archive that satisfies their retention and audit obligations. Separate destinations let each stream follow its own retention rules, access controls, and budget. For the basics, see an introduction to HAProxy logging.
WAF logs and traffic logs go to separate destinations with HAProxy Enterprise
CAPTCHAs that need no provider
The native CAPTCHA Module has shipped since HAProxy Enterprise 3.0. It supports Google reCAPTCHA v2 and v3, reCAPTCHA Enterprise, hCaptcha, Friendly Captcha, Turnstile, and custom providers. HAProxy Enterprise 3.3 added token-based callback verification, multiple CAPTCHA configurations per resource, and custom challenge HTML.
Every one of those providers verifies the challenge through an external or third-party service. For enterprises in regulated, air-gapped, or data-sovereignty environments, the challenge means a data-flow review before a CAPTCHA can go live.
We wanted to give those enterprises a CAPTCHA challenge that works inside their own perimeter.
HAProxy Enterprise 3.4 adds native support for self-hosted CAPTCHA options to the CAPTCHA Module: Altcha and Cap. Both are open-source projects. The user runs the challenge and verification endpoints, so no third-party CAPTCHA service sits in the request path. Neither option needs a site key or a secret key from a vendor account, giving enterprises native options that require no third party at all, alongside a full roster of external providers.
Comparison of third-party CAPTCHA provider and self-hosted CAPTCHA with HAProxy Enterprise
HAProxy Enterprise 3.4 also writes CAPTCHA events to the frontend access log. Users can see which challenges were served, solved, or abandoned, in the existing log pipeline. Bot management policy can be tuned on evidence rather than guesswork, which reduces the risk of affecting real users.
This extends the on-premises approach of our bot management solution. Detection and challenge both run on customer infrastructure, and HAProxy Technologies never receives customer traffic or user data.
Resilience
Broader GSLB coverage
HAProxy Enterprise Global Server Load Balancing (GSLB) keeps services available across sites and supports disaster recovery. Real deployments need DNS records beyond basic addresses for domain verification, certificate authority policy, telephony, and reverse lookups. Without them, users ran a second DNS system alongside GSLB.
HAProxy Enterprise 3.4 adds TXT, CAA, NAPTR, RDATA, and PTR record types to HAProxy Enterprise GSLB. A new cold-check verification mode also validates GSLB configuration syntax before changes are applied, preventing reload failures when multiple administrators make concurrent updates.
DNS-based global load balancing now resides in a single stack, reducing implementation costs. Traffic across sites follows current health, not an out-of-date verdict.
High-availability state in JSON
HAProxy Enterprise 3.4 adds a JSON option for VRRP status. Automation can now read the high-availability state directly rather than parsing text output. Runbooks that react to failover become more robust, and failover monitoring is easier to maintain.
Management and observability
Native OpenTelemetry
HAProxy Enterprise 3.4 adds native OpenTelemetry support, emitting OTel traces, logs, and metrics from the data plane. It replaces the OpenTracing support in previous versions of HAProxy Enterprise. This enables users to easily integrate HAProxy Enterprise telemetry with an existing observability stack.
Compliance and administration
FIPS-ready builds
In US federal, defense, and regulated finance, FIPS (Federal Information Processing Standards) is often a requirement for critical infrastructure products such as HAProxy Enterprise. We wanted to make procurement as simple as possible without compromising the high performance achieved by adopting AWS-LC as the default TLS library back in HAProxy Enterprise 3.2.
HAProxy Enterprise 3.4 offers FIPS-ready builds, using AWS-LC in FIPS mode. FIPS mode is a compliance-grade mode of the crypto engine customers already run, with no separate hardware appliance and no different product SKU.
External authentication on OVA images
Users deploying HAProxy Enterprise from OVA images used to install external-authentication packages after deployment. On an appliance-style image in a locked-down network, even fetching packages can be a change request.
HAProxy Enterprise 3.4 OVA images ship with external authentication pre-installed. RADIUS, LDAP/LDAPS, Active Directory, ADFS, Kerberos, OIDC/OAuth2, and SAML are available for management-plane authentication. Management access binds to a corporate identity provider from the first boot.
Building on the HAProxy One platform
HAProxy Enterprise 3.4 continues the steady evolution of the HAProxy One platform. HAProxy Enterprise 3.2 brought the Threat Detection Engine to the Bot Management Module, with behavioral detection running on customer infrastructure, including air-gapped environments. HAProxy Enterprise 3.3 unified the HAProxy Enterprise WAF into a single multi-engine design. HAProxy Enterprise 3.4 makes those capabilities easier to operate in production.
A load balancer, a WAF, bot management, CAPTCHA, global server load balancing, and programmable UDP all run in one data plane that runs entirely on customer infrastructure. They share one configuration language and one support relationship. HAProxy Fusion adds fleet-scale management, automation, and observability on top of all these capabilities.
Deprecations and breaking changes
OWASP CRS v3
OWASP has declared that Core Rule Set (CRS) v3 has reached end-of-life. As a result, the HAProxy Enterprise WAF in 3.4 supports CRS v4 only when running in the optional CRS compatibility mode. This does not affect the default mode, which uses only the Intelligent WAF Engine.
Users still running CRS v3 must migrate to CRS v4 (requires customer portal access). This migration procedure can be performed before or after upgrading to HAProxy Enterprise 3.4.
Legacy ModSecurity WAF module
The legacy ModSecurity WAF module is deprecated in HAProxy Enterprise 3.4. It is still included, and configurations that load it continue to work in 3.4. It will be removed in version 3.5.
The HAProxy Enterprise WAF is now the integration path. It runs in Intelligent WAF Engine mode, CRS compatibility mode, or both at once during a transition, so migration can be gradual. Plan the migration before the removal release. Migration guidance will be published in the HAProxy Enterprise documentation.
Per-module body directives
Per-module body directives are replaced by the WAF's large-buffer directives. The older directive remains functional in 3.4, and the new directives simplify configuration.
Deprecated | Status in 3.4 | Replacement |
OWASP CRS v3 | Not supported, still functional | CRS v4 |
Legacy ModSecurity WAF module | Deprecated, still included | HAProxy Enterprise WAF |
Per-module body directives | Deprecated, still functional | WAF large-buffer directives |
Upgrade to HAProxy Enterprise 3.4
When you are ready to upgrade, follow the links below:
Documentation | Release Notes | Install Instructions |
Try HAProxy Enterprise
The world's leading platforms and cloud providers trust HAProxy Technologies to simplify, scale, and secure modern applications, APIs, and AI services in any environment. HAProxy Enterprise 3.4 gives enterprises more control over security, UDP traffic, and runtime changes, all within the HAProxy One platform.
There has never been a better time to start using HAProxy Enterprise. To explore the changes in HAProxy Enterprise 3.4 in greater detail, don't forget to join our upcoming HAProxy Enterprise 3.4 webinar. Ready to jump in? Request a free trial of HAProxy Enterprise and see it for yourself.
Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.
