The Whole Surface, Side by Side

PQ Crypta Proxy 0.2.2 against the field — 228 features

CRS in the rule-count row means the proxy ships no rules of its own and relies on the OWASP Core Rule Set through ModSecurity or Coraza. vendor means a proprietary rule set supplied under licence. PQ Crypta's 256 rules are counted from the PQW-* identifiers in src/waf.rs: 58 bot, 54 scanner-probe, 18 SQLi, 18 XSS, 16 SSRF, 16 traversal, 15 command injection, 12 deserialization, 9 SSTI, 8 anomaly, 7 JNDI, 6 LFI, 6 NoSQLi, 5 XXE, 3 CRLF, 3 prototype pollution, 2 GraphQL.

Where We Stand Alone

55 of the 228 rows are ones where PQ Crypta has a native implementation and no other proxy in the field has even a partial one. They cluster, and the clusters say something about what the product is for.

Where They Beat Us

A chart that only shows wins is an advertisement. These are the places another proxy is the better tool. Most are scope differences rather than deficiencies — PQ Crypta is a security-focused edge terminator, not a web server, a service mesh or an orchestrated ingress — but a scope difference still means you should pick the other one, so each is stated with what this proxy does instead.

Who Should Pick What

Ten deployments, each with the proxy that fits it best and the one to reach for second. The runner-up column is the useful half: it says what you actually give up by taking it, which is usually the thing that decides an evaluation.

PQ Crypta is runner-up in most of the rows it does not win, and that is not courtesy — on the matrix it leads load balancing 68–60 on points and TLS 44–30, so on features it is the closest alternative even where another proxy is the right call. Where it is not the runner-up, the reason is specific and shows up in the matrix as one of the six rows it does not lead: FastCGI and uwsgi backends, dynamic service discovery, plugin and scripting extension, generic L4 stream proxying, gRPC-specific features, and on-demand TLS. Plus the two things a feature chart cannot hold — raw throughput, and the years behind a project.

How Our Column Is Validated

The rule is that a description of the software is not evidence of it. Every entry is established from an implementation in src/, from the configuration the production process is actually running, or from a probe against the live endpoint — and each one is listed below with the check that establishes it, so the column can be audited rather than taken on trust.

Capabilities the Config Never Surfaces

A configuration file is a poor inventory of what software does. Reading only config.rs — 434 settings across 37 structures — misses a whole class of behaviour that has no knob because it is not optional. Those entries come from reading the modules instead, and several are among the strongest in the chart.

Benchmarked Against HAProxy

Throughput is measured head to head, on one machine, rather than asserted. What the harness controls for comes before the results, because a benchmark that publishes only its numbers is asking to be taken on trust — and each control below exists because its absence produces a confident wrong answer that looks exactly like a right one.

What the harness controls for

All three of these are invisible in the results themselves. They are caught by sampling the proxy, the backend and the generator in the same tick and reading them together; any one alone is consistent with the rig being fine.

The backend must not be the ceiling. This machine has twelve logical CPUs and six physical cores — SMT siblings are paired, so a range like “cores 0–1” is one core, not two. A backend given one core saturates it and becomes the thing being measured: pinned that way, nginx tops out at 138,508 req/s with no proxy in the path at all, which is a figure HAProxy can reach. The backend now gets two physical cores and four workers, and bench-backend.sh measures its ceiling before every run so the proxies' numbers can be read against it.

Both proxies must actually be on the cores they were given. taskset sets a mask a process is free to overwrite, and HAProxy does: cpu-map re-pins its threads after start. If that line and the harness disagree, one proxy silently gets more cores than the other inside a benchmark whose entire output is a ratio — and the only symptom is a process reading above its own CPU budget. Every thread's Cpus_allowed_list is asserted after each proxy starts, and a mismatch aborts the run.

The generator must not be the ceiling either. h2load defaults to one thread, and a single core cannot drive a proxy at this rate — pinned that way it saturates at 99 % while the server under test sits at 248 % of the 400 % available, and the cell measures the client. It runs 6 threads across 3 physical cores, and its CPU is reported alongside the server's for every published cell.

