In older HAProxy versions, HTTP/1.1 parsing was performed "in-place" on top of the raw TCP data. It was not an issue while connection keep-alive and massive header manipulations were not implemented/supported. However, when reusing connections to process several requests and adding more and more header manipulations (it is not uncommon to see configurations with hundreds of http-request rules), performance and security became concerns. In addition, supporting HTTP/2 raised compatibility challenges between both protocols, especially around the ability to transcode one version into another. 

To be performant, secure, and future-proof, a new approach had to be envisioned. This is what we achieved by using our own internal HTTP representation, called the HTX.

HTX is the internal name for the HTTP abstraction layer in HAProxy. It serves as the interface between the low-level layers of HAProxy, particularly the one responsible for parsing and converting different HTTP versions, the HTTP multiplexers, and the application part.  It standardizes the representation of messages between the different versions of HTTP.

Thanks to its design, almost all attacks that have appeared on HTTP/1 since the arrival of HTX have had no effect on HAProxy.

How HAProxy handled HTTP/1 before HTX

Originally, HAProxy was a TCP proxy and L4 load balancer. The HTTP/1 processing was added on top of it to be light, handle one request per connection, and only perform a few modifications. Over time, the trend has changed, and using HAProxy as an HTTP/1 proxy/load balancer has become the main usage, with more complex configurations and increasingly expensive HTTP processing. 

To protect HAProxy and servers behind it from attacks against the HTTP/1.1 protocol, costly and complex manipulations were mandatory, making processing even more expensive and the maintenance harder. The limits of the pre-HTX model were reached, mainly because of its design:

• We directly received HTTP/1 from the socket into a buffer, and on output, we directly emitted this buffer to another socket.

• The buffer therefore contained requests with all their flaws and variations (extra spaces, etc). The start and end of headers were indexed on the fly, and the various analyzers had to account for all possible variations (upper/lower case header names, spaces after the :, spaces at the end of the line, lone line feeds (LF) instead of carriage return line feed (CRLF), forbidden characters).

• Rewriting a header required anticipating the change in size (up or down), and potentially deleting an eventual CR and an LF if a header was deleted, or inserting one if a header was added. These modifications also required updating the header index so that subsequent analyzers remained well synchronized. Some rewrites could insert CRLFs haphazardly ("hacks"), resulting in headers not being detected by subsequent stages because they were not indexed. The same applied to checks.

• Data brought up as chunks appeared in raw format with the chunk, including optional extensions, so it was not possible to perform simple string search processing without having to account for chunking. This is notably why the http-buffer-request directive only processed the first chunk.

• For very light and historical uses (with minimal header consideration, a model closer to early HTTP/1.0), this operation was relatively optimal since everything received was sent back with very little analysis.

• With the arrival of keep-alive, which required parsing many headers, performing many more checks (Content-Length vs. Transfer-Encoding, host vs. authority, connection, upgrade, etc.), and making even more changes (adaptation between close vs. keep-alive sides), the simplicity of the original model became a liability. All advanced parsing work had to be redone at each processing stage, often multiple times per request and response.

How HAProxy handled HTTP/2 before HTX

The HTTP/2 support was originally implemented as a protocol conversion layer between internal HTTP/1 and external HTTP/2. However, this raised several security issues due to the ambiguities of this conversion. But this also came with an unfortunate extra cost. The model was as follows:

• On input, a block of HTTP/2 data was received and decoded. HEADERS frames were decompressed via the HPACK algorithm and produced a list of headers as (name, value) pairs. This list was then used to fabricate an HTTP/1.1 request by combining the method, URI, and adding the headers with : after the names and CRLFs after the values. This already posed several problems, because H2 is binary-transparent, meaning it is technically possible to encode : and CRLF in field values, making header injection possible if not enough care was taken.

• The reconstructed URL was generally an absolute URL because the elements provided by the client (method, scheme, authority, path) were concatenated, and URL matchings in the configurations no longer worked (e.g., url_beg/static).

• Data received in DATA frames resulted in HTTP chunks if the Content-Length was not announced. Similarly, it was difficult to analyze request chunks when needed (e.g., impossible to perform state modifications in HTTP/2 on the stats page, which used POST).

• On output, the HTTP/2 converter had to re-parse HTTP/1.1 headers to fabricate a HEADERS frame. The parser used was simpler because it was assumed that HAProxy could be trusted to send valid protocol, but this caused many problems with error messages (errorfiles), responses forged in Lua, and the cache, which could sometimes store content that had undergone few protocol checks. Furthermore, to read the data, the parser also had to account for chunking and emit a DATA frame for each chunk. As a result, an HTTP/1 response sent back over HTTP/2 had to be parsed twice: once by the HTTP/1 parser for analysis, and a second time by the HTTP/1 parser integrated into the HTTP/2 converter.

• The HTTP/2 converter also had to infer the correct operating mode for the response based on the Connection header and the announced HTTP version (HTTP/1.0 vs HTTP/1.1). It also struggled with edge cases involving Transfer-Encoding combined with Content-Length, as well as cases with no announced length where closing the server-side connection signaled the end of the response. Trailers were not supported because they were too risky to implement in this conversion model.

• HTTP/2 was not implemented on the server side because of the increase in special cases to handle and the difficulty in converting these responses into valid HTTP/1. Furthermore, it quickly became clear that with this model, it was impossible to maintain a correct level of performance by doing end-to-end H2 because it required four conversions for each exchange.

The HTX: common internal representation for different HTTP versions

The "legacy" model having shown its limits, we logically decided to undertake a transition towards a more rational model. Continuing to base all internal operations on HTTP/1 was clearly a hindrance to the adoption of HTTP/2 and any other future versions of HTTP. The HTX was born from this thinking: to achieve a common internal representation for all current or future versions of HTTP.

If we take the previous example, here is how it happens today to transmit a request from an H2 client to an HTTP/1.1 server:

The HTX is a structured representation of an HTTP message, intended to serve as a common foundation for all versions of HTTP within HAProxy. Internally, an HTX message is stored in a buffer. It consists of a part containing information about the message, the metadata, followed by a set of blocks containing a portion of the message resulting from parsing. This eliminates formatting differences tied to specific HTTP versions and standardizes the data. For example, header names are stored in lowercase, and spaces at the beginning and end of header values are removed, as are CRLFs at the end of the header.

Because an HTX structure is limited to the size of a buffer, only part of a large HTTP message may be present in HTX at any one time. An HTX message can be thought of as a pipe: as parsing progresses, new blocks are appended; HAProxy processes them (header rewriting, body compression, etc.); and they are then removed on the output side to be formatted and sent to the remote peer.

Organization of HTX blocks

HTX blocks are stored in a contiguous memory area, an array of blocks. Each block is divided into two parts. The first part, the block index, contains information related to the block: its type, its size, and the address of its content in the array. These indexes are stored starting from the end of the block array. The second part, meanwhile, contains the block data and is stored starting from the beginning of the array.

The part corresponding to the block data is a memory space that can "wrap" and is located at the beginning of the block array. The block data is not directly accessible; one must go through the index of the corresponding block to know the address of its data, relative to the beginning of the block array.

However, this sometimes requires a defragmentation step when the distribution of blocks becomes too fragmented, and it is necessary to recover free space to continue processing. Concretely, the data can be arranged in two different ways:

• Contiguous and ordered: with two possible free spaces — before and after the data. To preserve the order of the blocks as much as possible, additions are made primarily at the end of the array. The gaps between the blocks are not directly reusable:

A block index contains the following information about the block:

• A 32-bit field: 4 bits for the block type and 28 bits for the size of the block data.

• The address of the block data, on 32 bits, relative to the beginning of the block array.

Block types overview

Among the different types of HTX blocks, we find the elements that constitute an HTTP message:

• A start-line: (method + uri) for a request, or (status + reason) for a response.

• A header or a trailer: a (name + value) pair.

• Data.

There are also internal block types used to mark the end of headers and trailers, or to mark a block as unused (for example, when it has been deleted).

Encoding details

Depending on the type, the information of a block will be encoded differently:

Header or trailer block:

0b 0000 0000 0000 0000 0000 0000 0000 0000
   ---- ------------------------ ---------
   type  value length (1MB max)  name length (256B max)

 Start-line or data block:

0b 0000 0000 0000 0000 0000 0000 0000 0000
   ---- ----------------------------------
   type      data length (256 MB max)

 "End of headers" or "end of trailers" marker:

0b 0000 0000 0000 0000 0000 0000 0000 0001
   ---- ----------------------------------
   type         always set to 1    

Unused:

0b 0000 0000 0000 0000 0000 0000 0000 0000
   ---- ----------------------------------
   type         always set to 0 

Block ordering

An HTX message is typically composed of the following blocks, in this order:

1. A start-line (request or response)

2. Zero or more header blocks

3. An end-of-headers marker

4. Zero or more data blocks (HTTP)

5. Zero or more trailer blocks

6. An end-of-trailers marker (optional, but always present if there is at least one trailer block)

7. Zero or more data blocks (TUNNEL)

Responses with interim status codes

In the case of responses, when there are interim responses (1xx), the first three blocks can be repeated before having the final response (2xx, 3xx, 4xx, or 5xx). In all cases, whether for requests or responses, the start-line, headers, and end-of-headers marker always remain grouped. This is true at the time of parsing, but also at the time of message formatting. The same applies to trailers and the end-of-trailers marker.

Structure of HTX block data

HTX block data comes in several forms, each representing a specific part of an HTTP message. The following sections describe how each block type is structured and used.

The start-line

The start line is the first block of an HTX message. The data in this block is structured. In HTTP/1.1, it is directly extracted from the first line of the request or response. In H2 and H3, it comes from the pseudo-headers (:method, :scheme, :authority, :path). Furthermore, because this block is emitted after all message headers have been parsed, it also contains information about the message itself, in the form of flags. For example, it can indicate whether the message is a request or a response, whether a size was announced via the Content-Length header, and so on.

Headers and trailers

Header data and trailers are stored the same way in HTX. There are two different block types to simplify internal header processing, but from the HTX perspective, there is no real difference, apart from their position in the message. Header blocks always come after a start-line and before an end-of-headers marker, while trailers always come after any data and are terminated by an end-of-trailers marker. In both cases, it is a {name, value} pair.

Data

The message payload is stored as data blocks, outside of any transfer encoding. Thus, in HTTP/1.1, the chunked formatting disappears. The same blocks are also used to store data exchanged in an HTTP tunnel.

End-of-headers or end-of-trailers markers

These are blocks without data. Depending on their type, they mark the end of the headers of a message or the end of the trailers. The end-of-headers marker is mandatory and marks the separation between the headers and the rest of the message. The end-of-trailers marker is optional and marks the end of the HTTP message and can potentially be followed by data exchanged in an HTTP tunnel.

The benefits of using HTX in HAProxy

Simplified and more secure manipulation

As header names are normalized and indexed, searching is straightforward; it is enough to iterate over the blocks and compare them without having to re-parse them. There are relatively few headers per request or response (very often less than ten per request, between one and two dozen per response), so any additional indexing would be superfluous. This simplifies operations by eliminating the need to preserve relative positions between all headers.

Rewrites are also well-controlled. The name of a header is normally not modified, and the value that needs modification (e.g., cookie modification) is already perfectly delimited and cleared of leading/trailing spaces and CRLFs. The API prevents insertion of forbidden characters such as NUL, CR, or LF. As a result, it is effectively impossible to leave CRLFs in a value accidentally, and each HTX header corresponds to exactly one outgoing header.

In HTTP/1, the CRLF at the end of each line is automatically added by the protocol conversion, so the user or analyzer working on HTX has no direct control. Except in cases of conversion bugs, this design makes it impossible to pass one header for another or inject portions of a request or response to cause smuggling. Risks of bugs in the analysis or application layer are minimized because this layer no longer needs to manage available space for modifications; HTX handles it automatically, making the API trivial to use.

Regarding the data, its delimitation is performed by the output converter. A block emitted in HTTP/1 will lead to the creation of a chunk, while the same block emitted in HTTP/2 will lead to one or more DATA frames. The total size of the converted data must match the announced size, otherwise an error is reported. Here too, the user has no control, so there is no risk of confusion about the output protocol. We again benefit from the intrinsic knowledge of the remaining data to be transmitted, avoiding the misinterpretation of boundary formatting that could lead to exploitation.

