Shifting from TCP to become QUIC-aware is a big architectural change for any proxy provider. The differences are more nuanced than simply providing HTTP/3 support.
This guide covers protocol-level differences, from MASQUE and Connection IDs to computational overhead, that one should account for realistically. Not only this, we have also shared some of the major use cases for QUIC tunneling and discussed general adoption challenges.
What is a QUIC proxy?
You can consider a QUIC or QUIC-aware proxy as a middlebox designed to route data over the UDP-based transport protocol, QUIC. For a QUIC-aware proxy, it’s important to avoid diluting the core QUIC benefits, such as built-in encryption, independent multiplexing, and unified transport and TLS handshakes.
And to adapt to these underlying QUIC principles, proxy providers (like us!) need to significantly tune their infrastructure since it’s not as simple as proxying TCP-based HTTP requests.
With TCP, providers get plain text transport metadata, including sequence numbers, ACK information, and flow control fields. Conventionally, this helped proxy developers establish and manage connections.
But things aren’t as straightforward with QUIC, as it encrypts transport data and has encryption and multiplexing directly integrated into its protocol. Not only that, QUIC doesn’t rely on conventional 4-tuples and instead uses connection IDs for packet routing.
All of this means that for a proxy to become QUIC-aware, it must maintain its own logic for flow state, ports, targets, congestion control, stream multiplexing, and connection migration.
But despite the challenges, proxying QUIC can be rewarding if the proxy configuration enables the end consumer to reap the rewards.
First, compared to HTTP proxies, connection establishment can be faster due to QUIC's low-latency handshakes. You also won’t have to re-establish proxy tunnels when a user switches networks (such as Wi-Fi and cellular), ensuring a seamless session experience on mobile devices without connection drops.
Another upside is the integration of TLS 1.3, so developers don’t have to retrofit encryption later. And since the World Wide Web is quickly moving toward HTTP/3, it’s better to adopt these changes sooner rather than later to reduce future compatibility gaps.
The Shift from CONNECT to MASQUE
Prior to MASQUE, there was no UDP equivalent to what HTTP CONNECT allowed with TCP connections.
As a workaround, developers used to encapsulate UDP within TCP, which created double retransmission overhead (UDP-over-TCP). Also, doing that reintroduced head-of-line (HoL) blocking, something TCP connections are known to suffer from.
But since QUIC runs over UDP and has its own mechanisms for handling packet loss, security, and congestion control, it was counterintuitive to keep wrapping UDP in TCP.
MASQUE (Multiplexed Application Substrate over QUIC Encryption) offers a standardized tunnel for proxying UDP over HTTP (CONNECT-UDP). This provides a robust framework for modern protocols like QUIC, which are underpinned by UDP.
Not only this, MASQUE lets you use the same proxy-to-target UDP 4-tuple for distinct QUIC connections to a specific target, which TCP simply can’t achieve.
Lastly, MASQUE extends beyond UDP by offering the CONNECT IP protocol, which enables sending random IP packets. This allows a MASQUE-based QUIC proxy to function similarly to a remote-access or site-to-site VPN for tunneling UDP, TCP, ICMP, or any other IP protocol without needing a VPN client.
Citing these benefits, MASQUE is receiving a warm reception across the industry. One notable in-practice MASQUE implementation is iCloud Private Relay (an Apple privacy service). While Apple handles the first hop, Cloudflare (the second relay) plugs MASQUE to provide quick and secure data transfers.
How QUIC-Aware Proxies Move Traffic?
The IETF QUIC proxy draft outlines two operational modes (tunneled and forwarded) for QUIC-aware proxies. We have briefly discussed both in the following sections, along with how a QUIC proxy handles Connection ID conflicts in these modes.
Tunneled mode
This is the default mode governed by the CONNECT-UDP method.
Packets are first encrypted end-to-end over QUIC between the client and the target, and then carried within an HTTP Datagram frame. That frame travels over another QUIC connection, going through a second round of encryption, this time between the client and the proxy.
This technique ensures that even QUIC long-header packets (such as those used during handshakes) remain secure and hidden from the proxy, which is great from a privacy standpoint. On the downside, it introduces multiple rounds of encryption and congestion control.
Forwarded mode
Forwarded mode eliminates full re-encapsulation and re-encryption between the client and the proxy. Instead, QUIC encryption is applied as usual between the client and the target, but the client-to-proxy path is managed by QUIC Connection IDs and special-purpose transforms.
This is a lightweight alternative to wrapping packets in HTTP Datagram and re-encrypting them externally, when all you need is end-to-end QUIC encryption between the client and the target. The idea is to reduce CPU/RAM consumption and avoid unnecessary encapsulation to preserve the effective MTU (Maximum Transmission Unit).
However, the forwarded mode is only suitable for short header packets. For the long one, one still needs to use the default tunnel to protect sensitive handshake information from the intermediary server.
Connection ID handling
Instead of solely relying on UDP 4-tuples, QUIC-aware proxies track Connection IDs (the client’s and the target’s) and the HTTP stream to allow multiple QUIC connections to share the same proxy-to-target UDP path.
In tunneled mode, a proxy maps Connection IDs between the client and the target to reuse 4-tuples, while the original packets remain untouched within HTTP Datagrams.
But since there is no such protection in the forwarded mode, a QUIC-aware proxy introduces Virtual Connection IDs (VCIDs) between the client and the proxy server. These VCIDs are swapped with the real target and client CIDs before forwarding to ensure error-free routing and load balancing.
At the same time, it’s up to the proxy to detect and reject CID conflicts. Two CIDs conflict when one equals the other or its prefix, including zero-length CIDs. Therefore, QUIC-aware can reject short CIDs to avoid possible future conflicts.
The State of QUIC Proxying: Use Cases vs. Challenges
QUIC proxying can seem interesting or technically complex to anyone. Regardless, there are multiple modern-age domains where implementing QUIC proxying can prove rewarding. However, like any other technology, there are some caveats to be aware of up front.
Therefore, we have summarized where QUIC proxying is a strong candidate and the hurdles you might face in the following sections.
Use Cases of QUIC Proxying
Low-overhead VPN tunneling: Conventional end-to-end VPN tunnels impose an unavoidable toll on the network due to additional encapsulation, multiple encryption layers, and MTU pressure. Not only is this complex to implement, but the real user experience is also far from frictionless and takes a noticeable toll on the network speed.
QUIC-aware proxying, especially in the forwarded mode, reduces some of this overhead to optimize latency and per-packet processing. Plus, for integrated deployments (such as in Apple iCloud Private Relay), it can work in the background without any additional client-side installations. Although in other cases, such as Cloudflare WARP (MASQUE over HTTP/3), a minimal client is required.
Ultra-Low Latency CDNs: Media over QUIC Transport (MOQT) is an IETF work-in-progress protocol to help content delivery achieve a balance between performance and operational simplicity. Owing to QUIC’s strengths, no single lost packet on one stream would block other independent audio/video streams. You also have 0-RTT handshakes, which eliminate the reconnection handshake delay ( almost instant play without loading) for returning users.
During highly congested intervals, MOQT’s subgrouping allows the relay to adjust quality in real time based on the user's network, rather than buffering content. All these features, in addition to connection migration and superior multiplexing, make MOQT a promising use case for streaming platforms, e-sports, and video conferencing. Again, we would like to cite Cloudflare, which launched its MoQ relay network in over 330 cities as a testament to QUIC’s applicability.
Geo-restriction Bypass: QUIC’s built-in TLS 1.3 encrypts application data and almost all transport-layer headers, making it difficult for firewalls to snoop on or regulate web networking. This, along with MASQUE/CONNECT-UDP, lets a QUIC-aware proxy obfuscate censored data and blend it with normal HTTP/3 traffic. It’s one of the most VPN-esque features you can equip your proxy with and extremely useful in censorship-heavy regimes, such as China and Iran.
Implementation Challenges
- Double Congestion Control: This is primarily due to the tunneled mode, in which data packets are encrypted twice (QUIC over QUIC). This adds encapsulation overhead and reduces the effective MTU for applications. On top of that, both layers running separate congestion control mechanisms ultimately increase resource consumption.
- Connection Tracking: Unlike TCP, tracking and managing a QUIC flow is inherently more complex because you can’t rely on the fixed 4-tuples anymore. This becomes more significant during NAT rebinding and connection migration, where a QUIC-aware proxy must effectively perform CID mapping, even if that means significantly higher compute.
- Compatibility: The only practical way for a good implementation is to support both modes simultaneously. This is because a connection always starts with a long-header handshake, which requires tunneled mode, even if a proxy operates in forwarded mode thereafter.
- UDP Throttling and Bans: Since it’s difficult to inspect and regulate QUIC packets, blocking UDP port 443 is a common practice among enterprise/government firewalls and legacy networking stacks. Here, the only option left is to fall back to TCP-based HTTPS, which undoes the purpose of a QUIC-based connection in the first place.
Navigating the Barriers to QUIC Proxy Adoption
For a TCP-based proxy infrastructure, adopting a QUIC-aware approach carries complexity and financial risks. Though most of these can be mitigated with specific optimization and carefully planned rollout, the following section still presents some friction points that one should address in advance.
- Support Boundaries: Though there are IETF’s standardized protocols for HTTP Datagrams, CONNECT-UDP, and CONNECT-IP, most present-day networks terminate HTTP/3 at the edge without providing a full client-to-target QUIC/MASQUE tunnel. In such cases, (legacy) TCP-based connections are re-established from the edge to the target.
- Reliability & Fallbacks: Since QUIC semantics do not support deep packet inspection, it’s practice for enterprise firewalls to block UDP ports 443. This means you can’t ride on QUIC alone and must maintain the TCP-HTTP/2 proxy stack alongside, similar to implementations in Chrome and iCloud Private Relay.
- Production Readiness Checklist: Here’s the bare minimum one should verify before going into production with QUIC-aware proxying:
- Support for finalized MASQUE and HTTP/3 standards
- Ensure endpoint support for the Capsule-Protocol header
- Validate client and proxy library compatibility
- Test connection migration and TCP-HTTP/2 fallback
- Support for qlog/qvis
- Infrastructure Costs: QUIC proxying is generally more computationally expensive than TCP proxying due to additional encryption, user-space processing, per-packet handling, and CID-based connection management. In fact, Fastly’s benchmark study found that unoptimized QUIC attained just 40% of TLS 1.3 over TCP throughput. Though the same research achieved comparable results for optimized QUIC vis-a-vis TCP. It simply means that off-the-shelf QUIC can be impractical to deploy at scale without significant tuning and kernel-level optimization.