All three failures push the same way: a clipped backend, a clipped generator and an under-pinned opponent each understate whichever proxy is faster. On this rig that is not us, so every one of them would flatter these results. That is the reason they are controlled for rather than assumed away.

The rig

6 physical cores of an AMD EPYC-Milan Processor, split so that the only saturated component is the one being measured: the backend gets 2 physical cores (nginx/1.28.3 (Ubuntu), serving three fixed bodies from memory), the proxy under test gets 1 physical core and 2 workers, and h2load gets 3 physical cores. Both proxies run as many workers as they have CPUs because HAProxy warns that oversubscribing threads to CPUs degrades it severely, and benchmarking a product in a configuration it warns about is not a comparison. One tool drives HTTP/1.1, HTTP/2 and HTTP/3 (h2load nghttp2/1.68.0, built from source against ngtcp2 and nghttp3), so the three protocols are comparable to each other rather than to three different clients. HAProxy 3.2.9 with QUIC on OpenSSL 3.5.5; same certificate, same backend, same TLS 1.3-only policy on both sides. The configurations as run are published with the data: HAProxy’s, ours and the backend’s.

Sampled every two seconds through every measurement, the only saturated component is the one being measured. HAProxy runs at a median 200 % of its 200 % and PQ Crypta at 199–200 %; the backend sits at a median of at most 116 % of its 400 % and the generator peaks at 183 % of its 600 %. Both are reported alongside every result rather than assumed. The backend's own ceiling, measured with nothing in front of it:

Results

HAProxy’s throughput over ours is 1.23× on HTTP/1.1, 1.38× on HTTP/2 and 1.18× on HTTP/3, as geometric means over the six cells of each protocol, with our proxy configured to do what HAProxy’s configuration does and no more. Above 1× HAProxy is faster; below it, we are.

As deployed, it is 2.71× on HTTP/1.1, 3.10× on HTTP/2 and 1.70× on HTTP/3: the same run, a third arm, our proxy with everything the production nodes run that one backend can exercise — the WAF in block mode, TLS-layer fingerprinting, both rate limiters, the security headers, compression, the optional features and post-quantum key exchange (its configuration). HAProxy does none of that here, so the distance between our two rows is what those features cost against a proxy doing none of them; the sections below take them one at a time.

Our arm (pqc-bench-lean.toml) is the plumbing configuration plus the four things HAProxy’s own configuration does not do: no added response headers, no Alt-Svc on TCP, the backend’s Server header passed through, no compression. A feature that is off leaves the request path entirely rather than standing aside in it. Its responses are the same size as HAProxy’s to the byte — 229 bytes of headers over HTTP/1.1 and 225 over HTTP/2 on the 1,024-byte body the run checks before it starts. Same TLS 1.3 policy, the same 2 CPUs and 2 workers each. The key exchange, as the generator reported it for every run: HTTP/1.1, X25519 for HAProxy against prime256v1 for ours; HTTP/2, X25519 for HAProxy against prime256v1 for ours; HTTP/3, X25519 for HAProxy against prime256v1 for ours. All classical — the generator’s TLS library offers no ML-KEM group — and paid once per connection, which these runs hold open throughout.

At 64 KB the gap is 1.00–1.09× on HTTP/1.1, 0.99–1.00× on HTTP/2 and 0.97–1.13× on HTTP/3. Ours has the higher median in 5 of 18 cells, most clearly on HTTP/3 at 64 KB and a hundred connections, where a random run of ours beats a random run of HAProxy’s in 97 % of pairings. At empty and 1 KB bodies the gap is 1.28–1.45× on HTTP/1.1, 1.53–1.81× on HTTP/2 and 0.92–1.61× on HTTP/3: fixed per-request cost shows most where each request carries least. The architectural advantage behind that is real rather than a tuning gap — HAProxy carries no framework state per request.

The distance is widest on HTTP/2: 1.38× over its cells, and 1.81× on HTTP/2 at 1 KB and a hundred connections. That is where the next work is.