This design is why nearly all HTTP/1 attacks since HTX’s introduction have had no effect on HAProxy. A few early issues affected the first versions due to missing checks in the conversion stage (e.g., spaces in the name of an HTTP/2 or HTTP/3 method), but these had very limited impact.

Closer to RFCs

Modern HTTP specs (RFC911x) have been carefully separated by distinguishing the semantic part from the protocol part. Thus, all HTTP versions are subject to the same rules described in RFC9110, and each version also has its own constraints. For example, HTTP/1 describes how the body length of a message is determined based on the method used, the status code, the presence or absence of a Transfer-Encoding header, etc., while HTTP/2 and HTTP/3 do not have this last header. Conversely, HTTP/2 and HTTP/3 are not allowed to let a Connection header pass and have specific rules regarding mandatory headers depending on the methods, and which may also be subject to negotiations within the framework of optional extensions (e.g., RFC8441 to pass WebSocket over HTTP/2).

These types of checks were tedious to implement in the analysis layer because they all had to be subject to version checks to know what to verify. And errors are even easier on the response path because an HTTP/2 request transferred over HTTP/1 will lead to an HTTP/1 response that must be re-encoded in HTTP/2, but the error of relying on the request version rather than the response version for a given treatment is very quick to happen. All this code was therefore considered very sensitive and was subject to very few improvements for fear of making it fragile.

The HTX made it possible to report protocol checks to the ends, in the converters, and to leave only semantic checks in the analyzers, operating on the HTX representation. Thus, each protocol converter is more free with its checks and can stick to its own rules without the risk of others benefiting from it as a side effect.

More easily extensible

Adding support for new protocols only requires writing the new converters, potentially by drawing inspiration from another similar protocol. There is no longer any need to modify the analyzers or the core semantic layer. This is how HTTP/3 support on top of the QUIC layer was added so quickly—with fewer than 3000 lines of code, some of which came from the HTTP/2 implementation (and were later shared between them). Indeed, in practice, implementing a new protocol mostly comes down to writing the HTX transcoding code to/from this protocol and nothing else.

Support for the FastCGI protocol was introduced in much the same way, since this protocol is primarily just a different representation of HTTP. As a result, the codebase is now well positioned to accommodate new experimental versions of protocols while remaining maintainable. For example, when HTTP/4 eventually takes shape, the HTTP/3 code will probably be reused and adapted to form the beginning of HTTP/4, thus preserving a proven basis that can evolve alongside the protocol and be ready with a functional version once the protocol is ratified.

This approach keeps the focus on the essential, namely the protocol itself and its interoperability with the outside world rather than on the impacts it could have on the entire codebase. By comparison, the first implementation of HTTP/2, starting from an already ratified protocol, took more than a year to complete.

Conclusion

The HTX enables us, among other things, to free ourselves from the details related to the different versions of HTTP in the core of HAProxy, allowing the conversion layers to handle them on input and output. HAProxy is thus capable of enabling clients and servers to communicate regardless of the HTTP versions used on each side. 

Ultimately, this abstraction immunizes HAProxy against numerous classes of bugs affecting HTTP/1. In HAProxy, HTTP/1 is not processed for analysis (rewriting, routing, or searching). Once the translation into HTX is done, HAProxy is no longer subject to HTTP/1 attacks. The focus is therefore concentrated solely on the conversion layer.

For example, a well-known request smuggling attack, which involves sending an HTTP/1 request with both a Content-Length header and a Transfer-Encoding header in order to hide a second request in the payload of the first is not possible in HTX, by design. Information related to data size is extracted from the message and stored as metadata.

While HAProxy cannot block every possible request smuggling attack (consisting of hiding one request inside another), it will not be vulnerable to them and will prevent a certain number of them from being sent to servers, precisely because with the switch to HTX, the HTTP message undergoes normalization, and HAProxy can only transmit what it understands.

At a glance

• The issue: A critical remote code execution (RCE) vulnerability, dubbed "React2Shell," affects React Server Components and Next.js (CVE-2025-55182).

• Severity: 10.0 (Critical).

• Status: Active exploitation observed in the wild; public proof-of-concept code is available.

HAProxy protection

• HAProxy Enterprise WAF: Customers using the HAProxy Enterprise WAF, powered by the Intelligent WAF Engine, are protected against most attack vectors. Refined rulesets covering remaining edge cases are available.

• HAProxy Community Edition: We provide sample ACLs based on best recommendations and known attack vendors.

• Immediate action required: If you are running React or Next.js behind HAProxy, update your WAF rulesets immediately and plan to patch your backend applications.

What is CVE-2025-55182 (React2Shell)?

On December 3, 2025, the React team announced a critical security vulnerability in React Server Components (RSC). Identified as CVE-2025-55182 (and covering the now-duplicate CVE-2025-66478), this flaw allows unauthenticated attackers to execute arbitrary JavaScript code on backend servers.

Technical impact:

The vulnerability stems from insecure deserialization within the RSC "Flight" protocol, which is used for client-server communication. By sending a specially crafted HTTP request payload, an attacker can manipulate how React decodes data, influencing server-side execution logic.

Because the flaw exists in the default configuration of affected applications — including those built with standard frameworks like Next.js — deployments are immediately at risk without requiring any developer code changes.

CVSS v3 Score: 10.0 (Critical).

Affected versions:

• React: Versions 19.0, 19.1.0, 19.1.1, and 19.2.0.

• Next.js: Versions 15.x and 16.x using App Router.

• Other Frameworks: Any library bundling the vulnerable react-server implementation (e.g., Waku, RedwoodSDK).

How HAProxy One protects your infrastructure

While patching the upstream application is the ultimate remediation, HAProxy One provides a multi-layered security platform that stops attacks at the edge of your network, providing a critical first line of defense. You can stop the attack before it ever reaches your vulnerable servers.

1. Managed protection with HAProxy Edge

For customers using HAProxy Edge, our managed Application Delivery Network (ADN), no immediate action is required on your part to enable protection. Your traffic is already being filtered through our global network, which is regularly updated with the latest threat intelligence and WAF rulesets. This ensures you have the best protection available while you plan your backend patching strategy.

2. Automatic protection with HAProxy Enterprise WAF

For customers using HAProxy Enterprise WAF only (see below), protection against this exploit is available via our latest rule updates.

Our initial testing confirmed that the HAProxy Enterprise WAF already blocked most identified malicious payloads associated with this vulnerability. To ensure comprehensive coverage, our security team has refined the ruleset to handle specific edge cases derived from global traffic analysis on HAProxy Edge. This threat intelligence, enhanced by machine learning, ensures your protection evolves as fast as the threat landscape.

Action required:

Update your WAF rulesets immediately to ensure you have the latest protections released on December 5th. Follow these instructions to update quickly:

• Docs for HAProxy Fusion / Control Plane users

• Docs for HAProxy Enterprise or Hardware/Virtual Appliance users

3. Moderate protection with CRS mode (ModSecurity)

For customers using HAProxy Enterprise WAF in the OWASP CRS compatibility mode, or the standalone lb-modsecurity module, protection against this vulnerability depends on your active rule version. This is due to the signature-based approach that the OWASP Core Rule Set provides. We advise customers to use the latest stable CRS v4 ruleset and ensure rules REQUEST-920-PROTOCOL-ENFORCEMENT, REQUEST-934-APPLICATION-ATTACK-GENERIC, and REQUEST-949-BLOCKING-EVALUATION are enabled.

If you are an HAProxy customer and are unsure about what protections you may have or best practices, please contact support.

Protections with HAProxy Community Edition

Below is a sample configuration for Community Edition users. This is based on best recommendations from the industry and the known attack vectors and is expected to provide reasonable protection, but may not cover all edge cases. We will update this as we learn more.

A basic example of a recommended ACL is provided here:

While HAProxy mitigates the immediate risk, we recommend a multi-layered security strategy:

1. Patch the source: Apply the official fixes immediately. The React team has released versions 19.0.1, 19.1.2, and 19.2.1 to address this issue.

2. Monitor logs: Watch your HAProxy logs for a spike in HTTP 403 errors, which indicates the WAF is actively blocking exploitation attempts.

3. Audit your environment: Recent data suggests up to 39% of cloud environments may contain vulnerable instances. Ensure you have identified all public-facing applications running Next.js or React

Conclusion

Vulnerabilities like React2Shell highlight the volatility of the modern threat landscape. With threat actors operationalizing exploits within hours of disclosure, relying solely on patching backend applications leaves a dangerous window of exposure.

HAProxy One provides the robust, multi-layered security needed to “virtually patch” vulnerabilities instantly. By leveraging the intelligence derived from our global traffic, our WAF rulesets evolve in real time to protect your infrastructure.

Next steps

• Existing Customers: Update your WAF rulesets now to the version released December 5th.

• Evaluate Security: If you want automatic protection against future zero-days, contact us to learn more about HAProxy One.

References

• Official React Blog: Critical Security Vulnerability

• AWS Security Blog: China-nexus groups exploit React2Shell

• Customer documentation for HAProxy Fusion

• Customer documentation for appliance

However, cyber threats with increasingly complex attack vectors and new zero-day exploits have grown more sophisticated — and elusive. Reactive, signature-based defenses now leave critical blind spots that bad actors can readily exploit. In response, our team has engineered a smart, new approach to application security – one capable of defending against sophisticated threats while simultaneously reducing false positives, simplifying management, and delivering performance efficiency that makes advanced security virtually cost-free.

We officially introduced the next-gen HAProxy Enterprise WAF with HAProxy Enterprise 2.9, and since then it has become a stable and mature option used by some of our biggest enterprise customers. This new WAF is designed to address the complexities and demands of modern application environments and the advanced threats they face — and is distinguished by its exceptional balanced accuracy, simple management, and ultra-low latency and resource usage.

Next, we'll dive (but not too deeply!) into the innovations behind the HAProxy Enterprise WAF. We'll explore the groundbreaking Intelligent WAF Engine, share key performance metrics that redefine industry standards, detail its unmatched usability, and outline its comprehensive protections. This thorough overview will show how this next-gen WAF empowers organizations to secure their services with unprecedented confidence and efficiency.

Traditional WAFs have historically relied on static lists and regex-based attack signatures to identify and block malicious traffic. Unfortunately, these measures are only capable of detecting threats for which a signature already exists. This leaves organizations vulnerable to emerging, polymorphic, or previously unseen attacks — commonly called zero-day threats. The unending race to update signatures against rapidly evolving threats also imposes a significant operational burden on security teams.

The patent-pending, next-gen HAProxy Enterprise WAF is built on our unique Intelligent WAF Engine. This engine moves beyond the constraints of static signatures by employing a non-signature-based detection system. Its advanced threat detection is powered by threat intelligence data from over 60 billion daily requests on HAProxy Edge and enhanced by machine learning — delivering highly accurate threat detection that virtually eliminates false alarms and undetected threats with almost zero performance impact on legitimate traffic. Our data science team trains our security models and enables them to reliably detect any attacks and anomalous behavior.

Unmatched accuracy and performance

A WAF's effectiveness is ultimately measured by its ability to accurately distinguish between legitimate and malicious traffic, all without notably impacting app performance. Accordingly, the next-gen HAProxy Enterprise WAF sets new standards for exceptional accuracy and speed.

WAF accuracy can be calculated by measuring the true positive rate and the true negative rate:

• True-positive rate refers to the proportion of dangerous traffic correctly identified by the WAF. Dangerous traffic incorrectly identified as safe is a “false negative”.

• True-negative rate refers to the proportion of safe traffic correctly identified by the WAF. Safe traffic incorrectly identified as dangerous is a “false positive”.

The average of these two values is called “balanced accuracy”. The vast majority of WAFs on the market do well at one metric but not the other, resulting in poor scores for balanced accuracy (generally below 90%).

