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 built on UDP and carries its own TLS 1.3 handshake plus a set of transport parameters (idle timeout, max packet size, active connection-id limit, flow-control windows) sent in the Initial packet. Their values and 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 escapes 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 negotiates HTTP/3, it opens a QUIC connection whose first packets reveal a lot. 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 all vary by implementation. 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 JA3/JA4-style hash applies inside QUIC too.

The result is a transport fingerprint that exists before any HTTP/3 request frame. A client that speaks HTTP/3 with a non-browser QUIC signature is as identifiable as one with a non-browser JA3 - and because HTTP/3 adoption is newer, 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 carry TCP. If the browser is allowed to use HTTP/3, its QUIC/UDP packets may go around the proxy directly 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. 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

Two strategies. The conservative one is to disable QUIC/HTTP3 so the browser falls back to HTTP/2 over TCP, keeping all traffic inside the proxy and avoiding the QUIC fingerprint surface entirely. This 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 (SOCKS5 UDP ASSOCIATE) 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 technique that identifies an HTTP client from its TLS handshake — before the server reads a single request byte. The…
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. Every HTTP/…
What Is JA4 Fingerprinting?
JA4 is a TLS client fingerprint that replaced JA3 after Chrome began randomising the order of its TLS extensions. JA3 hashed the extension l…
What Is a WebRTC IP Leak?
A WebRTC IP leak is the most-overlooked failure mode in browser-based scraping in 2026: WebRTC reveals your real local and public IP via STU…
What Is a DNS Leak?
A DNS leak is when a client resolves hostnames through its own DNS resolver instead of through the proxy, revealing the real network behind …
Anti-Bot Vendor Detection Cheatsheet
The first step of any scrape against a protected site is identifying which anti-bot vendor is in front of it. The vendor determines almost e…
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 distinguish automated traffic from human users — and to block, challenge, or thr…
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…
What Is Browser Fingerprinting Evasion?
Browser fingerprinting evasion is the practice of configuring an automated browser so that the combined fingerprint it presents — canvas, We…
How Do Websites Detect Web Scrapers?
Websites detect scrapers by collecting hundreds of signals across the network, transport, browser, and behavioral layers, then scoring the c…

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 TLS and HTTP/2 fingerprints for coherence.

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.

Last updated: 2026-05-30