Each figure is the median of 6 measurements of 60 seconds after a 15-second warm-up. “A run of ours is faster” is the share of pairings, one run of ours against one of HAProxy’s in the same cell, in which ours served more requests per second. HTTP/1.1 runs one request per connection at a time, HTTP/2 and HTTP/3 ten streams per connection. Both proxies get 1 physical core and 2 workers, so the absolute figures are a function of that budget; the ratios are what the page is about. Every row is in the published run, with the measurement windows and the CPU samples the figures above are computed from.

Why sixty seconds. Measured rather than asserted: the same cell (HTTP/1.1 at 64 KB and 10 connections), 6 runs of each proxy at each window, alternating. After a 2-second warm-up, 10-second runs of ours vary with a coefficient of variation of 8.2 % against 4.9 % at 60 seconds after 15 (HAProxy’s: 2.4 % and 0.9 %), and the short window reads our proxy 3.4 % higher than the long one while moving HAProxy 1.7 %. The runs are published.

How the run was controlled. The arms were interleaved within every cell, with the order rotated on each repetition so that every arm spent one repetition in each position: a null test on this rig once measured the second slot 3.7 % slower than the first, which is larger than some of the differences reported here, and rotation cancels it — median throughput by position came out at 0.996–1.003. Each proxy ran at a median 199–200 % of its 200 % CPU while the generator peaked at 183 % of 600 % and the backend at 116 % of 400 %, so the only saturated component was the one being measured. The backend was measured on its own beforehand and tops out at 96,000–361,000 req/s depending on the cell — in every cell at least 2.35× the rate the faster proxy reached with the same body and connection count. No request failed; the generator’s 2xx and completed counters differ by up to 0.04 % on any run, which is its accounting of the streams in flight when the window closes rather than an error from either proxy.

Which build. Proxy commit 6d75ab9, binary fa8556d2a7508f05, measured 25 September 2026. The build serving this page is 5ec548c75203d03a. Its changes since, outside the conformance suite and the tools:

• 30f819a TCP listeners rebuild their rustls configs, ECH included, after every TLS reload
• a6369f3 waf.programmatic_client_paths: the path form of allow_programmatic_clients
• 1a6d5a8 Routes can admit scripts without admitting scanners: allow_programmatic_clients
• a4a1794 Data files reload in place: the weekly refresh no longer restarts the proxy
• 6f31427 OpenSSL 4.0 accepted as native ML-KEM; --validate runs the security checks
• c562485 Hot reload rebuilds the OpenSSL listener's TLS contexts
• da34358 Post-quantum ECH (X-Wing, ML-KEM) and curveSM2MLKEM768
• b4020a2 JA4 as the FoxIO spec defines it: SNI and ALPN out of part c
• 50eb31e Dependencies forward: quinn-proto 0.11.19, redis 1.7 with rediss://, notify 8, axum-server 0.8
• 6477091 Formatting: tls.rs test imports in rustfmt order
• 5daa632 ML-DSA-87 certificate signing in FIPS builds too
• 649d332 Tests: PqdsaKeyPair::to_pkcs8v1 (aws-lc-rs 1.18 deprecates to_pkcs8)
• 459557e ML-DSA signing from aws-lc-rs's stable signature module
• b5a8420 Response headers: one policy for every transport; a route's own headers stand
• 9ff1915 Hot reload applies to everything it can, and names what it cannot
• 7456fc5 QUIC endings ranked once for both servers; a TCP-only host over HTTP/3 gets 421
• 6cfdd45 Every listener routes on one canonical path
• fba9e2e A redirect keeps the rest of a mixed-case path
• 7ee0295 Nonces are built from their source, never from a zeroed buffer
• bfb8f53 WebTransport: forward the request's api_key as X-API-Key
• fbed24c [pqc] experimental_groups: provider KEMs offered between ML-KEM and classical
• ee24321 tls: pure ML-KEM-1024 leads the level-5 tuple, as the CNSA 2.0 TLS profile requires
• fdcd878 tls: ECH over TCP -- ClientHellos naming this server's ECH config go to rustls
• 7a2b020 tls: an ML-DSA-87 companion certificate per domain, for clients that accept only ML-DSA
• 96dcc68 tls: post-quantum before classical whatever the client lists first; ML-KEM-1024 preferred
• 7ba5cf8 Crawlers: verified by their operators' published ranges; the edge bans spare them
• 7769bab WAF: SQLI-005 matches stacked statements, not keyword prefixes; blocks say where they matched
• 4d5435c Connection rate counts connections, not requests; Rust 1.99 clippy
• 2daca29 Backend pool: an idempotent request on a connection closed unanswered goes again
• b0e4e6b Credentialed programmatic clients pass the generic-client UA rules on routes that allow them
• b09497b x-health-check-bypass is proxy-only; clean peer closes are not errors
• 46ce2b6 SECURITY: proxy-only headers stripped from clients; bypass header no longer skips UA rules; WAF explain
• 27139fc fuzz: one mutation fuzzer for every parser of raw client bytes, replayable by seed
• 310fb2e SECURITY fingerprint: an odd cipher-suite length no longer aborts the proxy; ClientHello parser fuzzed
• a9949b0 SECURITY fingerprint: JA4 ALPN field per spec; a crafted ALPN value no longer aborts the proxy
• 296433e waf: PQW-JNDI-007 requires OGNL syntax; no rule may match random base64
• 9ddd89f shutdown: live connections finish and close, the WebTransport server is told, and a signal during startup is held
• a8f5cfb deps: jsonwebtoken 11, OpenTelemetry 0.33, tower-http 0.7, webpki-roots 1.0, reqwest 0.13; HTTP/3 and WebTransport now actually join the caller's trace
• 783ddcc webtransport: a session no longer holds the origin map's lock; the whole proxy could be stopped by five connections
• 3f05e53 tls: 0-RTT on every TCP listener, served before the handshake completes

