Is Your Proxy Ready for HTTP/3? Beyond HTTP/2 & HTTP/1.1

HTTP/3 is the latest iteration of the web’s core transfer protocol. This is built on top of UDP to provide faster connections, native encryption, improved multiplexing, and more.

In this article, we cover what’s new in HTTP/3 compared to its predecessors and how it behaves in real-world proxy environments.

What’s new with HTTP/3?

HTTP/3 builds on several features of HTTP/2 to deliver a new protocol to ultimately pave the way for faster and more secure connections.

The backbone of this transformation is the shift from TCP to QUIC (explained later). Before going to that section, let’s understand what has changed from HTTP/1.1, through HTTP/2, and finally to HTTP/3.

HTTP/1.1 vs HTTP/2 vs HTTP/3

The following table presents a highly curated summary of the differences among the last three HTTP versions.

QUIC over UDP: Next-Generation Multiplexed Transport

Google introduced the QUIC protocol as Google QUIC (or gQUIC) in 2012. Fast forward a few years, in 2015, Google submitted gQUIC to IETF, which, after many iterations/experimentations, released QUIC in May 2021 as RFC 9000.

It was a seismic shift from the earlier TCP+TLS-based transport, as seen in HTTP/2, by directly building on UDP. And though QUIC runs over UDP, it’s not a stateless protocol. It maintains connection state, reliability, and congestion control internally, carrying over TCP's strengths to QUIC.

This new transport design also improves how HTTP/2 originally multiplexed, in which a lost packet would still stall the entire connection. With QUIC, a single connection can carry all streams independently at the transport layer without any enforced order. This eliminated connection-level head-of-line blocking, so a stream with a lost packet can wait for recovery while other streams travel unaffected.

Another upside is that QUIC has TLS 1.3 natively configured into its transport layer. This ensures the connection is encrypted and authenticated by default. In addition, the initial QUIC handshake combines cryptographic and transport handshakes to minimize connection latency. In some cases, clients can even send data with zero round-trips (0-RTT) (although this requires prior communication and comes with replay risks).

Developers could also benefit from QUIC's ability to identify connections using Connection IDs rather than IP addresses. This allows the connections to persist, unaffected by the changes in IP addresses and ports. In practice, this is great news if you're building for mobile devices. Since these users frequently hop from one network to another, QUIC helps to prevent session drops and the need for re-handshakes.

However, there are still a few aspects that developers need to consider, which we discuss in the subsequent sections.

Performance and reliability trade-offs of HTTP/3

Though HTTP/3 is an excellent upgrade over HTTP/2, it’s better if you understand the overall picture, since every improvement comes with a corresponding cost.

• Latency: While 0-RTT allows you to send data immediately without waiting for a full handshake, it makes the application susceptible to an attacker replaying previous requests (replay attacks). To mitigate this, you must configure anti-replay measures, such as choosing which specific 0-RTT requests to accept or implementing tighter session ticket lifetimes, on the server or proxy.
• Head-of-line blocking: Since the streams travel independently, you now have QUIC to handle reliability, ordering, and congestion control instead of the OS kernel. In high-throughput environments, this can shift bottlenecks to the CPU, reducing HTTP/3 capacity per server compared to what you might achieve with HTTP/2.
• Connection migration: Relying on Connection IDs rather than IP/port tuples is another big resilience win for end users. However, this means you can’t rely on IP or port for connection tracking anymore. You must maintain the connection state independently, which can make the routing logic more complex.

When HTTP/3 improves performance and when it is negligible

We have created this section as a high-level summary, helping you evaluate when HTTP/3 delivers meaningful benefits or when you can stay with your existing configuration.

Adopt HTTP/3 for:

High-latency connections: Reduced connection setup time from QUIC’s combined handshake, along with faster repeat connections via 0-RTT, will benefit users located farther from your servers.

Mobile or unstable networks: QUIC’s positive impact is more noticeable when latency and packet loss are present, such as when users switch networks (e.g., from WiFi to 5G) or when network quality fluctuates. Moreover, HTTP/3 can improve perceived page load times, especially when multiple resources load simultaneously.

Still, you can delay the HTTP/3 upgrade:

For stable, low-latency environments: Since HTTP/2 already multiplexes, the HTTP/3 performance gains become less significant when users are close to servers or if networks are stable.

HTTP/3 Support: Research suggests that you will have little performance benefit if your site does not pull resources from domains that support HTTP/3.

Short-lived connections: HTTP/3 key latency advantage (0-RTT) comes into play for reused connections. For short-lived connections, the difference over HTTP/2 can be minimal and not worth switching to.

Security, privacy, and visibility implications

