Anti-Bot

What Is HTTP/3 and QUIC Fingerprinting?

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.

Quick facts

TransportQUIC over UDP - carries its own TLS 1.3 handshake
Fingerprint inputsQUIC version, transport parameters + order, Initial packet, embedded Client Hello
Distinct fromTCP JA3/JA4 and HTTP/2 - a separate signal vendors cross-check
Leak riskUDP escapes TCP-only proxies, exposing the real IP/path
Common defenceDisable 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.

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 …
What Is Browser Fingerprinting?
Browser fingerprinting is a technique that identifies and tracks a visitor by combining dozens of small, observable characteristics of their…
What Is Anti-Bot Detection?
Anti-bot detection is the set of techniques websites use to tell automated traffic apart from real human visitors — and then block, challeng…
What Is Headless Browser Detection?
Headless browser detection is the set of probes anti-bot systems use to distinguish a headless or instrumented Chrome session from a real us…
How Browser Fingerprinting Works
Browser fingerprinting is how a site combines signals — canvas, WebGL, audio, fonts, navigator probes, TLS (the encryption layer behind http…
How Do Websites Detect Web Scrapers?
Websites spot scrapers by gathering hundreds of small clues about each visitor, then scoring how human the whole picture looks. No single cl…

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
Building map…

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