What else ran. 11 events on the rig host during this run overlapped a measured cell; each is in the run’s disturbances file with the cells it touched. Every cell here is the median of its repeats, so one disturbed repeat moves it only if it is the middle value.

HTTP/3 with one request in flight

Throughput at high concurrency is the easy case. The demanding one is a single request at a time down each connection — one in-flight stream, which is what a browser fetching a single resource actually looks like, and where any per-request latency shows up as a throughput number rather than hiding behind pipelining.

What governs it is when the acknowledgement leaves. A client will not start its next request on a connection until the previous one has been acknowledged, so an acknowledgement that waits is a request that waits. We acknowledge a request in the response that answers it: an owed ACK rides on the next packet the connection sends for any other reason (server.ack_piggyback, on by default), and server.ack_eliciting_threshold — default 1, RFC 9000’s “every other packet” — decides only when an acknowledgement is worth a packet of its own.

Each alternative has a cost that shows at one stream. Same binary, one setting changed per arm, the arms interleaved and rotated, on the second machine (1 KB body, ten connections, one stream each; build 93256d064498e33d, 24 September 2026):

Without piggybacking the first row is a timer, not a distribution: its repetitions agree to three significant figures. Acknowledging every packet at once removes the wait but spends a datagram on it; at a hundred connections of ten streams that is 0.05 more received and 0.05 more sent per request (0.61 against 0.55), because at that load most acknowledgements have a response to ride on anyway. Two things this is not. It is not the ACK-frequency extension, which governs what we ask the peer to do and cannot affect our own acknowledgements. And it is not stream credit: ten times the advertised stream limit moves this cell’s median by -4.1 %, inside the spread of its own repetitions (71 %). The runs and the configurations are published.

What an HTTP/3 request costs, and where

Measured the way optimisation work on this proxy is measured — instructions retired per request, which is stable to a fraction of a per cent where throughput is not — with HAProxy 3.2 on the same second machine as the reference: an empty body at a hundred connections of ten streams costs us about 107,000 instructions per request against HAProxy’s 89,000 (runs). Four mechanisms decide most of that:

The two rewrites cannot be measured as “the current code without them” — there is no faithful way to put the old code back into today’s — so they carry the figure measured when each was made, beside what that path costs today, from an instruction profile of the deployed commit (701e003) built with symbols (shares). The packet counts are the clearest picture of what separates the two proxies now. Per request, at a hundred connections, HAProxy’s event loop and its clients exchange about 0.31 datagrams; we exchange about 0.55, and 2.42 without coalescing (runs). Beyond that the cost is spread thin: the largest single function in an HTTP/3 request is quic_listener::QuicListener::handle_h3_request at 5.6 % of its instructions.