Open source benchmarks reveal the HAProxy Enterprise WAF's impressive accuracy rates: a 99.8% true-positive rate (indicating its efficacy in accurately identifying actual threats) and a 97.1% true-negative rate  (signifying its ability to allow legitimate traffic through). These equate to an outstanding balanced accuracy rate of 98.5%. This significantly outperforms the category average, which typically falls below 90%. HAProxy Enterprise WAF thus ensures full-spectrum threat coverage, drastically minimizes false alarms, and ensures a seamless user experience.

Next comes performance. HAProxy Enterprise adds under 1ms of latency to each request on average, and that doesn’t change when you enable the HAProxy Enterprise WAF – it’s one of the only WAFs that runs in the same process as the request, having virtually no impact on performance. In the vast majority of cases, any added latency is below measurable thresholds — meaning no more tradeoffs between security and speed. This ensures a highly responsive user experience and optimal service performance under all traffic loads, making your business and customers happy. 

What’s more, this performance is achieved with startling efficiency. HAProxy has always been known for its low resource usage, and with HAProxy Enterprise WAF, that doesn’t change. In fact, enabling HAProxy Enterprise WAF has virtually no impact on CPU usage, according to customers like Roblox who presented their use case and experience at HAProxyConf.

Plus, HAProxy Enterprise WAF generates significantly fewer false positives with OWASP CRS enabled: an impressively low 2.9% false-positive rate at paranoia level 2, greatly outperforming the 28.36% figure for the ModSecurity WAF under identical conditions. This dramatic improvement has been a great relief to teams otherwise saddled with operational overhead and alert fatigue from traditional ModSecurity implementations.

Simpler security with enhanced control

Teams have historically viewed WAFs as complex, resource-intensive, and high maintenance — requiring extensive tuning. As a result, they haven't rushed to adopt and manage these solutions. HAProxy Enterprise WAF addresses these pain points by offering simplicity and control.

Because users don’t need to manually write, configure, or continuously maintain complex custom rules, adoption and management aren't insurmountable tasks. It makes intelligent WAF protection more accessible and practical for a broader range of organizations — from those with smaller security teams or less specialized WAF expertise, to large enterprises that need to reduce the operational overhead of managing hundreds or thousands of WAFs.

For those organizations with more complex needs, HAProxy Enterprise WAF makes it simple to deploy differentiated WAF rules using customizable WAF Profiles (available in HAProxy Enterprise 3.2). You can now create, customize, and apply a unique WAF ruleset for each WAF Profile, applying them selectively across different applications or locations. This granular control is essential for tailoring security across diverse application portfolios. By fine-tuning WAF security based on the unique traffic patterns and security requirements of individual applications, you can minimize false positives, reduce alert fatigue, and ensure an improved UX for your legitimate users.

WAF management and observability are streamlined through HAProxy Fusion, the centralized control plane for HAProxy Enterprise. HAProxy Fusion simplifies WAF management across diverse and complex environments, including multi-cluster, multi-cloud, and multi-team deployments. Teams get a unified WAF management interface which lets them upload custom rulesets, set thresholds, add exceptions when needed, and view security responses individually — or globally — across their load balancing clusters.

HAProxy Enterprise WAF effectively guards against a broad range of threats, including $SQL (SQL injection), $XSS (cross-site scripting), $RCE (remote code execution), $RFI (remote file inclusion), $TRAVERSAL (directory traversal attacks), and $EVADE (defense evasion attempts). The Intelligent WAF Engine adds robust protection against emerging and elusive zero-day threats, helping thwart attacks that traditional signature-based systems would miss.

Zooming out, HAProxy Enterprise WAF is not merely an isolated security product but an integral component of HAProxy Enterprise’s multi-layered security suite. This suite includes other critical security features such as HAProxy Enterprise Bot Management Module and global rate limiting — powered by the Global Profiling Engine (GPE). Modern cyberattacks are often multi-staged and involve many attack vectors, from automated bot reconnaissance to Layer 7 exploits. Singular security features cannot possibly address every cyber threat. 

For example, HAProxy Enterprise Bot Management Module can identify and reroute bad traffic before it even reaches HAProxy Enterprise WAF, boosting performance against application-layer attacks and minimizing load. This integrated approach is highly customizable, robust, and enables defense-in-depth threat management strategies. It's also a strong value proposition for customers seeking a unified security platform.

Benefits for your organization

The advanced technical capabilities of the next-gen HAProxy Enterprise WAF translate into improved efficiency, cost savings, and enhanced user experiences. Threat detection and traffic filtering occur in microseconds, resulting in minimal resource consumption and substantially lower operational costs.  Plus, the near-absence of false positives — as demonstrated by the impressive 2.9% false-positive rate when using the OWASP CRS  — drastically reduces the operational burden for security teams. Spend less time triaging irrelevant alerts and more time focusing on strategic security initiatives that can directly reduce risk and expenses.

Don't forget about accuracy. By virtually eliminating false negatives — where malicious traffic is missed — HAProxy Enterprise WAF helps minimize downtime, data loss, financial fraud, and other negative outcomes. Its comprehensive protection against today's and tomorrow's threats keeps you protected. You've worked hard to maintain a solid business reputation, and your WAF should support you there. 

Neither humans nor legitimate bots (such as Googlebot) are inadvertently blocked nor encounter latency. The HAProxy Enterprise WAF operates as a highly accurate detection and signaling system, allowing you to define your own response — whether that means blocking, logging, or alerting. This flexibility ensures seamless application delivery, positively impacts business perception, and increases ROI through risk mitigation and operational efficiency. 

Why upgrade now?

The case for adopting the next-gen HAProxy Enterprise WAF is clear. When threats are sophisticated and application performance is critical, relying on outdated or inefficient security solutions poses clear (and unnecessary) risks.

HAProxy Enterprise WAF offers unmatched accuracy, uncompromising performance with ultra-low latency and resource usage, simple management, and next-gen threat protection. For organizations currently grappling with the operational overhead of traditional WAFs, the alert fatigue from high false positives, or the constant threat of zero-day exploits, HAProxy Enterprise WAF will be transformative.

Try HAProxy Enterprise WAF today

To further explore how our WAF solution can secure web apps, APIs, and AI services, check out our web application firewall solution page. For deeper insights into specific use cases or to see HAProxy Enterprise WAF in action, we encourage you to contact our team.

More cores, more problems

CPUs have changed dramatically during HAProxy's lifetime. Today's chips have many more cores and threads than those that were popular in HAProxy's early days. More cores and more threads mean my applications can run faster and process more data, right? 

Not always. Let's take a moment to review some fundamentals and consider a few different processors from over the years.

From single-core to massively multi-core processors

In 2001 (the year HAProxy 1.0 was released), some of the best-selling processors for servers that year were the Intel Pentium III ("Tualatin") and the AMD Athlon MP (Multiprocessor). These chips had a single core and could handle a single thread of execution. "Threads", in computing terms, are a list of instructions for a CPU to execute. This is your program as it is executing. Each program run on the machine has its own set of instructions to execute. The operating system handles the work of coordinating the timing of each program's threads' executions on the core; the programs must take turns executing their instructions. 

In 2005, the industry saw the introduction and more widespread use of dual-core processors, such as the Intel Xeon and AMD Opteron. Both of these processors, as well as others of the time, had two cores on the same chip. This meant that you could get the simultaneous processing power of a machine with two chips with only a single chip. 

Multiple cores meant that you could execute multiple threads in parallel, with one caveat: the software had to be built to take advantage of the additional cores; it could not just use them automatically. Version 1.1.17 of HAProxy (2002) could take advantage of multiple processors on such a system by running multiple HAProxy processes in parallel. This was not without limitations, however, as data could not be shared across the processes, and some features could only be run in single-process mode.

Since then, the number of cores per chip has increased significantly, with even today's smartphones and workstations having six to twelve cores, often of varying computational capacity, in a single chip. 

As for servers, the number is much higher today, with massively multi-core processors such as AWS Graviton, AMD EPYC, and Intel Xeon, which can have as many as 288 cores on a single system. 

At this point, you must be thinking, "Surely by now, and with so many more cores, my programs must run so much faster, right?" To a large extent, yes, but variations in chipset architectures create a new set of challenges.

Multi-core NUMA CPUs: The challenges of massively multi-core systems and the importance of designing NUMA-aware software

Today's applications still face the same problems from decades ago: though today's processors offer more cores and more threads, applications must be designed to both efficiently and intelligently use the hardware in a multi-threaded way. If an application has only one thread of execution, it will run only on a single core; adding more cores produces no benefit. 

However, simply making an application multi-threaded and allowing it access to all cores on a system is not sufficient, as not all CPU architectures operate the same way, and in some cases, adding more threads to operate on more cores can even cause performance degradation on some modern systems, as can often be the case on NUMA (Non-Uniform Memory Access) systems.

In these processors, cores are grouped into CCXs, or core complexes, where the cores that share L3 caches have the lowest latencies and are grouped together. Multiple CCXs may be colocated in a single CCD, or core complex die, and then one or more CCDs may make up a single NUMA node. The arrangement of cores, CCX, and nodes is referred to as CPU topology.

This latency for data copies is dependent on the characteristics of your CPU topology. At best, it may be under 10 nanoseconds, and at worst, it may be hundreds of nanoseconds.

But it's just nanoseconds we're talking about, right? Yes, but if your processing expectations are to successfully handle several million requests per second, every nanosecond matters.

How does HAProxy overcome the challenges of modern processors?

CPU topology dramatically affects how multithreaded applications perform. This means that to provide the best performance, HAProxy must be aware of your CPU topology. HAProxy automatically makes these considerations about your specific system:

• How many cores do you have, and how are they arranged? (Operations between close cores will be the fastest.)

• How many threads do you have? (How many operations can be executed in parallel?)

• How can HAProxy intelligently organize its operations to make the most effective and efficient use of your hardware? (How can it minimize data transfers between distant cores and reduce the number of data copies in general?) 

HAProxy uses this information to intelligently scale its operations on your hardware to provide the best performance. Its architecture embodies optimized multithreading, enabling it to provide effective automatic CPU binding.

Optimized multithreading in HAProxy

HAProxy has supported multithreading since version 1.8, and it can run on machines with any number and arrangement of cores. It achieves this by detecting the topology of your system, that is, the layout of your CPUs, CCXs, caches, and so on, and it uses this information to arrange its threads in a way that minimizes latency between threads. 

In versions earlier than 3.2, HAProxy limits itself to the first NUMA node and does not automatically, that is, without additional, complex configuration, use the rest of the cores on systems that have more than one node. This is because, without additional restructuring of the core HAProxy components, benchmarking revealed that including more cores was counterproductive due to the latency associated with sharing data between distant cores.

Since version 2.4, HAProxy organizes its threads intelligently to minimize the sharing of data between cores that are very far from each other. Some data is shared between multiple threads (for example, server states, the next server to choose for round-robin, and statistics counters) and, therefore, must frequently be moved between cores. To reduce the distance this data must travel, HAProxy maintains multiple, independent copies of the data that stay local to groups of closely-located threads, which helps ensure that most data moves are fast, and keeps processing moving in parallel. Keeping data transfers local to closely located groups of cores enables HAProxy to utilize more nodes and potentially all available cores. 

To make this possible, important restructuring and optimization efforts since version 2.4 include:

• implementing zero-copy forwarding or "fast-forwarding" for data copies, which improves CPU cache performance

• rewriting critical components so that they better scale with more threads by:

  • reducing latency by minimizing process-wide data sharing, limiting sharing to only groups of close threads, or "thread groups", when possible, and restructuring components to be thread-group-aware

  • reducing lock contention and improving atomic operations (these reduce the number of locks required)

Zero-copy forwarding

CPU caches allow CPUs to access frequently used data very fast, much faster than they can retrieve the data from memory (RAM). CPU caches can store a considerably smaller amount of data than can memory, and as such, data in the cache is constantly refreshed. This means that once new data arrives, the CPU must retrieve the old data from memory if it needs it again, which takes more time than if that data were still in the cache.

This process of replacing cache data, called cache eviction, requires that the CPUs spend time copying the data that they need, which increases the time it takes for threads to complete their execution. To minimize this execution time, minimizing cache evictions is crucial.

