Skip to content

HTTP/3 Through a Proxy: Does Your Scraper Need It Yet?

By . Published

Your browser talks HTTP/3 to a growing share of the web. Put a typical proxy in the middle, and that connection quietly falls back to HTTP/2 over TCP.

For years nobody cared. Now proxy providers are shipping HTTP/3 support. Oxylabs launched MASQUE-based HTTP/3 proxying in October 2026, and the question is landing in buyers' inboxes: do you need this, and does your provider already have it?

This guide explains what HTTP/3 and QUIC are, why proxies usually downgrade them, the two ways to carry HTTP/3 through a proxy, and when it matters for scraping.

Quick answer: Can you use HTTP/3 through a proxy? Yes, but only if the proxy can carry UDP. HTTP/3 runs on QUIC, which uses UDP, and a standard HTTP CONNECT proxy only carries TCP. The two working options are SOCKS5 with UDP support and MASQUE (CONNECT-UDP over HTTP/3). Chrome and Firefox don't send UDP through SOCKS5, so for stock browsers MASQUE is the only route. Most scraping jobs still work fine on HTTP/2.

HTTP/3 and QUIC in plain terms

HTTP/3 is the newest version of the protocol your browser uses to load pages. The big change is underneath: HTTP/1.1 and HTTP/2 run on TCP, while HTTP/3 runs on QUIC, which is built on UDP.

Why that matters in practice:

  • Faster setup. QUIC combines the connection and encryption handshakes, so there are fewer round trips before the first byte.
  • No head-of-line blocking. On HTTP/2, one lost TCP packet stalls every request on that connection. QUIC streams recover independently.
  • Connection migration. A QUIC connection can survive a network change, like Wi-Fi to cellular, without starting over.

This is no longer a niche protocol. W3Techs puts HTTP/3 on 41.1% of all websites as of October 2026, and 45.1% of the top 1 million. Over 93% of browsers in use support it, according to Can I Use figures cited by Web Scraper.

The catch for scraping: when a browser or HTTP client goes through a normal proxy, HTTP/3 usually isn't an option at all.

Why most proxies downgrade HTTP/3

The standard way to proxy HTTPS is the HTTP CONNECT method. Your client asks the proxy to open a TCP tunnel to the target, then runs TLS through it. That works for HTTP/1.1 and HTTP/2, which both run on TCP.

QUIC runs on UDP, so it can't go through a TCP tunnel. When the client can't reach the site over QUIC, it falls back to HTTP/2 over TCP, usually with no error and no warning. As Oxylabs puts it, HTTP/3 simply can't pass through a traditional TCP tunnel.

There are two established ways to give HTTP/3 a UDP path through a proxy:

SOCKS5 with UDP MASQUE (CONNECT-UDP)
Standard RFC 1928, UDP ASSOCIATE command (1996) RFC 9298, Proxying UDP in HTTP (2022)
How it works Client opens a SOCKS5 session, then sends UDP datagrams through the proxy's relay Client opens a UDP tunnel inside an HTTP connection to the proxy, using HTTP Datagrams
Client support Common for TCP; UDP needs a client built for it. Chrome and Firefox send only TCP through SOCKS5 Newer; Firefox implements it, few other clients do
Carries other UDP traffic Yes: DNS, WebRTC, VoIP, games Yes, any UDP
Proxy connection itself Plain SOCKS5 Can run over HTTP/3 to the proxy

Both get the job done: a real QUIC connection runs end to end from your client to the target, and the site sees HTTP/3. The practical difference is which one your client and your provider support. Chromium's proxy docs say SOCKS5 in Chrome "cannot be used to relay UDP traffic", and Firefox's networking docs describe CONNECT-UDP as its path for proxied HTTP/3. So SOCKS5 UDP is for QUIC libraries and tools, not stock browsers.

Does the downgrade hurt scraping?

Sometimes. The evidence points to a small but real effect on detection, a bigger effect on speed over bad networks, and a new fingerprint to get right if you switch.

Detection: bots mostly don't speak HTTP/3

Web Scraper's July 2026 analysis of Cloudflare Radar data found about 34% of likely-human traffic used HTTP/3, compared with about 2% of likely-bot traffic (Web Scraper). If your client says it's Chrome but never negotiates HTTP/3 on a site that offers it, you look more like the 2%.

The same team tested 7 proxy providers. Only 2 offered working HTTP/3 proxying, and those gave a few percentage points better data availability than HTTP/2 proxies. They note it's hard to separate that from overall provider quality, so treat it as directional.

Speed: it matters most on lossy networks

A Washington University in St. Louis testbed study compared HTTP/3 and HTTP/2 through proxies. On a clean network, a 10 MB download took about 9 seconds either way. With 12% packet loss and 20 parallel files, HTTP/2 took 113.4 seconds and HTTP/3 took 21.0 seconds.

The takeaway: on stable server-grade connections, the gap is small. On lossy links, HTTP/3 can be much faster.

The trade-off: a new fingerprint

QUIC has its own fingerprint: version, transport parameters and their order, and the TLS Client Hello inside the first packet (Scrappey). A Python or Go QUIC library doesn't look like Chrome. Switching to HTTP/3 with a mismatched client can trade one inconsistency for another.