Consistency, and how precise any of this is

We are markedly less repeatable than HAProxy. Spread within a single unchanged cell (fastest of the 6 measurements over slowest) is a median of 5.6 % for HAProxy, 17.2 % at worst, against 15.0 % for us, 41.1 % at worst. It is not a pattern of degradation: throughput does not decay under sustained load on either side.

The cause is not the proxy doing more work. Sampling per second under load (HTTP/2, 1 KB bodies, 10 connections of 10 streams), throughput sits in a slow mode near 129,000 packets/s or a fast one near 187,000, holding one for as long as 100 seconds at a stretch. Across the two modes the CPU is saturated either way, cycles per second are no lower in the slow mode (7.57 against 7.15 billion), and instructions retired per packet are flat to 0.04 % — 43,539 against 43,520. The code executes the same work; the processor retires it 1.54× more slowly, instructions per cycle falling from 1.14 to 0.74.

Four explanations were tested and rejected. CPU steal on the proxy’s CPUs is exactly zero in every one of 100 seconds while throughput moved between 121,000 and 223,000 packets/s, so the hypervisor is not taking cycles. dTLB misses run at 2.0 per packet in the slow mode against 1.7 in the fast, beside some 59,000 cycles per packet: too few to matter whatever each one costs, so it is not huge pages. Frequency scaling cannot be it while cycles per second are no lower in the slow mode. Moving the two workers off shared SMT siblings (CPUs 4-5) onto separate physical cores (4,6) raised throughput 5 % (43,000 against 40,900 req/s) and widened the scatter rather than narrowing it (a coefficient of variation of 14.5 % against 10.7 %). The one counter that moves with the mode is cache misses: 804 per packet in the slow mode against 676 in the fast, 19 % more for the same instructions. The code does the same work and finds less of it in cache; what else is using the cache is not visible from inside this machine, which is a virtual one. The probes are published per second, with steal and the two layouts, measured 25 September 2026 on build 93256d064498e33d.

The work is stable even where the rate is not, so development measures the work. Instructions retired per request, counted over the generator’s own measurement window, has a coefficient of variation of 0.77 % against req/s at 17.4 % over the same 6 runs. For a 1 % change in the code to stand two standard errors clear, an A/B needs 5 rounds by instructions — about 9 minutes — and 2,425 by throughput. Throughput is what this page publishes, because throughput is what an operator gets, but it is a poor instrument for deciding whether a change made the code cheaper. benchmarks/instr-ab.sh in the source tree is the one used for that, and the runs are published.

How precise are the numbers above? Less than a table of five-digit figures suggests. That scatter is the floor on what any single cell of ours can resolve, which is why every cell is a median of 6 interleaved measurements and the gap is quoted as a geometric mean over each protocol’s cells rather than from any one of them. Treat a movement smaller than 15 % in any single figure of ours on this page as the harness rather than the software, and one as large as 41 % as possible in the worst cell.

Where the allocations are not

What closes the distance is where the allocations are not, and each decision behind that is held to an interleaved A/B of two of our own binaries under an identical generator, where a shared ceiling cancels: four hot structures passed as reference-count bumps rather than copies, route regexes compiled once at startup rather than per request per route, a direct request dispatch, and the allocator.

When they were made, the last two carried more than the rest combined, and for the same reason. The allocator is mimalloc, not glibc’s: on the current build it is worth 1.19× on HTTP/1.1, 1.07× on HTTP/2 and 1.14× on HTTP/3 in throughput against the system allocator, on the second machine, and it was worth 1.74× on the benchmark rig when made (b23bd75, 4 September 2026). glibc locks per arena, and a proxy allocates small buffers constantly then frees them on whichever worker finished the request, the case that design serves worst. Requests dispatch directly rather than through the web framework’s router, which otherwise rebuilds a boxed, heap-allocated routing table on every request for a table with one entry in it: worth 1.35× on HTTP/2 when made (0b5eb48, 4 September 2026); today dispatch’s own code is 2.49 % of an HTTP/2 request’s instructions and the framework router 0.00 %. Dispatch is a TCP path and does not touch HTTP/3; the allocator does.