HAProxy accomplishes this using a mechanism called zero-copy forwarding or fast-forwarding. This concept of fast-forwarding helps prevent L3 cache evictions by avoiding additional buffering for data wherever possible. This reduces the number of times that data must be copied, and therefore, reduces the required number of CPU cycles. 

HAProxy avoids excess buffering by only reading data when needed, determining how much data can be read directly from one network buffer (such as the server) to another (the client) without requiring intermediate buffering. Per connection, this significantly reduces both the memory required and the number of CPU cycles needed to copy data, as the data is read directly from one buffer to another.

The H1, H2, and QUIC muxes, which handle connection processing, fully support fast-forwarding. Applets, which are custom processing functions, and the cache also support fast-forwarding. This means these channels process connections and data with as few intermediate buffering steps as possible, which dramatically improves performance.

Better scalability with many threads

Thread groups, introduced in version 2.7, enable HAProxy to keep data local to only groups of close threads, which minimizes data transfer time between cores. In version 3.2, many critical components, including the round-robin and leastconn load balancing algorithms, received updates that make them thread-group aware, which improves scalability with more threads and overall performance.

Improvements to load-balancing algorithms

Before version 3.2, the round-robin load balancing algorithm operated by having all CPUs share the same index of available servers, which meant that the list had to be updated for every CPU with every request. Now, with support for thread groups, the round-robin load balancing algorithm is implemented such that each thread group maintains its own copy of the list. This means that other thread groups are not impacted by updating the copy of the index belonging to any one group, and can continue processing. Server properties, such as health checks and weights, are shared across all groups to maintain synchronization. Ultimately, this results in round-robin having much better scalability with more threads.

The leastconn load balancing implementation, which uses locking more frequently than the other algorithms, has had its memory model reworked with a focus on reducing contention. Leastconn, which tries to choose the least-loaded server, faces challenges because the number of connections to servers changes during the server selection process. The implication here is that the number of connections per server must be locked as each thread retrieves them, resulting in more locking contention. HAProxy manages this intelligently by arranging "bins" of servers grouped by similar numbers of active connections, from which the algorithm can randomly choose an equally eligible server. Benchmarks showed that by reducing this locking contention, the request rate doubled on a 64-core system. 

For both of these load balancing algorithms, this ultimately means that HAProxy can choose the appropriate backend server for routing traffic more quickly, thereby significantly improving request processing time.

Reduced lock contention

As for locks, which are required for multithreaded applications to ensure data integrity when the same data is accessed by multiple entities (threads), the fewer locks that are required, the faster data can be processed. When a resource (some data) is locked, it can't be used by any entity other than the one that locked it. The other entities must then wait their turn, which slows processing. Many of the improvements in version 3.2 focused on reducing lock contention by restructuring components such that they are thread group-aware, which limits the number of threads that need to acquire any particular lock. Additionally, the locks in many critical components are now implemented with exponential backoff, which is a mechanism by which threads retry to obtain locks that reduces thread congestion and helps prevent system overload.

Atomic operations improve lock contention as well, as they reduce the amount of heavy locks required. Available atomic functions vary per system architecture, and the most recent HAProxy versions include updates that use the most performant atomic functions when they are available. HAProxy's lockless memory pools use atomic functions to manage memory allocation and deallocation, which further reduces the overhead for these operations.

Queues, cache, SPOE engine, and stick table improvements

As of version 3.2, queues are arranged by thread groups and favor group-local pending requests for short bursts in order to eliminate the heavy locking contention between distant CPUs. Queues were previously very CPU-intensive because of the cost of data sharing between distant CPU cores when there was only a single list for all threads. This is quite similar to what was already done for persistent connection management. Additional improvements have been made to the HTTP cache, resulting in significantly less lock contention. The SPOE engine was completely rewritten in version 3.1 to benefit from a mux-based architecture, allowing idle connection sharing between threads and per-request load balancing. 

Stick tables have seen several recent improvements as well, including significantly reduced lock contention during updates from peers, and locking that scales much better with threads, as lookups are now disentangled from peer updates thanks to fixes regarding cache line sharing. Stick-tables are now sharded over multiple tree heads that each have their own locks, which also significantly reduces locking contention on systems with many threads. The need for stick-tables to efficiently broadcast every change to all connected peers in itself represents extremely difficult challenges. There have been several redesign attempts, and developers are working on further improving this; expect news on this front coming in versions 3.3 and 3.4

Automatic CPU Binding

With all these updates and multithreading optimizations, how do you configure HAProxy to fully utilize your hardware resources? In version 3.2, it's just a simple and portable configuration directive. Add the following cpu-policy to the global section of your configuration:

global  
 cpu-policy performance

When set to performance, HAProxy will enable all threads and organize them into thread groups that reflect the layout of your CPUs, and assign them to groups of appropriate CPUs. This is often referred to as CPU affinity, CPU pinning, or CPU binding. While you can still manually assign your CPU affinity, HAProxy offers several cpu policies to help you build configurations that are automatic and portable.

Here is an example of a system with a single NUMA node with 4 CCX. Each CCX has 8 cores that share a single L3 cache. In version 3.2, when no cpu-policy is set, HAProxy defaults to cpu-policy first-usable-node, wherein a single NUMA node is used with a single thread group with as many threads as there are available CPUs. This means that all CPUs can share data with each other, regardless of their locality, which may not always be the most performant configuration.

Run HAProxy with the -dc argument to see how it has arranged its threads on your CPUs. For this particular example, it produces the following:

Thread CPU Bindings:

  Tgrp/Thr  Tid        CPU set
  1/1-32    1-32       32: 0-31

Thread CPU Bindings:

Tgrp/Thr  Tid        CPU set
1/1-8     1-8        8: 0-7
2/1-8     9-16       8: 8-15
3/1-8     17-24      8: 16-23
4/1-8     25-32      8: 24-31

Be sure to test this configuration before implementing it in production to ensure that it indeed provides better performance and doesn't conflict with any other CPU affinity settings you may have for other applications. Also, you should not add this directive if you are already manually assigning CPU affinity using nbthread, thread-groups, and cpu-map, as these settings conflict with each other, though you can use the new settings to replace your existing configuration. 

For more information, including important considerations and instructions for analyzing your system and configuration, see our configuration tutorial. This tutorial addresses potential performance issues you may encounter, and explains possible solutions for the versions of HAProxy that support thread groups (versions 2.7 and higher). There are also options for tuning the automatic binding in version 3.2 onwards, should you want finer-grained control of which CPUs HAProxy will use.

Real-world performance improvement

Want to see a real-world example of HAProxy's CPU affinity settings in action? Check out Criteo's talk at HAProxyConf 2025. In his talk, Basha Mougamadou walks you through how, with only a few configuration directives, they tuned HAProxy's CPU binding settings using HAProxy 3.2 for their specific use case on AMD EPYC 7502P Zen 2 processors, resulting in a 20% decrease in their CPU usage with the same level of network traffic, thanks to HAProxy's more efficient use of the CPUs in version 3.2. This leaves more CPU available for other applications, including the kernel.

Modern CPU architectures, optimized to maximize total per-chip throughput, present challenges for multithreaded applications. Through automatic CPU binding and intelligent thread management, HAProxy turns these challenges into strengths, while still maintaining its original principles that technically complex features must remain easy to configure.

Combined with optimizations in the most recent versions of HAProxy, including zero-copy forwarding, reduced lock contention, exponential backoff in locks, and important improvements to queues, load balancing algorithms, memory pools, and other core components, HAProxy can efficiently and effectively leverage the power of modern CPUs, no matter the scale.

The answers were eye-opening. Engineers shared stories of 40% resource overhead, multi-second latency spikes during peak traffic, and infrastructure bills that had nearly doubled since mesh adoption. One architect told us they were spending more time managing their mesh than building features.

But beyond costs, a second theme emerged in nearly every conversation: the complexity of federating services across fractured environments. As teams expand beyond a single cluster, they are struggling to connect workloads across services and clouds.

These conversations made it clear that teams are hungry for a better path forward. That’s why we presented two sessions at KubeCon: a keynote overview and a technical demonstration, introducing our vision for solving both cost and connectivity challenges — Universal Mesh. The response confirmed what we have long known: the service mesh dream hasn't matched the reality for many organizations.

This post recaps our KubeCon sessions, explores the challenges Universal Mesh solves, and explains why this approach resonated so strongly with the technical community.

TL;DR

• The problem: Current service mesh architectures create significant resource overhead (30-50% infrastructure cost increase) and struggle to federate Kubernetes workloads across clusters and clouds, as well as non-K8s resources.

• The solution: Universal Mesh shifts focus from per-service proxies to strategic gateways at network boundaries, acting as a unified federation layer.

• The results: Mesh benefits (mTLS, observability, traffic control) without the per-service overhead, plus seamless connectivity across clusters and clouds.

• See it live: PayPal runs this architecture at massive scale (they call it "Meridian").

The service mesh reality check: what we heard at KubeCon

Traditional service mesh architectures operate well within Kubernetes but struggle to integrate these diverse environments. At our booth, two problems came up in nearly every conversation.

Problem 1: the "mesh tax" is real

The mesh tax refers to the resource overhead and performance impact of current service mesh approaches. Engineers shared specific pain points:

• Sidecar model: Deploying a proxy alongside every application pod is expensive. Each sidecar typically consumes 0.5-1 CPU cores and 512MB-1GB of RAM. Every request traverses the sidecar proxy twice (outbound and inbound), adding 2-10ms of latency per hop. One team told us they had deployed over 800 sidecars across their clusters, consuming more resources than their actual applications.

• Sidecar-less model: While this improves resource usage, it often shifts complexity to distributed components, like a Layer 4 proxy per node and Layer 7 proxies per namespace. Organizations reported that troubleshooting became harder, and upgrades still required careful orchestration across dozens of components.

The bottom line: teams reported 30-50% infrastructure overhead from mesh components alone, along with performance impacts that forced them to over-provision their clusters.

Problem 2: the multi-cloud federation challenge

The integration wall has become an operational obstacle for platform engineers tasked with multi-cloud federation.  Teams are finding it difficult to:

• Send traffic outbound: Enabling services inside the mesh to securely call external resources (like AWS Lambda, RDS databases, or legacy APIs on VMs) requires custom workarounds.

• Receive traffic inbound: Allowing non-K8s resources, such as virtual machines or bare-metal servers, to securely call services inside the mesh often means maintaining separate API gateways, VPN tunnels, and certificate infrastructure.

For example, one engineer described spending weeks building a solution for a simple use case: letting a Lambda function authenticate to a Kubernetes service across AWS and Azure. The final setup involved custom API gateways, VPN configuration, and complex certificate management.

This is the friction of federating complex infrastructure. Existing solutions lack unified observability and security policies across these boundaries, creating blind spots and compliance headaches.

A paradigm shift: focus on the boundary, not the service

The industry has been hyper-focused on managing connectivity at the service level, but we believe the real challenge lies at the network boundary.

Instead of deploying 500 sidecar proxies for 500 pods, what if you deployed 3-5 strategic gateways at critical network boundaries — your cloud provider edges, your on-premises perimeter, your cluster boundaries? These gateways handle all cross-boundary traffic and act as the glue for your federation strategy, while services communicate directly within their trusted zones.

This is the core idea behind Universal Mesh. It's not an incremental improvement, but a fundamental shift that provides unified security, federated connectivity, and observability across every environment, from VMs and bare metal to Kubernetes and serverless functions.

KubeCon session highlights

We explored the Universal Mesh concept in depth during our two sessions.

Keynote: A vision for simplified connectivity

The core problem

Frank argued that the problem isn't the service — it's the boundary. Managing thousands of individual service proxies creates operational complexity and resource drain. The solution is to shift focus to strategic gateways at network boundaries.

The Universal Mesh approach

Universal Mesh converges Ingress, Mesh, and Proxies into a single, unified data plane. Rather than distributed components scattered across your infrastructure, you deploy high-performance gateways at network boundaries that handle cross-boundary traffic.

Quantifiable benefits

By removing sidecars and distributed components, organizations can:

• Reduce resource overhead by 30-50%

• Decrease per-request latency by 5-15ms

• Simplify operations — upgrades happen at gateway boundaries, not across thousands of pods

• Cut infrastructure costs while improving performance

Built for real-world complexity