When you need HTTP/3 through a proxy (and when you don't)

Most scraping jobs run fine on HTTP/2. HTTP/3 support starts to matter when your client is supposed to look like a modern browser and the target is protected.

Your situation HTTP/3 through the proxy? Why
Real or automated Chrome/Firefox hitting a protected site Only through MASQUE Neither browser sends UDP over SOCKS5, so a SOCKS5 or HTTP proxy means HTTP/2
Your own QUIC client with a browser-like fingerprint Worth testing over SOCKS5 UDP This is the case SOCKS5 UDP serves today
Scraping APIs, sitemaps or lightly protected pages Skip it Nobody checks; HTTP/2 or HTTP/1.1 is normal for these clients
Python or Go HTTP client with a non-browser fingerprint Skip it, or fix the client first A mismatched QUIC fingerprint can hurt more than it helps
Large downloads or many parallel requests over lossy links Worth testing HTTP/3 handles packet loss much better
Static ISP or datacenter IPs on stable links Optional The speed gain is small on clean networks
WebRTC, DNS or other UDP traffic from your own tools Needed anyway You need a UDP-capable proxy regardless

Two checks before you switch:

  1. Does the target offer HTTP/3? Look for an alt-svc: h3 header in its response.
  2. Does your client actually use it? Run a request through the proxy and check the negotiated protocol. If it silently says HTTP/2, the UDP path isn't working.

How Stat Proxies handles HTTP/3

Stat Proxies carries HTTP/3 over SOCKS5 UDP. We don't offer MASQUE. Every IP supports HTTP, HTTPS and SOCKS5 with the same username and password, and SOCKS5 is included at no extra cost. SOCKS5 carries both TCP and UDP, so QUIC, DNS, WebRTC, VoIP and game traffic leave from the IP you bought. In our own test, a Python QUIC client (aioquic) negotiated h3 with the target over SOCKS5 UDP, and the target saw the proxy IP.

To use it:

  1. In your dashboard, switch the proxy list from HTTP(S) to SOCKS5. The IPs, username and password stay the same.
  2. Use a client that sends UDP through SOCKS5 and supports SOCKS5 username and password auth. Many SOCKS5 clients only carry TCP, and Chrome and Firefox are among them.
  3. Check the negotiated protocol to confirm you're getting HTTP/3, not a fallback.

If you need a stock Chrome or Firefox to negotiate HTTP/3 through a proxy, we're the wrong pick for that part of the job: browser traffic through our IPs uses HTTP/2. For regular browser and scraper traffic, including HTTPS sites, the HTTP endpoint is still the simplest place to start.

HTTP/3 is one part of looking consistent. Our IPs also send a Windows 11 TCP/IP fingerprint by default, and you can add -os-macos, -os-ios or -os-linux to your username to match your User-Agent. That profile applies to TCP connections, including TCP over SOCKS5. QUIC runs over UDP, so the profile doesn't change it: the QUIC fingerprint a site sees comes from your client. See how TCP/IP fingerprinting works, how to check your proxy's fingerprint and our static ISP proxies for full specs.

FAQ

Do proxies support HTTP/3?

Only proxies that can carry UDP. A standard HTTP CONNECT proxy tunnels TCP, so HTTP/3 falls back to HTTP/2. SOCKS5 with UDP support and MASQUE (CONNECT-UDP) both carry HTTP/3, but Chrome and Firefox only use MASQUE for proxied HTTP/3; they send nothing but TCP through SOCKS5.

Why does my scraper use HTTP/2 even though the site supports HTTP/3?

Usually because the proxy or the client can't send UDP. HTTP/3 runs on QUIC over UDP, and when that path fails, clients fall back to HTTP/2 over TCP without an error. Chrome and Firefox do this on every SOCKS5 or HTTP proxy, because they don't send UDP through either.

What is MASQUE?

MASQUE is a set of IETF standards for proxying traffic over HTTP. Its CONNECT-UDP method, defined in RFC 9298, opens a UDP tunnel through an HTTP proxy so QUIC and HTTP/3 can run end to end.

Is SOCKS5 or MASQUE better for HTTP/3?

Both carry HTTP/3. SOCKS5 with UDP works with QUIC libraries and tools built to send UDP through SOCKS5. Chrome and Firefox don't, so for stock browsers MASQUE is the only route. Pick the one your client and provider both support.

Does Stat Proxies support HTTP/3?

Yes, over SOCKS5 UDP, for clients that send UDP through SOCKS5. Every IP includes SOCKS5 with the same username and password at no extra cost, from $2.50 per IP per month. We don't offer MASQUE, so stock Chrome and Firefox use HTTP/2 through our IPs.

Does HTTP/3 help avoid bot detection?

It can remove one inconsistency. Analysis of Cloudflare Radar data found about 34% of likely-human traffic uses HTTP/3 versus about 2% of likely-bot traffic. But QUIC has its own fingerprint, so your client needs to look like the browser it claims to be.

How much of the web supports HTTP/3?

W3Techs puts HTTP/3 on 41.1% of all websites and 45.1% of the top 1 million, as of October 2026.

Sources