The pattern is worth naming, because it is the one thing here that generalises. A profiler attributes an allocation’s own instructions to the allocation and everything it really costs — lock contention, cache traffic — somewhere else. So the decisions that remove allocations return far more than their profile share predicts, while putting the shared security state behind a reference count — 3.4 % of the profile, and plainly correct — measured 1.00× when made (6050eb2, 4 September 2026), and cloning it costs 0.00 % of a request today. It stands because it is right, not because it helps.

Each multiplier is what that change is worth against the binary without it, on the machine named. None of them says where the proxy stands against HAProxy — that is the table above. The current-build A/Bs are published, with the variants’ hashes in the manifest.

What the optional features cost

Early hints, priority hints, request coalescing and Server-Timing — the four settings pqc-bench-features.toml turns on over the plumbing configuration — cost 1.14× on HTTP/1.1, 1.13× on HTTP/2 and 1.03× on HTTP/3, as geometric means over each protocol’s six cells: the plumbing arm’s throughput over the features arm’s. They are not HTTP/3-only despite the name of the middleware that implements them, which sits in the TCP chain as well as the QUIC one.

Per cell the cost runs 1.07–1.24× on HTTP/1.1, 0.98–1.37× on HTTP/2 and 0.98–1.10× on HTTP/3. The range for HTTP/1.1 sits entirely above 1.00×, so the effect there is not an artefact of one cell; within one unchanged cell the run’s repetitions spread a median 18.5 % and at worst 76.8 %, which bounds how finely any single figure here resolves. Measured on build fa8556d2a7508f05 (commit 6d75ab9), 25 September 2026, with the two arms interleaved and rotated as in the comparison, 4 measurements of 60 seconds each; no request failed. The rows are published with the run. Also on the rig during it: 2 events, listed below.

What the security stack costs

Both arms run the same binary and the same generator, and both bind 10.99.0.1, a non-loopback address — which is what makes the comparison mean anything, because is_trusted() short-circuits the entire per-request security block for loopback peers. Measured over loopback, the security stack is switched out from under the request and the figure is zero by construction.

On the on arm (its configuration, against the off arm’s) the WAF’s 256 rules run in block mode, TLS-layer JA3/JA4 fingerprinting classifies every connection, replay and drift detection run, and both rate limiters are active. What is lifted is only their power to ban: the thresholds are set far above the offered load, so the figure is the cost of evaluating a request rather than the cost of refusing one. A run that gets itself banned measures the rejection path, which is fast and beside the point. The harness refuses to start unless a plain GET returns 200 on both arms, a SQLi probe returns 403 on the on arm and 200 on the off arm, and a five-second burst at a hundred connections returns no 4xx on either. In this run the probe drew 403 and 200, and the bursts served 104,214 and 143,543 2xx with 0 4xx. Then all 144 measurements behind the table completed with no failed request, and every one’s 2xx count matches its completed count to within 0.03 %.

req/s columns are the 1 KB, ten-connection cell; the cost column is the off arm’s throughput over the on arm’s as a geometric mean over each protocol’s cells, median of 4 interleaved measurements each. No cell is excluded.

The security stack costs 1.36× on HTTP/1.1, 1.39× on HTTP/2 and 1.19× on HTTP/3 for 256 WAF rules in block mode, full JA3/JA4 fingerprinting with replay and drift detection, and two rate limiters: most on HTTP/2, least on HTTP/3. Every protocol’s per-cell range sits clear of 1.00×, so the effect is real on all three transports rather than an artefact of one cell.

Measured on build fa8556d2a7508f05 (commit 6d75ab9), 25 September 2026, the two arms interleaved and rotated as in the comparison, 4 measurements of 60 seconds each. Within one unchanged cell the repetitions spread a median 18.0 % and at worst 49.7 %, which bounds how finely any one figure here resolves. One structural difference beyond the security work itself: TLS-layer fingerprinting needs its own accept loop to see the ClientHello, so enabling it changes which listener serves the connection. The rows are published with the run. Also on the rig during it: 4 events, listed below.