The architecture is designed from the ground up for multi-cluster and hybrid-cloud environments. Federation isn't bolted on — it's fundamental to how Universal Mesh works.

Jakub Suchy, Director of Solutions Engineering, led a demo theater session that demonstrated how Universal Mesh works in practice, utilizing HAProxy Fusion (the control plane) and HAProxy Enterprise (the data plane), which is built on HAProxy’s reliable and high-performance open source core.

Connect everything

Jakub demonstrated how Universal Mesh provides a single pattern for connecting both greenfield (Kubernetes) and brownfield (VMs, legacy) applications across different cloud providers and on-premises locations.

The highlight: a Lambda function authenticating to a Kubernetes service across AWS and Azure — something that typically requires custom API gateways, VPN tunnels, and complex certificate management. With Universal Mesh, it took three configuration lines and worked immediately.

Operational simplicity

The demo showcased the ease of adding new services and managing traffic routing. Jakub demonstrated automatic failover to a backup region when a primary cluster became unavailable — no manual intervention, no complicated runbooks, just policy-based routing at the gateway.

Centralized control

Critical functions, such as mTLS (Zero Trust), web application firewall (WAF), authentication, rate limiting, and advanced traffic splitting, are applied consistently at the gateways across the entire mesh. One policy, one place, enforced everywhere.

Universal Mesh deploys HAProxy gateways at strategic network boundaries. These gateways handle all cross-boundary traffic, whether that's between clusters, between Kubernetes and VMs, or between cloud providers.

Services within a trusted zone communicate directly without proxies. When they need to cross a boundary, the gateway provides security (mTLS), observability (e.g., metrics and tracing), and traffic control (routing, failover, rate limiting).

The result: you get mesh benefits without per-service overhead.

Why Universal Mesh resonates

Universal Mesh addresses the real-world pain points we heard at KubeCon:

Performance first: It eliminates the latency and resource overhead of sidecars by leveraging the world's fastest software load balancer at strategic points. No more 2x proxy hops, no more gigabytes of RAM consumed by mesh infrastructure.

True flexibility: It allows for mixed topologies — running gateways external to Kubernetes for traditional infrastructure or within clusters for cloud-native workloads. This bridges the gap between legacy systems and modern applications without forcing a rip-and-replace migration.

Simplified multi-cluster: The architecture is designed with federation and multi-environment spanning in mind, without architectural compromises. Organizations running clusters across AWS, Azure, GCP, and on-premises data centers manage them all through a unified control plane.

By shifting focus from the service to the boundary, Universal Mesh offers the benefits of a service mesh with a fraction of the cost and complexity.

Real-world validation: PayPal's "Meridian"

This isn't just theory. PayPal runs this architecture at massive scale across hybrid cloud environments. They call their implementation "Meridian," and it handles billions of transactions monthly.

Their HAProxyConf 2025 session details how they eliminated the “mesh tax” while improving reliability and simplifying operations. They describe the specific challenges they faced with traditional mesh approaches and how the boundary-focused architecture solved them.

It's a powerful real-world example of Universal Mesh succeeding at enterprise scale.

Watch the PayPal Session: Building Bridges Across Clouds: The PayPal Approach to Unified Business Communication.

Who should care about Universal Mesh?

Universal Mesh is particularly relevant if you:

• Run multi-cluster Kubernetes deployments across cloud providers or regions/availability zones

• Struggle with service mesh resource overhead or performance issues

• Need to connect Kubernetes workloads with legacy systems, VMs, or serverless functions

• Manage hybrid cloud environments spanning on-premises and multiple public clouds

• Want mesh benefits (mTLS, observability, traffic control) without the operational complexity

What's next?

The KubeCon response confirmed what we have long known: organizations need a better way to manage modern connectivity challenges. We're committed to helping you adopt this architecture.

We will be releasing a detailed implementation guide in early 2026. In the meantime, contact our solutions team now to discuss your specific infrastructure and discover the measurable performance and cost benefits of adopting the Universal Mesh architecture.

Thank you to everyone who stopped by our booth and attended our sessions at KubeCon. The conversations were invaluable, and we're excited to help you eliminate the mesh tax.

Their story provides a powerful blueprint for any organization that must deal with hyperscale growth efficiently, while maintaining robust security throughout.

Roblox uses HAProxy Enterprise as the gateway for external traffic to their edge data centers, powering an agile, engineering-led DevOps environment, allowing for stable operations and rapid scaling to support hot new experiences. Scalability, a core feature of HAProxy Enterprise, is also supported by the stellar performance of the HAProxy Enterprise WAF (see video).

Scalability is crucial to Roblox (and many other UGC hosts). A recent public filing showed that daily active users have increased beyond the 97.8 million cited in the talk to 111.8 million users. Engagement was up nearly 60% year over year. 

One new game, Grow a Garden, drew 30 million simultaneous users recently. “Out of nowhere, my boys have become expert virtual gardeners,” says one proud mother on LinkedIn. Rapid growth depends on smooth, glitch-free operation for users — even as new users are flooding into a popular game.

This rapid, efficient scaling would not have been possible under the limitations of their previous load balancing infrastructure, setting the stage for a dramatic shift.

HAProxy Enterprise powers innovation

Before the COVID-19 pandemic, Roblox used F5 hardware appliances for load balancing. However, "tremendous user growth" as people were stuck at home during the pandemic revealed the limits of their setup. The physical load balancers were inflexible and "no longer cost-effective."

• Inflexible scaling: The cluster-based model meant that when a cluster became overwhelmed, a new cluster had to be manually deployed, which "didn't scale".

• Manual and complex configuration: The initial configuration was done "by hand" with no automation for adding new VIPs , and the vendor's automation framework required "full submission to their technology to scale the way that we wanted to".

• Cost and slow delivery: The cost of the deployment began to "exceed the value that it's actually providing" , and acquiring new physical chassis could take "up to six weeks" when capacity crunches occurred.

This forced a strategic shift to a software-based solution. Roblox evaluated its options and chose HAProxy as its “load-balancing solution of choice,” featuring "fantastic performance." The move solved their immediate scaling and cost problems.

RLB allows service owners to self-register and configure their own load balancing settings—such as choosing between round-robin or least-connection algorithms—simply by adding tags to their service registry. Running on Nomad makes the system "self-recovering," automatically rescheduling failed instances to prevent any loss of capacity and taking advantage of the rock-solid reliability of HAProxy Enterprise.

Leveraging core features for the win

Specific features of HAProxy Enterprise have helped Roblox create a powerful enterprise solution that delivers one of the most robust, capable, and fun user environments in the world.

Dynamic updates for GitOps integration

HAProxy Enterprise Dynamic Updates “allow you to update the contents of some things, like map files, without needing to reload HAProxy. Very handy.” Figure 1 shows a slide from the Roblox presentation, describing how they use the HAProxy Enterprise Dynamic Update Module.

High-performance security

The HAProxy Enterprise Web Application Firewall (WAF) is a “single, centralized security solution” with “great logs and metrics,” replacing inconsistent tools. Roblox uses the Dynamic Update pipeline to enable safe, gradual WAF deployments. The security team can onboard a service or ramp up enforcement by using a pull request to change a value in a map file — again, with no reloads. This leads to "very reassured and very happy service owners.”

Roblox describes HAProxy’s stick tables as “flexible, high-performance key-value stores built into HAProxy.” And HAProxy Enterprise’s Global Profiling Engine (GPE) allows them to “collect and aggregate ... stick table data across HAProxy instances and clusters, providing a more unified setup.”

Docker container 

The HAProxy Enterprise Docker Container is very popular among HAProxy Enterprise features. Customers are increasingly orchestrating their environment with Kubernetes, Nomad, and other powerful platforms. Containers make it easy to modify HAProxy Enterprise in a visible and manageable manner. And the Docker container is always up-to-date, so it contains the latest and greatest code, along with security patches and feature updates. Roblox had been building and maintaining their own container; now, HAProxy Enterprise gives them an updated, tested, reliable, supported version.

Customer support

The team praised HAProxy Technologies’s customer support, noting that it is a "huge relief to just be able to ask someone who intimately knows the software for input.” When a new vulnerability is announced, “there is nothing more reassuring than knowing that we're already protected thanks to WAF.” And the Roblox team would “recommend partnering with HAProxy Technologies for getting sanity checks on configurations.”

Automating the build pipeline

Roblox has even automated the deployment of updates to HAProxy itself. They’ve used GitHub Actions to create a full CI/CD build pipeline. Every day, they pull the latest HAProxy Enterprise Docker Container and deploy it to a canary fleet, 5% of the total. They monitor key metrics, using custom tracking they have developed in-house. Once successful, the build is promoted to the entire production fleet.

Conclusion: a blueprint for modern application delivery

Roblox moved from a reactive, hardware-based model to a proactive, software-defined platform, with HAProxy providing foundational technology. Roblox leverages HAProxy's performance and efficiency, its containerized ecosystem, and the advanced features of HAProxy Enterprise. The HAProxy-powered Roblox system can handle the unpredictable demands of a global gaming platform, proving that it is possible to achieve performance, security, and agility at hyperscale.

Find out how HAProxy Enterprise can protect your applications and simplify operations with a free trial.

Our new downloadable HAProxy packages, compiled using the AWS-LC TLS library, provide the simplest way to get the latest and best-performing version of HAProxy for your flavor of Linux. HAProxy’s class-leading SSL/TLS processing is even better with support for ACME DNS-01 challenges, automatic SNI, Encrypted Client Hello, Linux Kernel TLS, and more. Persistent stats over reloads enabling continuous, uninterrupted metrics for dashboards and alerting systems. Improvements to default settings and CPU/memory management make HAProxy 3.3 the fastest and most efficient HAProxy yet. Experimental support for QUIC on the backend provides expanded interoperability and helps ensure future-proof compatibility with the QUIC protocol.

In this blog post, we’ll explore all the latest changes in detail. As always, enterprise customers can expect to find these features included in the next version of HAProxy Enterprise.

Register for our webinar HAProxy 3.3: Feature Roundup and listen to our experts as we examine new features and updates and participate in the live Q&A.

New to HAProxy?

HAProxy is the world’s fastest and most widely used software load balancer. It provides high availability, load balancing, and best-in-class SSL/TLS processing for TCP, QUIC, and HTTP-based applications.

HAProxy is the open source core that powers HAProxy One, the world’s fastest application delivery and security platform. The platform consists of a flexible data plane (HAProxy Enterprise) for TCP, UDP, QUIC and HTTP traffic; a scalable control plane (HAProxy Fusion); and a secure edge network (HAProxy Edge).

HAProxy is trusted by leading companies and cloud providers to simplify, scale, and secure modern applications, APIs, and AI services in any environment.

​How to get HAProxy 3.3

You can install HAProxy version 3.3 in any of the following ways:

• Install the new HAProxy packages for Ubuntu / Debian (version 3.3 available here soon).

• Run it as a Docker container. View the Docker installation instructions.

  • (Note that Docker containers built with the HAProxy performance packages with AWS-LC will be available later.)

• Compile it from source. View the compilation instructions.

Performance packages

Get started with the performance packages here.

Security and TLS

ACME

HAProxy 3.3 extends the ACME implementation from version 3.2 by adding support for DNS-01 type validation challenges alongside the existing HTTP-01. A validation challenge is the method that ACME providers, such as Let's Encrypt, utilize to verify that you own the domain for which you're requesting a TLS certificate.

HAProxy supports this via the HAProxy Data Plane API version 3.3 (coming soon), which handles the communication between HAProxy and the DNS provider. During the DNS-01 challenge, the ACME provider sends a secret phrase that must be added as a DNS TXT record, establishing ownership of the domain. The HTTP-01 challenge accomplishes the same thing by adding the secret phrase to a file on the web server. In both scenarios, HAProxy and the HAProxy Data Plane API seamlessly automate the entire process.

Once the validation is complete, the ACME provider issues a TLS certificate. New in this version, the HAProxy Data Plane API will automatically store the certificate on the load balancer's filesystem, eliminating manual management. However, you should use this functionality only with single load balancer deployments. For multiple load balancer deployments or clusters, you'll need manual synchronization of the certificates, though HAProxy Fusion offers cluster-wide certificate management capabilities out of the box.

