PathNetwork-layer fingerprinting

Step 5 of 6

What Is HTTP/3 and QUIC Fingerprinting?

Pim · Scrappey Research

May 31, 2026 4 min read

Paste into ChatGPT, Claude, or any LLM

What Is HTTP/3 and QUIC Fingerprinting? — conceptual illustration

On this page

HTTP/3 / QUIC fingerprinting identifies a client from the QUIC transport layer that HTTP/3 runs on. QUIC is the modern transport beneath HTTP/3: instead of TCP, it runs on UDP (a fast, connectionless way to send packets) and carries its own TLS 1.3 handshake - TLS is the encryption layer behind https. Bundled in is a set of transport parameters (idle timeout, max packet size, active connection-id limit, flow-control windows) sent in the very first "Initial" packet. The exact values and their order, combined with the QUIC version and the embedded TLS Client Hello, form a fingerprint distinct from the TCP-based JA3/JA4 and HTTP/2 fingerprints. It also creates a leak risk, because UDP often slips past proxies that only carry TCP.

Transport	QUIC over UDP - carries its own TLS 1.3 handshake
Fingerprint inputs	QUIC version, transport parameters + order, Initial packet, embedded Client Hello
Distinct from	TCP JA3/JA4 and HTTP/2 - a separate signal vendors cross-check
Leak risk	UDP escapes TCP-only proxies, exposing the real IP/path
Common defence	Disable QUIC, or tunnel UDP (SOCKS5 UDP ASSOCIATE)

What QUIC exposes

When a client uses HTTP/3, it opens a QUIC connection, and the first few packets give a lot away. Three things vary depending on which software sent them: the QUIC version, the set and order of transport parameters (max_idle_timeout, max_udp_payload_size, initial_max_data, active_connection_id_limit, and others), and the structure of the Initial packet. Chrome's QUIC stack, Firefox's, and a Go or Rust QUIC library each produce a recognizable signature. On top of that, QUIC embeds a TLS 1.3 Client Hello, so the same JA3/JA4-style hash that identifies TLS applies inside QUIC too.

The result is a transport fingerprint that exists before the client has sent a single HTTP/3 request. A client whose QUIC signature does not look like a real browser's is as identifiable as one with a non-browser JA3 - and because HTTP/3 is newer, these mismatches are common in DIY stacks that bolt HTTP/3 onto a library.

The UDP leak problem

QUIC runs on UDP, and this is where many proxied scrapers fail in a way that has nothing to do with the fingerprint hash. Most proxy setups only carry TCP. If the browser is allowed to use HTTP/3, its QUIC/UDP packets may travel around the proxy straight to the destination - exposing the real IP and network path even though all the TCP traffic is cleanly proxied. The same UDP-escape problem affects WebRTC STUN (the mechanism browsers use to discover their own IP for peer-to-peer calls). It is a transport-level leak sibling.

So HTTP/3 is a double exposure for scrapers: a transport fingerprint that can mismatch the claimed browser, and a UDP path that can bypass the proxy entirely.

How scrapers handle it

There are two strategies. The conservative one is to disable QUIC/HTTP3 so the browser falls back to HTTP/2 over TCP. This keeps all traffic inside the proxy and avoids the QUIC fingerprint surface entirely. It is common and safe - though a site that offers HTTP/3 and sees a "Chrome" client that never attempts it can treat that as a (weak) signal, since real Chrome usually tries HTTP/3.

The thorough one is to tunnel UDP through the proxy (using SOCKS5 UDP ASSOCIATE, a proxy feature that forwards UDP as well as TCP) so QUIC/STUN stay inside the tunnel and the QUIC fingerprint comes from a real browser stack. Few proxy providers support UDP ASSOCIATE, which is why high-end anti-detect tooling that implements UDP-over-SOCKS5 natively is relatively rare. For most scraping, disabling QUIC is the pragmatic default; serious operators who need HTTP/3 parity invest in UDP-capable proxies or managed APIs that handle the transport for them.

Code example

text

Three layers a modern anti-bot stack fingerprints, all before HTTP content:

  TCP path:    TLS Client Hello   -> JA3 / JA4
               HTTP/2 SETTINGS    -> JA4H / Akamai h2 fingerprint
  UDP path:    QUIC Initial       -> QUIC version + transport params + embedded CH

QUIC transport parameters (order + values are implementation-specific):
  max_idle_timeout, max_udp_payload_size, initial_max_data,
  initial_max_stream_data_*, active_connection_id_limit, ...

Two failure modes for a proxied scraper using HTTP/3:
  1) QUIC signature != claimed Chrome  -> transport fingerprint mismatch
  2) UDP escapes the TCP-only proxy    -> real IP leak

Pragmatic default: disable QUIC so everything stays HTTP/2 over the proxy.
Thorough: tunnel UDP (SOCKS5 UDP ASSOCIATE) with a real browser QUIC stack.

Next in Network-layer fingerprinting · 6 of 6

One more network path can betray your real egress entirely.

What Is a WebRTC IP Leak?

Related terms

What Is TLS Fingerprinting (JA3/JA4)?

TLS fingerprinting is a way to recognize what software made a connection just by looking at how it sets up encryption — before the server re…

What Is HTTP/2 Fingerprinting?

HTTP/2 fingerprinting identifies an HTTP client from its SETTINGS frame and frame-level behaviour, independent of the TLS layer. Think of it…

What Is JA4 Fingerprinting?

JA4 is a way to identify a browser by the fingerprint of its TLS handshake — TLS being the encryption layer behind https. It replaced the ol…

What Is a WebRTC IP Leak?

A WebRTC IP leak is when your browser quietly reveals your real IP address — even though you set up a proxy to hide it. It is the most-overl…

What Is a DNS Leak?

A DNS leak is when your computer looks up website names through its own DNS resolver instead of through the proxy, which exposes the real ne…

Anti-Bot Vendor Detection Cheatsheet

A useful first step when working with any protected site you are authorized to access is identifying which anti-bot vendor sits in front of …

Concept map

How HTTP/3 / QUIC Fingerprinting connects

The terms most directly tied to this one. Hover a node to see its neighbours, click to preview, drag to rearrange.

0 terms · 0 connections

You are here · Anti-Bot

Tools & solutions for this topic

Frequently asked questions

Should I disable HTTP/3 in my scraper?

For most proxied scraping, yes - disabling QUIC keeps all traffic on TCP inside the proxy, avoids the UDP-leak risk, and removes the QUIC fingerprint surface. The minor downside is that a site offering HTTP/3 may notice a Chrome client that never attempts it, which is a weak signal. If you need true HTTP/3 parity, you must tunnel UDP through the proxy.

Is the QUIC fingerprint the same as the TLS fingerprint?

No, but it contains one. QUIC carries its own TLS 1.3 Client Hello (so a JA3/JA4-style hash applies inside it), but it also adds the QUIC version and transport parameters, which are a separate signal. Vendors can cross-check the QUIC signature against the TCP-based TLS and HTTP/2 fingerprints to see whether they all agree - a mismatch is a red flag.

Why does HTTP/3 leak my real IP through a proxy?

QUIC runs on UDP, and most proxies only carry TCP. If the browser uses HTTP/3, its UDP packets can travel directly to the destination, bypassing the proxy and exposing your real IP - even though your TCP traffic is fully proxied. The fix is to disable QUIC or use a proxy that supports UDP ASSOCIATE (which forwards UDP too).

Last updated: 2026-05-31