Imagine a familiar post office discovering that its letter counter can also organize a freight terminal. The address system still works. The paperwork still looks familiar. But the service can now arrange transport for much more than letters.
Something similarly surprising is happening with HTTP. The MASQUE protocol family lets HTTP clients request tunnels that carry UDP traffic or IP packets through a cooperating proxy. The protocol you associate with loading a webpage becomes part of the machinery for carrying other network traffic.
The interesting question is how it does that without forcing every message to behave like a reliably delivered document.
What is MASQUE?
MASQUE stands for Multiplexed Application Substrate over QUIC Encryption. It is a family of HTTP proxying mechanisms, developed in the IETF, rather than a single new transport protocol that replaces everything beneath it.
Its core building blocks include CONNECT-UDP, standardized in RFC 9298 in 2022, and CONNECT-IP, standardized in RFC 9484 in 2023. Together with HTTP Datagrams, they extend the kinds of traffic that HTTP-based proxying can carry.
Think of the proxy as a transfer terminal. A client requests a service, the proxy accepts an authorized request, and traffic travels through the resulting association. Both ends need the appropriate support; an ordinary website does not become a network tunnel just because it speaks HTTP.
The clever extension to an old idea
HTTP already has a CONNECT method. In its traditional form, it asks a proxy to establish a TCP tunnel to a destination. That is useful, but TCP’s reliable byte-stream service is not the same service as UDP or IP packet forwarding.
MASQUE expands that toolbox:
| Mechanism | What the client requests | What it carries |
|---|---|---|
| Traditional CONNECT | A TCP tunnel through an HTTP proxy | A stream of bytes |
| CONNECT-UDP | A UDP association with a target host and port | UDP payloads |
| CONNECT-IP | An IP tunnel, potentially constrained by policy | IP packets |
The distinction between the last two rows matters. CONNECT-UDP forwards UDP payloads and the proxy constructs outgoing UDP datagrams. CONNECT-IP carries packets at the IP layer, allowing broader tunneling use cases, including VPN architectures.
Neither requires the client to translate a game’s messages into HTML. HTTP provides the request framework and association; the tunneled data remains network traffic.
Follow one game update through the tunnel
Suppose a configured MASQUE client carries a game’s UDP flow through an HTTP/3 proxy. This is an illustrative journey, not a benchmark or a claim about a particular game.
- Request the route. The client establishes an encrypted HTTP/3 connection to the proxy and requests a CONNECT-UDP association for the game server’s host and port. The proxy decides whether to accept it.
- Package the update. The client places a UDP payload into an HTTP Datagram associated with that request. When negotiated, HTTP/3 carries it using a QUIC DATAGRAM frame inside the encrypted QUIC connection.
- Forward at the terminal. The proxy receives the data and sends the payload to the game server in an outgoing UDP datagram. The server can receive ordinary UDP; it does not need to implement MASQUE for this arrangement.
- Bring the reply back. The proxy receives the server’s reply and conveys its payload through the association to the client. Separate associations can share the outer HTTP/3 connection while retaining their own identities.
The target-facing UDP headers are not simply the original headers preserved unchanged. That is one reason UDP proxying and IP tunneling are separate mechanisms.
Our UDP explainer provides the foundation: datagrams preserve message boundaries, while delivery and ordering guarantees must come from elsewhere if an application needs them.
The surprising ingredient: QUIC can carry unreliable data
QUIC is often introduced through its reliable streams. HTTP/3 maps HTTP onto QUIC, which itself runs over UDP. But the QUIC DATAGRAM extension adds a different option: messages whose contents are not retransmitted by QUIC when lost.
That makes a useful combination possible. Reliable streams can carry control information; unreliable datagrams can carry data for which timeliness matters. Both can share an encrypted connection.
For a game-state update, insisting on recovering an old position may be less useful than receiving a fresh one. Whether to recover a loss remains a decision for the protocol or application inside the tunnel.
Unreliable does not mean unencrypted. It also does not mean unconstrained sending: the basic QUIC DATAGRAM model uses the connection’s congestion controller. Loss and congestion still affect performance.
There are multiple ways to convey HTTP Datagrams. When QUIC DATAGRAM transport is unavailable or undesirable, the Capsule Protocol can carry them reliably, including over HTTP versions that use TCP. That changes delivery behavior and can reintroduce waiting behind lost data. “MASQUE” alone does not tell you which transport mode a deployment actually uses.
UDP inside HTTP over QUIC over UDP?
Yes. It sounds like a networking joke, but each layer has a job.
The inner UDP flow represents communication with the target application. The outer UDP packets carry the QUIC connection between the client and proxy. HTTP Datagrams identify which tunneled association the data belongs to, while QUIC supplies the protected transport.
The inner destination and the outer destination are different. Looking only at the outer packet tells you where the tunnel goes, not necessarily where the traffic emerging from it will go next.
Who can see what?
In a simple, single-proxy CONNECT-UDP deployment, the visibility looks approximately like this:
| Participant | What remains visible |
|---|---|
| Observer on the client-to-proxy network path | The proxy’s address and traffic metadata such as timing and size; the protected tunnel contents are encrypted |
| MASQUE proxy | The client’s connection and requested target; payload contents unless separately protected end to end |
| Target server | The proxy’s outgoing network address and whatever identifying information the application supplies |
The proxy therefore becomes a trust point. Application encryption, such as a separate end-to-end secure connection carried through the tunnel, can protect content from the proxy. Accounts, cookies, and application identifiers can still identify a user to the destination.
More elaborate architectures can distribute trust across multiple relays. Those privacy properties depend on the arrangement and its assumptions; the MASQUE name by itself does not establish anonymity.
Where MASQUE already appears
Cloudflare’s current documentation describes the Cloudflare One Client, formerly WARP, using WireGuard or MASQUE to establish a proxy tunnel for device traffic. That is a concrete deployment of these ideas in an endpoint client.
It also shows why MASQUE belongs in a modern networking vocabulary: HTTP extensions now participate in systems that carry internet and private-network traffic, well beyond individual webpage requests.
Three details worth checking in a real deployment
- Transport and network policy. HTTP/3 uses QUIC over UDP. Allowing TCP port 443 does not automatically allow UDP port 443, and supported fallback behavior depends on the implementation.
- Packet size. Encapsulation consumes space. Tunnel MTU and path-MTU handling matter, especially when carrying whole IP packets. There is no universal overhead figure or tunnel MTU that fits every configuration.
- The proxy’s actual job. Authentication, allowed targets, routing, traffic handling, and observability need configuration. A proxy server remains a working intermediary, with processing costs and a position on the network path.
MASQUE’s most interesting achievement is the reuse of familiar infrastructure for a broader task: HTTP negotiates the passage, while suitable transport mechanisms carry the traffic. The post office still handles the paperwork. It has learned how to run a freight terminal.
References and further reading
- IETF MASQUE Working Group — scope and core proxying mechanisms.
- RFC 9298: Proxying UDP in HTTP — CONNECT-UDP and target associations.
- RFC 9484: Proxying IP in HTTP — CONNECT-IP, packet handling, and MTU considerations.
- RFC 9297: HTTP Datagrams and the Capsule Protocol — datagram associations and reliable carriage.
- RFC 9221: An Unreliable Datagram Extension to QUIC — unreliable delivery, encryption, and congestion control.
- RFC 9000: QUIC and RFC 9114: HTTP/3 — the underlying transport and HTTP mapping.
- RFC 9614: Partitioning as an Architecture for Privacy — proxy visibility and privacy assumptions.
- Cloudflare One Client documentation — an example of deployed MASQUE support.