Forward proxies have existed for decades. The classic HTTP CONNECT method lets a client ask a proxy to open a TCP tunnel to some destination, then pipe bytes back and forth. Corporate gateways, debugging tools like mitmproxy, and the first generation of privacy relays all leaned on it. The problem is that CONNECT only understands TCP. The modern internet runs an increasing share of its traffic over UDP: QUIC, HTTP/3, DNS, WebRTC media, and real-time gaming all live there. A proxy that cannot carry UDP cannot carry a growing fraction of what people actually do online.
MASQUE, which stands for Multiplexed Application Substrate over QUIC Encryption, is the IETF working group and family of specifications that fixes this. It defines how to tunnel UDP and even raw IP packets inside an HTTP/3 connection, using the same QUIC transport that carries normal web traffic. The result is a proxy that is hard to distinguish from an ordinary HTTPS session, and that can carry almost anything.
The Two Core Methods
MASQUE is really two related capabilities, defined in separate RFCs.
CONNECT-UDP (RFC 9298) lets a client ask the proxy to forward UDP datagrams to a named target. The client sends an extended HTTP request along the lines of "please relay UDP to target host and port," the proxy confirms, and from then on UDP payloads ride inside the QUIC connection as datagrams. This is what makes it possible to proxy a QUIC or HTTP/3 session through a relay without first downgrading it to TCP. The inner QUIC handshake runs end to end between your device and the real destination; the proxy only sees encrypted datagrams it is forwarding.
CONNECT-IP (RFC 9484) goes a layer lower. Instead of forwarding UDP to a single target, it tunnels full IP packets. This turns a MASQUE proxy into something closer to a VPN concentrator, capable of carrying arbitrary protocols, with the routing and address assignment negotiated over HTTP. It is the foundation for VPN products that want to ride on standard web infrastructure rather than custom ports that firewalls love to block.
A MASQUE tunnel looks like an HTTPS connection to port 443 because that is exactly what it is. Network operators that block obvious VPN ports cannot single it out without blocking the web. This is the same blending logic that domain fronting once relied on, achieved through a standardized protocol rather than a trick.
QUIC Datagrams Are the Enabling Piece
MASQUE could not exist on top of TCP. It depends on a QUIC extension (RFC 9221) that adds an unreliable datagram frame to a protocol that is otherwise reliable. Normal QUIC streams retransmit lost data and deliver it in order, which is exactly wrong for tunneling UDP. If you wrap a real-time voice packet in a reliable stream, a single lost packet stalls everything behind it, the problem known as head-of-line blocking.
QUIC datagrams skip retransmission and ordering. A lost inner packet is simply lost, which is what UDP applications already expect and handle. This lets a MASQUE proxy forward latency-sensitive traffic without adding the lag that a TCP-based tunnel would. If you want the deeper background on the transport, our explainer on QUIC and HTTP/3 security covers the handshake and encryption model that MASQUE inherits.
The Two-Hop Architecture
The privacy property people actually care about does not come from MASQUE alone. It comes from chaining two proxies operated by different parties. This is the design behind iCloud Private Relay and similar relay networks.
| Hop | What it sees | What it cannot see |
|---|---|---|
| Ingress proxy | Your real IP address and that you are a paying account | Which website you are visiting (the inner connection is encrypted to the egress) |
| Egress proxy | The destination you are connecting to | Your real IP address (it only sees the ingress proxy) |
Neither hop holds both halves of the picture. The first relay knows who you are but not where you are going. The second knows where you are going but not who you are. The privacy depends entirely on those two operators not colluding and not being run by the same entity. This is a real assumption, not a mathematical guarantee, and it is worth being clear-eyed about. A two-hop relay raises the cost of linking identity to activity; it does not make the link cryptographically impossible the way an onion network with three independent relays aims to.
MASQUE moves the bytes. The privacy comes from who operates the hops and whether they can be made to talk to each other.
How MASQUE Compares to the Alternatives
MASQUE is not the only privacy-preserving relay design, and it solves a different problem than the others.
- Oblivious HTTP. OHTTP hides the client's identity from a server for single, stateless requests using a relay and a gateway plus encapsulation. It is built for one-shot messages like telemetry or safe-browsing lookups, not for tunneling a live connection. MASQUE carries ongoing, bidirectional sessions.
- Tor. Onion routing uses three relays and layered encryption for stronger anonymity against a global adversary, at a real cost in latency. MASQUE relays are faster and operated by a known commercial party, which is a different trust model: you are trusting Apple or Cloudflare or Fastly rather than a volunteer network.
- Traditional VPNs. A single-hop VPN sees both your identity and your destination. The two-hop MASQUE design exists precisely to split that knowledge, so no single operator can build a profile of you.
What MASQUE Does Not Protect
A few honest limits are worth stating plainly, because relay marketing tends to gloss over them.
MASQUE hides your IP from the destination and splits trust across two operators, but it does nothing about what you reveal at the application layer. If you log in to an account, the destination knows who you are regardless of how your packets arrived. Browser fingerprinting still works against you. And traffic-analysis adversaries who can watch both ends of the relay can still attempt correlation based on timing and packet sizes, the same traffic-analysis weakness that affects every low-latency relay.
MASQUE is infrastructure, not a complete threat model. It is a strong building block for hiding network-level identity, and its standardization means we will see it in more products: privacy VPNs, in-browser relays, and corporate tools that want to carry UDP through a single hardened endpoint. What it gives you depends entirely on how the hops above it are arranged.
Where This Fits in a Privacy Stack
Network-layer relaying answers one question: who can see your IP address and your destinations. It does not answer who can read your messages. Those are separate layers, and a serious setup addresses both. Transport relaying like MASQUE protects metadata about your connections; end-to-end encryption protects the content of your communication. For a fuller map of how these pieces stack, our guide to building a privacy stack in 2026 walks through the layers in order.
At Haven we treat content encryption as our job and network-layer privacy as a complementary tool you bring. Your messages are encrypted end to end before they ever reach the network, so whatever path your packets take, the contents stay sealed. A relay like MASQUE protecting your IP address and a messenger protecting your message bodies are solving different problems, and the strongest posture uses both.