HTTP/3 changes not just performance characteristics, but also how traffic is secured and controlled across networks. These changes are largely driven by QUIC’s design choices around encryption and transport, as explained subsequently.

TLS 1.3, Encrypted Transport, and Inspection Limits

HTTP/3 is underpinned by QUIC, which comes with TLS 1.3 built into its transport layer. This means encryption is mandatory by design, and there is no way around it.

Moreover, QUIC encrypts not just the application data but also most transport-level metadata. As a result, you lose much of the passive visibility that you might have enjoyed with HTTP/2 over TCP.

In practice, this means deep packet inspection, traffic classification, and handshake analysis aren’t as effective anymore. Since QUIC encrypts most transport signals, intermediaries have limited visibility into traffic behavior.

And if you want similar visibility, you have to terminate TLS, which can introduce trade-offs with performance, certificate management, and privacy.

IP Leak Fears, Real Risks, and How to Test Safely

Since QUIC uses connection IDs, your proxies and VPN setups can’t rely solely on legacy configurations based on IP and port.

Because in practice, older or misconfigured systems often block or mishandle UDP traffic. And since HTTP/3 is UDP-based, this can prevent QUIC connections from being established, ultimately leading to a fallback to HTTP/2.

Plus, in some cases where the network allows outbound UDP/443 and the proxy is configured only for TCP, the client may connect via QUIC directly (without the proxy). On the surface, this may look like an IP leak, but it is generally a configuration issue.

You can test this by hitting an HTTP/3-enabled endpoint and checking the gateway or proxy logs to see whether UDP/443 traffic is being handled as intended. If not, and if you need strict routing, you can disable QUIC and force fallback to HTTP/2.

Firewall and Gateway Considerations for UDP/443 and QUIC

Typically, a client never attempts HTTP/3 initially. It’s attempted only if Alt-Svc headers were found in previous HTTP/1.1 or HTTP/2 responses, or if a DNS SVCB record was found.

Once negotiated, HTTP/3 runs over QUIC, which means UDP/443 must be open alongside TCP/443. However, QUIC cannot be reliably identified by port numbers alone, since other protocols may also use the same port, making simple port-based filtering insufficient, as noted in the IETF manageability guide.

If you need to disable QUIC without breaking user experience, the IETF recommends rejecting connections rather than silently dropping packets. This allows applications to fall back to HTTP/2 over TCP instead of failing outright.

Blocking QUIC is therefore sometimes used as a practical way to restore inspection capability by forcing traffic back to TLS over TCP.

Finally, QUIC introduces amplification considerations during connection establishment. Servers are required to limit how much data they send before validating a client’s address, preventing abuse during the handshake.

How does HTTP/3 interact with different proxy types?

Most traditional proxy setups were built around TCP, which creates a natural misalignment with the UDP-based QUIC protocol. This is reflected in the fact that not many providers support HTTP/3 proxies. (As for us, HTTP/3 is on our beta network, and HTTP/2 has been on our network for a while now.)

In the following sections, we explain how HTTP/3 requirements apply to different proxy types and a few essential fundamentals related to supported proxy environments.

HTTP proxies vs HTTPS proxies vs SOCKS5 proxies

HTTP Proxies: HTTP proxies expect plaintext (TCP traffic) since they are designed primarily for HTTP/1.1. Put simply, they don’t understand QUIC or handle UDP transport, so they can’t support HTTP/3.

HTTPS Proxies: Although HTTPS proxies can tunnel traffic using the CONNECT method, they still use TCP. Since QUIC is UDP-based, these proxies can’t support HTTP/3 traffic either.

SOCKS5 Proxies: These are more flexible at the protocol level because they support both TCP and UDP. So, they can carry QUIC traffic, but only if UDP relay is enabled and properly handled. In practice, however, it is often disabled in production environments for security or simplicity.

Which proxy types can carry UDP or QUIC-related traffic?

For a proxy to carry UDP or QUIC-related traffic, it must support UDP transport.

Currently, SOCKS5 remains the primary legacy option for UDP support, though we are gradually seeing a shift toward MASQUE-based architectures (which allow proxying UDP over HTTP/1.1, HTTP/2, and HTTP/3 by using the CONNECT-UDP method) in more modern stacks.

However, we would like to clarify the speed claims often associated with HTTP/3 proxies. While HTTP/3 can be faster due to 0-RTT handshakes and the absence of head-of-line blocking, these gains are often less visible in a proxy context.

Where browser fallback to HTTP/2 still happens

Since browsers are designed to be resilient, they will fall back to HTTP/2 or HTTP/1.1 if the network path (including the proxy) prevents a QUIC handshake.