Nagle, and why TCP_NODELAY is on

The proxy sets TCP_NODELAY on every accepted client-facing socket, and the fingerprinting stream wrapper forwards poll_write_vectored and is_write_vectored so a response leaves as a single segment rather than a header segment followed by a body segment. Both matter for the same reason.

Nagle’s algorithm will not put a short segment on the wire while earlier data is unacknowledged. A proxy writes a response and then waits, so when a response ends in a short segment behind a full one, the short one is held. The client has already sent its next request and so has nothing to piggyback an acknowledgement on, and its delayed-ACK timer — 40 ms on Linux — has to expire first.

The setting is server.tcp_nodelay, and it defaults to on. One binary, the knob as an operator would set it (on, off), the arms alternating with the order flipped each round:

With it off, 3 of the 5 loads stall — the server’s CPU falls to 5–14 % because it is sitting on the client’s timer rather than working, and throughput falls by a factor of 17–65. Where the mean latency sits below 40 ms, only some requests wait: at HTTP/1.1, 64 KB, 10 connections × 1 stream, request times with Nagle run from 146 µs to 42.5 ms around a mean of 22.3 ms — the same timer, hit by about 52 % of requests — against a mean of 502 µs without it (both distributions). Where it does not stall, Nagle’s coalescing is worth 1.33× at HTTP/2, 64 KB, 10 connections × 10 streams and 1.21× at HTTP/2, 64 KB, 100 connections × 10 streams. A throughput gain on some saturated multi-stream loads against a stall on HTTP/2, 64 KB, 10 connections × 1 stream, HTTP/1.1, 64 KB, 10 connections × 1 stream and HTTP/2, 1 KB, 10 connections × 10 streams is not a close call for anything interactive, which is why the default is what it is; the setting exists for bulk transfer, where the trade may go the other way.

Measured 26 September 2026 on build fa8556d2a7508f05, 3 rounds of 60 seconds per arm and load; medians. The rows are published. TCP_NODELAY governs every accepted socket whatever else is configured, so none of this is specific to the security path; what varies is the write pattern, and so the body size and stream count at which the exposure shows up.

HTTP/3 has no equivalent exposure. QUIC has no Nagle: the stack decides when a packet leaves, and an ACK it owes rides on the next packet the connection sends for any other reason, as described under “HTTP/3 with one request in flight” above.

What post-quantum key exchange actually costs

The question a reader has is “what does PQC cost me?”, and the honest answer is a measurement. Both proxies here run OpenSSL 3.5.5 — ours with its OpenSSL provider (its configuration, against HAProxy’s) — which carries ML-KEM natively, so this is a head-to-head on the same key exchange rather than one product’s post-quantum against another’s classical. The figure is the mean connect time over 200 concurrent fresh handshakes, one request per connection; the proxies alternate within every repetition with the order rotated, 8 repetitions per group, and the group is read back off a connection before each is measured rather than assumed from the configuration — every one negotiated the group it was offered. secp384r1 is the classical baseline because it is the only classical group our listeners offer; X25519 on its own is not among them.

Adding ML-KEM to the same curve — secp384r1 to SecP384r1MLKEM1024 — costs 1.23× on HAProxy and 1.32× on ours: that is the like-for-like price of the post-quantum half. X25519MLKEM768, the hybrid browsers send, is faster than secp384r1 alone on both (0.74× and 0.62×): its classical half is X25519, which is cheaper than P-384 by more than ML-KEM-768 adds. Against HAProxy, our handshakes are faster on secp384r1 and X25519MLKEM768 and slower on SecP384r1MLKEM1024, most clearly on X25519MLKEM768, where a repetition of ours beats one of HAProxy’s in 73 % of pairings; on secp384r1 and SecP384r1MLKEM1024 the repetitions overlap too much for the medians to say which is faster. The handshake is dominated by cryptography both products get from the same library, which is why the two are close here; the request-throughput gap measured above — 1.23× on HTTP/1.1, 1.38× on HTTP/2 and 1.18× on HTTP/3 — is our own per-request path. Absolute figures are inflated by 200-way concurrency and are only meaningful as ratios.

