Two datasets, two questions
Dataset 1 — Edge flow (first-party). 15,436 requests through
pqcrypta-proxy (Jun 29–30, 2026), each tagged with its negotiated
protocol token, plus 24 hours of QUIC-listener telemetry: incoming connections,
completed handshakes, ALPN results and accept errors. This answers
“what does traffic to us look like?”
Dataset 2 — Scan corpus (active scan). 563 unique domains probed
with a real QUIC handshake, recording H1/H2/H3 support, QUIC version, TLS version, 0-RTT,
MASQUE, WebTransport, and — critically — the TLS key_share group and
signature algorithm. This answers
“what does the reachable HTTP/3 internet look like?”
Neither is a random sample of the web, and we label which dataset each figure comes from. The value is in watching the same protocols from both ends.
The shape of traffic at a QUIC edge
The most striking result in our logs is the complete absence of HTTP/2 from
observed traffic. It is not disabled — it is offered in ALPN and served by the
TCP stack — it simply drew no requests over this window. The most plausible explanation:
real browsers see Alt-Svc: h3, switch to QUIC and stay there, while
everything else hitting the edge is a bot or crawler on HTTP/1.1. In our environment,
traffic formed a barbell — multiplexed H3 at one end, keep-alive H1 at the other, nothing
in between. We would not claim this holds universally, but it is a clean operational
observation worth recording.
Multiplexing in the wild: one handshake, ~17 requests
Across 24 hours, 431 HTTP/3 requests rode just 25 established QUIC connections. A single hybrid-PQC handshake is amortised across roughly seventeen multiplexed requests, with stream independence removing head-of-line blocking between them.
Where the H3 traffic goes
POST /api.php, /analytics/web/heartbeat).WebTransport: built, advertised, and waiting. Our WebTransport endpoint is fully wired and origin-checked, yet over a seven-day window the only sessions came from a known measurement scanner. There is no organic WebTransport traffic to study yet — we are provisioned ahead of demand, which is the right place to be.
A 563-domain snapshot of the HTTP/3 internet
Within our scan population, PQC-TLS is already the majority
This is where operating a PQC edge and scanning for PQC pays off: our scanner
reads the TLS key_share group and signature directly from each handshake —
actual protocol analysis, not a header check. Among the 128 HTTP/3 sites we scanned,
post-quantum TLS is no longer a rarity — a majority of them offered a PQC-hybrid key
exchange.
X25519MLKEM768 (FIPS 203) dominates; pre-NIST Kyber is a rounding error. The PQC signature we observed is ML-DSA-44 (94 observations).Our own edge as ground truth
All eight pqcrypta-operated domains were scanned, and all eight negotiate X25519MLKEM768 + ML-DSA-44 on the wire — earning the only A++ grades in the entire corpus. This cross-check validates the scanner's group/signature parsing against an edge whose configuration we control, and confirms the same suite is offered consistently across both the QUIC (rustls/aws-lc-rs) and TCP (OpenSSL 3.5) stacks.
api.pqcrypta.com X25519MLKEM768 ML-DSA-44 A++
pqcrypta.com X25519MLKEM768 ML-DSA-44 A++
pqpdf.com X25519MLKEM768 ML-DSA-44 A++
fated.org X25519MLKEM768 ML-DSA-44 A++
stlweb.dev X25519MLKEM768 ML-DSA-44 A++
office.stlweb.dev X25519MLKEM768 ML-DSA-44 A++
philibert.stlweb.dev X25519MLKEM768 ML-DSA-44 A++
philibill.stlweb.dev X25519MLKEM768 ML-DSA-44 A++
When a dashboard lies about your own key exchange
Cross-checking the scanner's view of our own edge against our configuration exposed a
real, if cosmetic, inconsistency. Our deployed config set
preferred_kem = "x25519_kyber768" — a deprecated pre-NIST name. Because the
legacy-pqc build feature is off by default, the parser silently resolved that
value to none and fell through to the recommended hybrid order, which begins with
X25519MLKEM768. So the wire was always correct (the A++ scan above proves
it) — but the startup banner, Prometheus active_kem metric and admin API all
reported the deprecated name, contradicting the actual handshake.
X25519MLKEM768; the parser hardened to emit a WARN on any
unrecognised preferred_kem instead of silently dropping it; docs
corrected. Post-deploy: startup banner, Prometheus metric and a live
openssl s_client probe all now agree —
Negotiated TLS1.3 group: X25519MLKEM768. The wire never
regressed; the reporting now tells the truth.
The lesson generalises: the single most useful finding here — a metric lying about our own key exchange — only surfaced because we scanned our own edge with the same tool we point at the internet. Ground-truth your dashboards against an external observer.
Conclusions
- In our deployment, HTTP/2 was vestigial. At this QUIC-first edge, traffic bifurcated into multiplexed H3 (browsers) and keep-alive H1 (machines), with h2 drawing no requests despite being enabled. Other deployments may differ — but it is worth checking your own logs before tuning h2.
- QUIC multiplexing delivered — ~17 requests per handshake in our logs — which is exactly why amortising an expensive PQC-hybrid handshake over a long-lived connection is sound.
- Budget for UDP reconnaissance. In our sample a third of inbound QUIC never completed; treat incomplete QUIC as a likely recon floor on UDP/443, not malfunction.
- Within our scan population, PQC-TLS is the majority. 52% of the HTTP/3 sites we scanned offered a hybrid KEX, dominated by
X25519MLKEM768 + ML-DSA-44; legacy Kyber was a rounding error. - The transports past H3 — MASQUE, WebTransport — are built but not yet populated. Being provisioned for them today is a bet on the next phase.
- Operate what you measure. Ground-truth your telemetry against an external observer; that is how the config defect above surfaced.
Related reading: QUIC / HTTP3 / WebTransport hardening, the QUIC vs TCP real-world whitepaper, the HTTP/3 scanner, and the pqcrypta-proxy documentation.
Frequently Asked Questions
Alt-Svc: h3 and switch to QUIC, staying on HTTP/3, while
everything else (bots, crawlers, sitemap pingers, uptime monitors) speaks
HTTP/1.1 with no QUIC stack. Traffic bifurcated into multiplexed H3 and keep-alive
H1, leaving the middle protocol empty. We report this as an observation from our
logs, not a universal claim.X25519MLKEM768.
ML-DSA-44 was the post-quantum signature we observed. Only two sites
still exposed the pre-NIST Kyber hybrid. This is our scan corpus, not a random
sample of the whole web.