SNI

Configuring server-side TLS is now simpler as HAProxy can automatically set an SNI value from the host HTTP header and forward it to the backend server. Previously, this required manual configuration using sni req.hdr(host) on the server line. You can disable this automatic behavior by setting no-sni-auto on the server line, or explicitly re-enable it with sni-auto. Similarly, the check-sni-auto and no-check-sni-auto arguments allow explicit control of the automatic SNI value sent in health checks.

Also, you'll get a warning now if you try to use the strict-sni and default-crt arguments together on a bind directive in a frontend. This relates to setting default TLS certificates in your frontend: When you set a bind directive's crt argument to a directory instead of a single certificate file, HAProxy selects a certificate from that directory that has a CN or SAN field matching the SNI value the client sent. The default-sni argument lets you fall back to a default certificate if no other certificates match. Meanwhile, the strict-sni argument requires the SNI to match a certificate. The two don't make sense to use together and so are mutually exclusive.

Certificates with passphrases

A new global directive, ssl-passphrase-cmd, enables HAProxy to unlock TLS certificates that have a private key protected by a passphrase. The directive specifies a script that returns the passphrase when invoked with the key. HAProxy optimizes the process by trying all previously retrieved passphrases before re-invoking the script.

Encrypted Client Hello

A new, experimental bind argument, ech, enables HAProxy to use TLS ECH (Encrypted Client Hello). This new feature encrypts the ClientHello message sent to the load balancer, protecting sensitive fields including the SNI field, so they remain private and only decryptable by the target server. Using this argument requires the global directive expose-experimental-directives. Additionally, ECH requires clients to retrieve the public key from DNS, so first add your public key to your DNS configuration.

Kernel TLS

HAProxy 3.3 adds support for Kernel TLS, wherein the Linux kernel takes over handling the symmetric cryptography part of the TLS processing. It's beneficial because it allows HAProxy to offload cryptographic work to the kernel after it's performed the initial TLS handshake. The kernel handles further decryption and encryption without copying the data to HAProxy's userland process. Then data are encrypted/decrypted on the fly during the transfer from userland to the kernel. That in itself saves resources, particularly on high-speed links of 100 Gbps and above.

Even greater benefits come with end-to-end TLS, in which HAProxy manages TLS connections between itself and the client, and also between itself and the backend server. In that case, you can enable Kernel TLS on both ends. Then, optionally, enable kernel-based TCP splicing to transfer the data directly from the client socket to the server socket entirely at the kernel level without ever passing the data to the userland software, saving two memory copies!

You must compile HAProxy with flags for Kernel TLS and splicing, although both are enabled in the linux-glibc build target, which users commonly use. You'll need to run HAProxy with OpenSSL 3.x or the latest AWS-LC library. Set expose-experimental-directives in the global section. Add the ktls on argument to your bind directive and, if using end-to-end TLS, to your server directives. Then, to enable splicing, add option splice-auto to the frontend.

Preprocessor conditions

New preprocessor conditions help you to add sections to your configuration only when the statement is true.

OAuth authentication

HAProxy has supported validating JWTs (JSON Web Tokens) since version 2.5, which are necessary for OAuth 2.0 authentication. As part of the validation, HAProxy will, via the jwt_verify fetch method, check the signature embedded in the JWT against a public key that you got from the OAuth identity provider. However, providers often don't provide the keys directly, but embed them inside X.509 certificates. It had been a manual step to extract the key from the certificate. Now, with the new jwt_verify_cert fetch method, you can download the certificate and HAProxy will do the work of extracting the key from it, facilitating automation. 

To use a certificate with jwt_verify_cert, first declare it with a load directive in a crt-store section and set its jwt argument to on. The jwt argument is new in this version.

Other security changes

This version has a few other security-related changes:

• You'll now get a warning at startup if you're running HAProxy as root and your configuration is missing the global directive user, which sets a Linux user account that HAProxy should run as. HAProxy runs with superuser privileges during initialization so that it can perform necessary tasks, such as binding to privileged ports, but afterwards, it's best if it can drop those privileges and become another user. The warning will nudge users towards adopting this security best practice. You could even set the user directive to root, but at least then it'd be explicit.

• New bind and server arguments named tcp-md5sig adds support for Protection of BGP Sessions via the TCP MD5 Signature Option, which many routers require when placing a TCP proxy like HAProxy between them.

Observability

Persistent stats

You can now store frontend, backend, and server statistics in Linux's shared memory so that they can be preserved after reloading the configuration. These are the statistics you see on the Stats page and when calling the Runtime API command show stat. The feature is experimental, but the steps are:

1. Add the expose-experimental-directives and shm-stats-file global directives.

2. Add GUIDs to your frontends, backends, and servers. The GUIDs must be unique within your configuration.

3. Reload HAProxy to see that the stats were preserved. Restarting it will lose the statistics.

Example configuration:

The new acme and ssl trace sources let you monitor ACME and SSL events. In this example configuration, we start tracing ACME events, which will be sent to standard out:

• The default load balancing algorithm is now random instead of roundrobin, when not otherwise set with the balance directive in a backend. This has demonstrated superior performance and improved fairness between uneven servers, but please read more about this change in this discussion. Note that the random algorithm works out of the box as a Power-of-Two algorithm, which allows it to randomly draw two servers from the list and then choose the least loaded one from those two.

• HAProxy's cpu-policy now defaults to performance, meaning that on systems with a heterogenous mix of efficiency and performance core types, the load balancer will run on only the performance cores. For more information about cpu-policy, see tuning the load balancer’s automatic CPU binding. Also, HAProxy will automatically use all available cores and NUMA nodes on NUMA systems and the maximum number of threads is no longer limited to 64, which matters for machines that have more than 64 cores, particularly on non-NUMA systems. The increased processing capacity benefits CPU-intensive use cases such as TLS, Lua, and regex.

• Frontend, backend, and server-related event counters are now stored per thread group, which reduces bottlenecks when accessing the counters.

• Backends with mode http now set option abortonclose by default. This setting tries to stop processing a request before it's been sent to a server if the client aborted on their end, such as by closing the tab or refreshing. Also, you can now set option abortonclose in a frontend, which wasn't allowed before, and HAProxy will avoid computing the TLS handshake on connections that are already closed.

• HAProxy saves resources by no longer allocating memory for a default-server directive unless you declare one in your configuration. Also, after parsing the directive, HAProxy releases the memory associated with it.

• When using a use-server directive or track argument in a backend, startup will be faster now that HAProxy uses a more efficient algorithm for finding the server.

• You can now choose a different TCP congestion algorithm by setting it with the new cc argument on a bind or server line.

• This version relaxes the amount of locking between stick tables and peers by batching the updates and delaying work, leading to a smoother traffic flow and better overall performance.

• Some multi-threaded tasks that caused a lot of contention on servers with many CPUs, such as stick table expirations and resolvers connections, were changed to be single threaded.

• HAProxy's internal HTTP client, which it uses for tasks such as sending requests to ACME servers, had yielded control of the thread in between sending the HTTP headers and sending the HTTP body. That isn't necessary if HAProxy has the headers and body ready to send. In this release, HAProxy will send both, if possible.

• In this version, the way that HAProxy connects to DNS nameservers was changed. Previously, if an outage caused by a main route to the nameservers being down might cause the packets to use an alternative route and interface, but then not revert to the main route once it became available again,  HAProxy will now correctly revert to using the main route. Instead of using the connect() and send() functions, HAProxy now performs a bind on the wildcard address for the datagram AF_INET* client socket, then uses sendto() instead of send().

• Multithreaded applications may experience performance hits when multiple threads modify data, even if unrelated, in the same cache line, which may invalidate the cache line for other threads and cause a cache eviction. Updates to this version include some initial work towards optimizing HAProxy's memory allocation functions such that they align some objects and memory pools along cache line boundaries (64-byte chunks). Allocating memory aligned to the cache line boundaries helps keep data grouped by locality which prevents multiple threads thrashing the cache when the data is unaligned. This results in less contention, less locking, and fewer cache evictions.

• In this version, the mechanisms reusing and purging server-side idle connections saw improvements. Connections created when http-reuse is set to never or when using Basic Authentication can now be purged, preventing resource leaks, and some related features, such as deleting a server via the HAProxy Runtime API, will work more reliably, as the servers' idle connections are now better managed.

Flexibility

HTTP/3

You can now connect to backend servers with HTTP/3 over QUIC. After ensuring that your backend web server supports HTTP/3 and has it enabled, configure HAProxy to use the protocol. Because it's an experimental feature, add the expose-experimental-directives global directive. Then, update your servers to use quic4@ before the address and set the TLS arguments.

• tune.quic.be.cc.cubic-min-losses

• tune.quic.be.cc.hystart

• tune.quic.be.cc.max-frame-loss

• tune.quic.be.cc.max-win-size

• tune.quic.be.cc.reorder-ratio

• tune.quic.be.max-idle-timeout

• tune.quic.be.sec.glitches-threshold

• tune.quic.be.stream.data-ratio

• tune.quic.be.stream.max-concurrent

• tune.quic.be.stream.rxbuf

• tune.quic.be.tx.pacing

• tune.quic.be.tx.udp-gso

• tune.quic.listen

• tune.quic.mem.tx-max

The global directives that were prefixed with tune.quic.frontend still exist, but are deprecated in favor of the directives prefixed with tune.quic.fe. A few other QUIC directives were also deprecated, as the naming is consolidated.

Also in this version, the no-quic global directive has been renamed tune.quic.listen, which you can set to on or off to enable and disable the QUIC protocol.

Fetch methods

New fetch methods in this release are:

Converters

New converters in this release are:

Also, the aes_gcm_dec and aes_gcm_enc converters now accept an optional AAD argument that's sometimes required for authentication.

Runtime API

The HAProxy Runtime API has these changes:

• The add ssl crt-list command will no longer verify that the certificate's path matches its name in memory. That's because when using crt-store and crt-list together, you might assign aliases to your certificates, which wouldn't work with the previous path-based name validation. It's up to you to ensure that the certificate you're adding to the crt-list has the correct path, if not an alias.

• The show dev command, which displays platform and environment information, now reports the thread-to-CPU bindings.

• The show info command, which displays process information, now reports the number of added and removed lines in map and ACL files, to better detect scripts that continuously add entries, but don't remove entries as expected.

• When calling the show stat command with the typed argument, it now shows next to each metric the letter V for volatile or P for persistent. These appear after the already existing origin, nature, and scope letters in the output. This is part of HAProxy's new support for persisting metrics across reloads.

Usability

• You can get the HAProxy version in different formats. Pass the command-line arguments -vq for version, -vqs for the short version, or -vqb for the branch.

• If you've set the expose-experimental-directives global directive, but all of the experimental features you were using are no longer experimental, you'll get a reminder to remove the directive. That should help users in avoiding having experimental features enabled unintentionally.

• The global directive dns-accept-family that was introduced in the last version now defaults to the value auto. This directive lets you disable IPv4 or IPv6 DNS resolution. A value of auto will enable IPv4 DNS resolution and check for IPv6 connectivity at startup, then again every 30 seconds to determine whether to enable IPv6 resolution.

• Setting the global directive nbthreads to a total number of threads on which HAProxy should run while also declaring a thread-groups directive with a range of threads that exceeds that number will now emit a warning, and the missing threads will be removed. If a thread group is left with no threads at all, it causes a startup error.

• For users who compile HAProxy statically, an error can arise if they then try to use the user and group global directives, due to a known limitation in  libc. HAProxy will now emit a warning at startup if it detects this. In this case, use the uid and gid directives instead.

• Use the shell script haproxy-dump-certs to easily dump certificates from the HAProxy stats or master socket to the filesystem. Although, for those using the Data Plane API to enable ACME providers like Let's Encrypt, the API will save the certificates for you.

• The directive tune.disable-fast-forward is no longer experimental, so you don't need to set expose-experimental-directives to use it. This directive was introduced in version 2.8 and disables data fast-forwarding.

• For debugging, you may want to prevent all workers from being killed when a segfault occurs. You can use the global directive master-worker no-exit-on-failure.