Measured 25 September 2026 on build 93256d064498e33d. The repetitions are published, with the group each one negotiated.

How Their Columns Are Sourced

Competitor values come from each project's own material: official documentation first, then release notes and vendor engineering blogs, then the issue tracker where a feature's absence is the thing being established. Where a maintainer has stated a position plainly it is quoted rather than inferred — HAProxy's blog says post-quantum signatures are step two and not yet supported; Envoy's post-quantum issue is closed as not planned pending a BoringSSL upgrade; NGINX's ModSecurity WAF reached end of life in March 2024. No competitor cell is set from a benchmark article or a third-party comparison post.

Known Limits of This Comparison

• Breadth is not quality. The scorecard counts whether a capability exists. It says nothing about throughput, latency, memory behaviour, or how a feature holds up under an adversary. On raw performance HAProxy and NGINX have decades of evidence and we have months.
• We grade ourselves. Our column is established from source and a live endpoint, which is a stronger basis than a description — but the person who chose which 228 rows to include is the person who wrote the software. A row that exists partly because we have it is still a row that flatters us.
• Editions blur. Splitting NGINX and HAProxy into free and paid columns is fairer than one column each, but a large operator running Plus or Enterprise sees a different chart than the one an open-source evaluator sees.
• Documentation lags code. A competitor cell marked absent means the project does not document it. Several of these projects move quickly, and QUIC-adjacent features in particular are shipping continuously.
• One operating point. The throughput figures are one machine, one physical core per proxy, two workers each, a loopback path and a static backend. Ratios measured there need not hold at eight cores, across a real network, or against a slow origin. A wrong detail in a rig produces confident wrong numbers, so re-run it rather than trusting it: the harness, its guards and the reasons for each of them are in benchmarks/ in the source tree.
• One snapshot. Everything here reflects PQ Crypta Proxy 0.2.2 as deployed in October 2026, and each competitor at the version named in its column header.

References

1. HAProxy Technologies. How to enable post-quantum cryptography and TLS termination with HAProxy — source for the PQC curve, edition and signature rows.
2. HAProxy. Post-Quantum Cryptography (PQC) Support · Issue #3171.
3. nginx. Support for QUIC and HTTP/3 — source for 0-RTT, QUIC Retry, GSO and the supported SSL libraries.
4. nginx. Module ngx_http_acme_module; Let's Encrypt, Native ACME Support Comes to NGINX.
5. NGINX Community. Post-Quantum Cryptography support in NGINX and Encrypted Client Hello Comes to NGINX.
6. F5. F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life — end of life March 2024.
7. Envoy. BoringSSL upgrade for Post-Quantum Cryptography support · Issue #42893 (closed as not planned) and Support for TLS ECH · Issue #44165.
8. Caddy. Release notes — 2.10 introduced automated ECH and x25519mlkem768; tls directive documentation lists x25519mlkem768 as the only PQC curve.
9. Traefik. Post-Quantum Key Exchange support for HTTPS · Issue #10755; OCSP documentation.
10. LiteSpeed. QUIC and HTTP/3 Support.
11. IETF. draft-ietf-quic-multipath, RFC 9298 (CONNECT-UDP), RFC 9297 (HTTP Datagrams), RFC 9111 (HTTP Caching), RFC 9218 (Extensible Priorities).
12. Certificate compression sources. nginx, ssl_certificate_compression — introduced in 1.29.1, default off; HAProxy Technologies, Announcing HAProxy 3.4 — tune.ssl.certificate-compression, default auto; Envoy, 1.38.0 release notes — brotli added to QUIC and brotli with zlib to TCP TLS; Go, crypto/tls: add support for Certificate Compression (RFC 8879) · Issue #42967 — open, milestone Unplanned, which is the source for the Caddy and Traefik cells; LiteSpeed, SSL Performance.
13. PQ Crypta. pqcrypta-proxy — the source tree every value in our column is read from; proxy documentation, multipath QUIC whitepaper, HTTP/3 conformance suite.