This commonly happens when UDP/443 is blocked at the firewall or gateway, when the proxy only supports TCP, or when the QUIC handshake fails due to latency or configuration limits.

It’s easy to overlook this during testing. We might assume HTTP/3 is in use because both the browser and the server support it, but in reality, the traffic has already fallen back.

How does HTTP/3 traffic pass through a proxy?

When we introduce a proxy into the network path, we’re simply adding a layer to handle UDP traffic. Since HTTP/3 relies on a different transport architecture, we need to look at how different clients handle that negotiation when a proxy is introduced.

Browser behavior: Chrome, Firefox, Edge, Safari

Browsers generally attempt HTTP/3 once an Alt-Svc header advertises QUIC support, but they are also extremely risk-averse in the sense that they won’t let a failed QUIC handshake break the page load.

The following sections explain the HTTP/3 behavior for mainstream browsers.

Chrome & Edge (Chromium): Generally, Chrome and Edge aggressively attempt QUIC connections via the Alt-Svc header. However, Chromium typically defaults to a TCP-based CONNECT tunnel when it detects a standard HTTPS proxy. Unless the proxy explicitly advertises UDP support (via newer protocols like MASQUE), the browser usually stays on HTTP/2.

Firefox: Firefox follows similar logic but is generally more conservative in proxy environments. When UDP paths are unreliable or unsupported, it sticks to TLS over TCP to ensure the connection does not hang.

Safari: Safari, while supports HTTP/3, is sensitive to network conditions. You will notice it falls back to HTTP/2 if it detects UDP packet interference in the proxy path.

App behavior: curl, automation tools, mobile apps, API clients

Unlike the browsers, tools aren’t that robust in automatic fallbacks, and you need to be explicit in how they behave with HTTP/3 or in the absence of it.

curl: Curl is originally designed for HTTP/1.1 or HTTP/2. For HTTP/3, you need to add the --http3 flag and ensure that it is compiled with a QUIC library such as ngtcp2 or quiche. Also note that if your proxy doesn’t support UDP, curl will simply fail the request instead of falling back to HTTP/2 or HTTP/1.1.

Automation tools (Puppeteer/Playwright): These typically inherit the behavior of the underlying browser binary. However, they will usually operate over HTTP/2 if the correct network settings are not configured to enable UDP support.

Mobile apps and API clients: Some mobile SDKs, such as Google’s Cronet, ship with HTTP/3 (QUIC) support. With a proxy, some clients may still skip or limit Alt-Svc discovery (to avoid the latency of failed UDP attempts), favoring TCP's stability.

Common reasons traffic bypasses inspection or falls back

Here are some cases where the traffic might not always behave as expected in proxy environments.

• The client may establish a direct QUIC connection if a proxy only supports TCP and the network allows outbound UDP/443, bypassing the proxy and any inspection logic.
• Similarly, you may notice the client falling back to HTTP/2 over TCP due to a failed QUIC handshake when UDP is blocked or ignored.
• And since QUIC uses TLS 1.3, proxies attempting interception without full HTTP/3 support can trigger certificate validation failures. This may prompt the client to drop the connection or fall back to a supported protocol.

Do you actually need HTTP/3-aware proxying?

Before you make any infrastructure changes, we suggest making a distinction between HTTP/3 to the proxy and HTTP/3 to the target.

Though we support this in beta, HTTP/3 to the proxy is still rare. On the other hand, HTTP/3 to the target can be achieved using SOCKS5 proxies with UDP support or newer approaches like HTTP CONNECT-UDP (which we plan to support soon).

In practice, most confusion around HTTP/3 proxying comes from a few common assumptions:

• Mistaking browser support for end-to-end proxy support: Just because the browser supports HTTP/3 doesn’t mean the proxy path does. In most setups, traffic still runs over HTTP/2 between the client and proxy.

• Buying “UDP support” without a real use case: Enabling UDP doesn’t automatically improve performance. HTTP/3 benefits depend on factors such as latency, packet loss, and connection reuse.

• Misreading blocked inspection as broken proxying: You should expect reduced visibility when QUIC is in use. However, this is often mistaken for proxy failure, even though traffic is flowing correctly.

How to force HTTP/2 when HTTP/3 causes problems

For whatever reason, if HTTP/3 isn’t working for your setup, here are some ways to fallback to HTTP/2.

You can disable HTTP/3 at the server level by not advertising it via Alt-Svc headers. You can also do this at the client level in controlled environments by configuring the clients to avoid QUIC entirely. Either way, this will prevent the client from discovering HTTP/3 support.

Alternatively, you can block or restrict UDP/443 at the network or firewall so clients can’t establish QUIC.