• The default number of reloads defined by mworker-max-reloads is now 50.

• To build the halog utility, run make install-admin instead of make install. This change will help to ensure that users build halog with the correct options.

Modernization of subsystems

All applets, including the DNS, http-client, Lua, logs, peers, and Prometheus applets which were updated with this release, now maintain their own buffers rather than share buffers with the stream, which is used for socket reads and writes. Each applet having its own buffers requires less locking and improves synchronization, which reduces contention across the applets, improving the applets' scalability.

Deprecated features

These features are now deprecated, meaning they will be removed in a future version: 

• The backend directives dispatch and option transparent are deprecated and will emit a warning to replace them if used.

• Global directives prefixed with tune.quic.frontend are deprecated. Use the same directives prefixed with tune.quic.fe instead.

• The master-worker global directive has been deprecated. Use the command-line arguments -W or -Ws instead.

Breaking changes

This version has the following breaking changes:

• The minimum, default Linux kernel version, the one corresponding to the build target linux-glibc, has been updated to 4.17, which is a version older than all of the currently maintained LTS distros. This version was needed to support the new Kernel TLS feature.

• The program section, which allows you to start and run an external program as a child process, was deprecated in version 3.1 and is now removed.

• Using the same name for more than one frontend, backend, listen, defaults, or log-forward section is no longer allowed. Duplicated names, which have emitted a warning since version 3.1, will now emit an error at startup.

• Using the same name for more than one server in a backend isn't allowed.

• When configuring email alerts, you must enable the Lua implementation. If you add a mailers configuration section, but forget to load the Lua file, you'll get an warning.

• The backend directive http-send-name-header, which lets you send the name of the server HAProxy is connecting to as an HTTP request header, had always let you decide which HTTP header to use for that purpose. But now, it won't allow you to choose the headers connection, content-length, host, or transfer-encoding. Overwriting those headers would only cause an invalid request.

• When declaring an ACL, you can set the match type via the -m flag to explicitly compare the input value as a boolean, string, integer, etc. Specifying more than one match type after this flag is no longer allowed. Previously, HAProxy had silently used the last match type. Also, HAProxy will emit a warning when the match type is ambiguous, such as in path_beg -m reg. Is it matching the beginning of the path or using a regular expression?

• This version renames the no-quic global directive to tune.quic.listen, which lets you enable or disable the QUIC transport protocol on all frontend listeners.

Conclusion

HAProxy 3.3 is a feature-rich release that continues to make application delivery simpler, more scalable, and more secure. This release improves SSL/TLS processing and automation, observability, performance, flexibility, and usability, benefiting organizations of all sizes with lower operational costs, increased operational efficiency, and more reliable services.

Ready to upgrade or make the move to HAProxy? Now’s the best time to get started.

Additional contributors: Nick Ramirez, Iwan Price-Evans

This news has understandably caused a wave of anxiety. Ingress NGINX is one of the most popular controllers, and with the community now racing to find stable, supported, and future-proof alternatives, we've been inundated with questions.

Our message is simple: We are here to help.

Here at HAProxy, we have a clear path to help Ingress NGINX users migrate to a more powerful, reliable, and fully-supported solution. Whether you need an immediate fix or a long-term strategic upgrade, we have you covered.

Register for our webinar Life After Ingress NGINX: A Zero-Stress Migration Guide to HAProxy and listen to our experts and participate in the live Q&A.

Immediate choice: HAProxy Ingress Controller

For teams facing a tight migration deadline, the HAProxy Kubernetes Ingress Controller is the easiest, most immediate, and most direct replacement. You get a stable, production-ready solution right now for the smoothest transition possible.

This is the most direct path if you need to migrate on a timeline and are looking for an immediate, production-ready replacement.

The HAProxy Ingress Controller was developed as a major alternative to the NGINX Ingress Controller. Over time, its annotation system has been built out to provide equivalent functionality for the most critical, high-usage features that most users rely on:

• nginx.ingress.kubernetes.io/load-balance -> haproxy.org/load-balance

• nginx.ingress.kubernetes.io/backend-protocol -> haproxy.org/backend-protocol

• nginx.ingress.kubernetes.io/proxy-connect-timeout -> haproxy.org/proxy-connect-timeout

• nginx.ingress.kubernetes.io/cors-allow-origin -> haproxy.org/cors-allow-origin

• nginx.ingress.kubernetes.io/affinity -> haproxy.org/affinity

• ...and so on for things like rate limiting, timeouts, and cookies.

It's not a 100% drop-in replacement because it intentionally handles complex/unsafe things (like snippets) differently. Most of the time, you can find/replace the annotation prefixes.

We are committed to being transparent about where configurations differ and will provide clear, documented alternatives for NGINX-specific features.

Why HAProxy Ingress Controller is an upgrade, not just a replacement

The HAProxy Ingress Controller is built on the same HAProxy core that has been battle-tested for 20+ years, powering many of the world's largest websites. It's not just a replacement; it's a significant upgrade.

• Superior Performance: In our public, reproducible benchmarks, the HAProxy Ingress Controller consistently handles more than double the request throughput of Ingress NGINX while consuming significantly less CPU.

• Advanced Load Balancing: This is our core strength. You get immediate access to more sophisticated algorithms like "least connections" and "source IP hash," giving you far more precise control over your traffic distribution.

• Better Observability: Get a richer set of native Prometheus metrics out-of-the-box, without needing extra sidecars or exporters.

• Zero-Downtime Reloads: HAProxy is famous for its ability to apply configuration changes with zero dropped connections - a critical operational win.

• Robust Protocol Support: It offers first-class, reliable support for Layer 4 load balancing (e.g., for database connections, gRPC, or real-time streaming) in addition to its powerful Layer 7 (HTTP/S) capabilities.

This is all available as a free, open-source project with everything you need to make the switch.

Enterprise power when you need it

Future proof: the HAProxy Unified Gateway

The Kubernetes community’s official long-term recommendation is to move toward the new Gateway API. We are all-in on this transition.

This week, we announced the beta of the HAProxy Unified Gateway. This is our next-generation controller, built from the ground up to provide a single, unified way to manage both Kubernetes Gateway API (available now) and Ingress resources (available in 2026). With support for both resource types, users will be able to:

1. Adopt HAProxy Unified Gateway.

2. Use it in "Ingress mode" for an easy migration from Ingress Controller.

3. Enable Gateway API resources on that same controller, migrating from Ingress to Gateway API resources at their own pace.

This is the best part: making the change to the HAProxy Kubernetes Ingress Controller now sets you up for future success.

It's simple to migrate from HAProxy Kubernetes Ingress Controller to HAProxy Unified Gateway because they share the same core HAProxy technology and an identical configuration philosophy. By migrating to the HAProxy Ingress Controller today, you solve your immediate Ingress NGINX problem with a superior controller and place your team on the clearest, most proven path to the future of Kubernetes networking.

Frequently asked questions (FAQs)

The clock is ticking on Ingress NGINX. Waiting until the 2026 deadline means risking security debt and competing for support during the global scramble.

Avoid the bottleneck. Choose your path below to secure your infrastructure today:

• Launch the Ingress NGINX migration assistant

  • Best for: Getting an immediate, step-by-step technical transition plan from Ingress NGINX to HAProxy Kubernetes Ingress Controller.

• Book a strategy session with an expert

  • Best for: Validating complex architectures and planning a zero-downtime switch.

The continuous shift toward containerization means businesses are migrating more complex, mission-critical workloads to Kubernetes. This trend necessitates traffic management solutions that support diverse protocols (such as TCP, UDP, HTTP, and gRPC) and sophisticated organizational architectures, while delivering exceptional performance and efficiency.

To address these modern cloud-native requirements, HAProxy Technologies today announced the public beta of the new HAProxy Unified Gateway for Kubernetes at KubeCon + CloudNativeCon North America 2025, where the company is a Diamond sponsor. HAProxy Unified Gateway is a free, open-source product dedicated to providing unified, high-performance, Kubernetes-native application routing for both Gateway API and Ingress – with a powerful enterprise implementation coming in 2026, integrated directly into the groundbreaking HAProxy Fusion Control Plane.

HAProxy Unified Gateway provides flexible protocol support, role-based access control, and a low-risk, gradual migration path for organizations moving from Ingress to Gateway API. Combined with HAProxy’s legendary performance and reliability, these key features support the needs of modern applications and evolving organizations.

Built on HAProxy’s 20+ years of open-source innovation, HAProxy Unified Gateway is designed to be the most dependable and scalable solution for cloud-native application delivery within the Kubernetes community.

Quick start

You can get the Docker image for HAProxy Unified Gateway’s beta release on Docker Hub, and contribute to the community project on GitHub.

In the GitHub project, you can find an example of how to deploy HAProxy Unified Gateway as well as examples of how to use various features. 

If you want to learn how to set up HAProxy Unified Gateway with a GatewayClass, a new Gateway, and an HTTPRoute, you can see a step-by-step example with configuration in this article.

Why Kubernetes users need more than Ingress

For years, the Kubernetes Ingress standard has served a foundational role, but it is fundamentally unsuited to the demands of today’s complex, high-scale environments. The core limitations of Ingress controllers include:

• Protocol constraints: Ingress typically lacks flexible protocol support, often restricting traffic to HTTP/S unless you use a workaround like vendor-specific ConfigMaps or port mapping. This inflexibility limits the types of applications – such as those relying on TCP or UDP – that can be easily migrated and managed behind a standard Ingress controller, slowing innovation and modernization.

• Operational risk: The standard uses a single Ingress object for all configuration. This lack of “separation of concerns” or robust role-based access control (RBAC) forces organizations to either create operational bottlenecks by restricting management to one team or risk errors and conflicts by allowing multiple teams to modify the same resource. This design limits scalability and undermines the core Platform Engineering goal of enabling teams to operate safely with autonomy.

HAProxy Unified Gateway is engineered to leverage the modern Gateway API standard immediately, and relieve pressure on organizations with substantial Ingress deployments by providing unified support for both Ingress and Gateway API.

Simple adoption of the latest Kubernetes Gateway API standard

The core use case of HAProxy Unified Gateway lies in its support for the latest Kubernetes Gateway API, delivering the role-based access, flexibility, and portability required for cloud-native ecosystems.

HAProxy Unified Gateway launches with crucial support for TCP and HTTP/S (including TLS termination) via its Gateway API implementation, a level of flexible protocol support that was challenging under the old Ingress standard. With future releases, we plan to make HAProxy Unified Gateway progressively conformant with the Gateway API specification, which includes supporting GRPCRoute and  more. This flexibility empowers the community to quickly onboard a wider variety of application workloads, including legacy or specialized Layer 4 (L4) applications, which will accelerate modernization initiatives.

Additionally, the upcoming enterprise implementation via HAProxy Fusion and HAProxy Enterprise will support UDP for applications that prioritize real-time communication.

Role-based access control

The Gateway API’s role-oriented design is another significant benefit, resolving the complexity of the Ingress standard. HAProxy Unified Gateway implements RBAC through the Gateway API, which enables a clear separation of concerns among Cluster Operators, Infrastructure Providers, and Application Developers.

This design allows teams to safely share network infrastructure without direct coordination, centralizing control over the underlying Gateway while distributing flexibility to application teams to manage their own routing rules. This directly reduces operational complexity and lowers the risk of configuration errors and conflicts.

Low-risk migration from Ingress to Gateway API

HAProxy Unified Gateway is designed to solve the difficult choice faced by organizations migrating from Ingress to Gateway API (the "massive cut-over" versus the complex "gradual migration"). Our roadmap includes the future integration of both Ingress and Gateway API standards in a single HAProxy Unified Gateway instance (coming in 2026). This unification will provide a low-risk, gradual migration path with consistent management and centralized observability, eliminating the need to manage separate products from different vendors.

Unrivaled performance and efficiency

HAProxy Unified Gateway is built on the proven HAProxy core, widely recognized as the world’s fastest software load balancer. This foundation ensures HAProxy Unified Gateway brings industry-leading throughput, latency, and resource efficiency to Kubernetes traffic management using the Gateway API.

Performance as a cost lever

Low performance and efficiency significantly increase the cost of scalability in cloud-native deployments. An inefficient Gateway – like any inefficient component – directly increases resource consumption and, therefore, cloud costs. 

However, the indirect consequences for the resilience of a Kubernetes cluster are perhaps even greater. A poorly performing Gateway, requiring more instances, results in more calls to the Kubernetes API, which can lead to synchronization problems and bring down an entire cluster – something to be avoided at all costs.

HAProxy Unified Gateway is cost-effective and resilient, delivering the exceptional performance and efficiency HAProxy is known for. The HAProxy core is proven to scale well, reaching over 2 million HTTPS requests per second on a single AWS Graviton2 instance. HAProxy is used by some of the world’s largest platforms to handle hundreds of billions of requests a day with low latency. 

How is this possible? HAProxy uses a high-performance event-driven architecture; advanced multi-threading with thread groups and automatic CPU binding; and a task scheduler that balances high throughput with low latency. These core architectural choices translate directly into resource savings, enabling users to handle large-scale traffic with fewer (and smaller) machines.

This fundamental performance ensures HAProxy Unified Gateway can manage bigger and more demanding Kubernetes applications while reducing the total cost of ownership for cloud infrastructure.

Operational simplicity and reliability

HAProxy Unified Gateway is engineered to make Kubernetes networking simple and reliable, leveraging more than two decades of open-source expertise.

Streamlined deployment

To simplify implementation and management, HAProxy Unified Gateway deploys efficiently in a single Application Stack. This design minimizes the number of moving parts and reduces points of failure compared with products requiring multi-pod deployments.

Battle-tested reliability

HAProxy Unified Gateway’s reliability is underwritten by the HAProxy open-source core, which has been in continuous development and production use for 20+ years. The core is known for being extremely robust, built with extensive internal checks that prevent service outages and other failures. This foundation of reliability, trusted by the world’s leading platforms and public sector organizations, ensures dependability for the most critical traffic management needs.

HAProxy Unified Gateway is and always will remain a free, open-source product dedicated to the Kubernetes community and the adoption of the Gateway API standard. We encourage contribution and participation through our community channels.

For organizations whose requirements extend beyond a single Kubernetes cluster – such as global governance, multiple gateway classes and multi-cluster management, or centralized security – HAProxy Unified Gateway provides a seamless evolution path to a powerful enterprise solution.

The enterprise implementation of a unified Ingress/Gateway API capability will be introduced in 2026, integrated in HAProxy One – the world’s fastest application delivery and security platform. HAProxy One consists of HAProxy Enterprise (a flexible data plane), HAProxy Fusion (a scalable control plane), and HAProxy Edge (a secure edge network). 

The enterprise implementation in HAProxy One will provide a natural extension of the open-source product, providing critical centralized capabilities without requiring users to completely rewrite their foundational traffic management layer. By migrating their Gateway API configuration seamlessly from the open-source HAProxy Unified Gateway to HAProxy One, users will gain the following benefits:

1. Universal traffic management: The ability to consolidate cloud-native traffic management (Gateway API and Ingress) with other methods – north-south and east-west – across any environment, including on-premises, multi-cloud, and multiple Kubernetes clusters (supporting Kubernetes federation initiatives).

2. Intelligent multi-layered security: Industry-leading edge security, including DDoS protection, bot management, global rate limiting, and a robust Web Application Firewall (WAF).

3. Centralized control plane: HAProxy Fusion provides centralized management, observability, and automation for all HAProxy Enterprise instances, along with high-performance service discovery, supporting the massive scale of large Kubernetes clusters.

This strategy ensures that the core, high-performance, Kubernetes-standard routing functionality remains free and open-source, while providing an enterprise upgrade path that delivers the platform consolidation and advanced security needed for more complex global deployments.

Example: deploying a Gateway and an HTTPRoute using HAProxy Unified Gateway

It’s simple to get started with HAProxy Unified Gateway. You can easily configure it to route traffic through Kubernetes. In this example, we will:

1. Define a GatewayClass

2. Deploy a Gateway

3. Deploy an HTTPRoute

Step 1: Define a GatewayClass

First, you need to define a GatewayClass that your Gateway resources will use.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: haproxy
spec:
  controllerName: gate.haproxy.org/hug

The GatewayClass is a similar construct to the Ingress class. The GatewayClass needs a name and a controller. The controllerName indicates that this GatewayClass belongs to HAProxy Unified Gateway (abbreviated here to “hug”). Every Gateway that uses this GatewayClass will also belong to the controller. 

Step 2: Deploy a Gateway

After you have deployed the GatewayClass, you need to deploy a Gateway.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: hug-gateway
spec:
  gatewayClassName: haproxy
  listeners:
  - name: http
    port: 31080
    protocol: HTTP
    allowedRoutes:
      kinds:
      - group: gateway.networking.k8s.io
        kind: HTTPRoute
    hostname: "*.haproxy.local"

The Gateway needs a name, it needs to be connected to our gatewayClassName, and it needs to contain at least one listener. In HAProxy terms, a listener is a Frontend that defines the port to listen to and the type of traffic it accepts.

Step 3: Deploy an HTTPRoute

After you have deployed the Gateway, you can deploy the HTTPRoute.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: route-hello-world-exact
spec:
  parentRefs:
  - name: hug-gateway
    sectionName: http
  hostnames:
  - "exact.haproxy.local"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: hello-world
      port: 8888

The HTTPRoute needs a name, a Gateway, and routing rules. You can use parentRefs to show that this particular HTTPRoute is connected to our Gateway. Each rule also needs to specify at least one service to which this route will point traffic. 

After you have deployed the HTTPRoute, you can safely check if the service is reachable through the controller.

Try HAProxy Unified Gateway today and share feedback on the beta release

The beta release of HAProxy Unified Gateway marks a pivotal moment in cloud-native traffic management. By adopting the Kubernetes Gateway API standard, HAProxy Unified Gateway eliminates the complexity and limitations of legacy Ingress resources while leveraging HAProxy’s legendary performance and two decades of experience.

HAProxy Unified Gateway delivers unified, high-performance, Kubernetes-native application routing backed by an incredible open-source community and provides a low-risk pathway toward modernizing Kubernetes networking.

The HAProxy Unified Gateway beta is now available for download on Docker Hub. We encourage the community to try the beta, explore the documentation, and actively contribute to the project to help shape the final v1.0 release (and beyond).

With this release, we’re introducing HTTPS health checks to Global Server Load Balancing (GSLB), new partitioning for larger firmware updates, enhanced web application firewall (WAF) functionality, and our new Threat Detection Engine (TDE). These features bring HAProxy ALOHA and HAProxy Enterprise closer together, expand scalability for future upgrades, and provide stronger protections for modern applications.

New to HAProxy ALOHA?

HAProxy ALOHA provides high-performance load balancing for TCP, UDP, QUIC, and HTTP-based applications; SSL/TLS processing; PacketShield DDoS protection; bot management; and a next-generation WAF.

HAProxy ALOHA combines the performance, reliability, and flexibility of our open-source core (HAProxy — the most widely used software load balancer) with a convenient hardware or virtual appliance, an intuitive GUI, and world-class support.

HAProxy ALOHA benefits from next-generation security layers powered by threat intelligence from HAProxy Edge and enhanced by machine learning.

What’s new

HAProxy ALOHA 17.5 includes exclusive new features — plus many core features from HAProxy 3.2 (community version) and HAProxy Enterprise 3.2. You can see what's new in our HAProxy 3.2 and HAProxy Enterprise 3.2 announcements. 

Key highlights unique to HAProxy ALOHA 17.5 include:

• Global Server Load Balancing (GSLB) enhanced with HTTPS health checks – Customers can now offload health checks, secured via SSL/TLS, to HAProxy ALOHA. Easily view and maintain server health across thousands of remote DNS zones by monitoring for health check responses, unexpected error codes, and server recovery updates. 

• New partitioning for firmware updates – HAProxy ALOHA users can now install much larger firmware files up to 1GB in size. This paves the way for future HAProxy ALOHA modules, database integrations, and general feature enhancements.

For a complete list of HAProxy ALOHA 17.5 feature updates and enhancements, see our release notes.

New features incorporated from HAProxy Enterprise

Additionally, HAProxy ALOHA 17.5 adds the following features and enhancements from HAProxy 3.2 and HAProxy Enterprise 3.2: 

• New Threat Detection Engine (TDE) – Integrated with the HAProxy Enterprise Bot Management Module, TDE provides sophisticated detection, classification, and industry-standard labeling of application DDoS, brute force, web scraper, and vulnerability scanner threats without compromising performance or customer privacy. 

• Custom WAF Profiles – Customers can now create, customize, and apply a unique WAF ruleset for each WAF Profile, applying them selectively across different applications or locations. 

• New AWS-LC integration – The AWS-LC library replaces OpenSSL and provides the best available performance at any scale, especially on modern multi-core systems, with robust QUIC support.

Ready to upgrade?

To start the upgrade process, visit the installation instructions for HAProxy ALOHA 17.5.

Secure GSLB health checks deliver deeper observability

Two supplemental monitoring plugins offered some useful workarounds, but were less resilient than desired and required administrators to set up child processes across numerous DNS zones. These active processes could be resource intensive under certain conditions. We wanted to maximize GSLB reliability, scalability, performance, and simplicity for these complex deployments without needing workarounds. Our goal was to give GSLB users deeper observability everywhere on par with HAProxy Enterprise's functionality. 

HAProxy ALOHA 17.5 introduces encrypted and performant GSLB health checks for distributed infrastructure. Customers can enable secure GSLB health checks over TCP/HTTP using the new ssl keyword parameter that users add to their existing http-check directive. This piece of the configuration is very simple and offers a seamless UX, provided HAProxy ALOHA also has GSLB configured across relevant DNS zones. 

The GSLB code itself remains largely unchanged. Users just need to permit HAProxy to accept the clear health check from the GSLB server before triggering the HTTPS portion of the health check. 

This upgrade directly mitigates risk associated with potentially unsecured connections between a GSLB server (often running in a public cloud) and private, on-premises data centers.

• It's highly resilient

• It's transparent from the client's perspective 

• Encryption is neither enforced nor skipped on the client side, itself

• DNS zone names remain readable 

Overall, the mechanisms driving this latest update to GSLB should feel familiar to existing HAProxy ALOHA users. HTTPS health checks offer greater control over your security posture without revealing too much of your monitoring logic to potential bad actors. Your GSLB server(s) will concurrently run HAProxy alongside the DNS daemon to support these functions. DNS queries are handled over UDP/TCP with the GSLB daemon to obtain the IP address of the closest reachable datacenter.

Improved firmware update partitioning

Firmware updates have long been a staple of HAProxy ALOHA, enabling new features and boosting lower-level optimization across hardware appliances. While useful, file management within HAProxy ALOHA has been somewhat limited — with individual file uploads capped at 32MB. We wanted more flexibility to enhance future versions of HAProxy ALOHA while empowering users to implement new infrastructure components. 

HAProxy ALOHA 17.5 now allows users to install and run individual firmware files up to 1GB in size. This filesystem change also enables users to readily upload their data-hapee bot management rules and MaxMind integrations — delivering geolocation-supported fraud detection, traffic analysis, geo-targeting, improved compliance, and more. This opens the door for continual HAProxy Enterprise module integrations and helps bridge the gap between both products. 

This native file support greatly simplifies firmware handling for HAProxy ALOHA users. The SCP protocol is no longer required to transfer files smaller than 64MB, and external tools are no longer needed to access /tmp or /app folders on the system. However, this file manager behavior depends on the size of its internal buffers, which we've increased for this release. 

Users can manage everything with much less friction than in previous versions. This setup offers improved transparency by simplifying file management natively.

Upgrade to HAProxy ALOHA 17.5

When you are ready to upgrade to HAProxy ALOHA 17.5, follow the links below:

Conclusion

HAProxy ALOHA 17.5 further enhances the performance and security of HAProxy ALOHA, while paving the way for additional improvements and features. This latest release is also an important step towards greater feature parity with HAProxy Enterprise — unlocking deeper support for HAProxy Enterprise modules both now and in the future.

Interested in learning more about HAProxy ALOHA and taking it for a test drive? Request a quote or free trial today.