MASQUE proxy: how HTTP/3 tunnels UDP and IP traffic

Originally published on proxymint.

A MASQUE proxy tunnels UDP and IP traffic over HTTP/3 with CONNECT-UDP and CONNECT-IP. How it works, who runs it today, and what it means for proxy users.

TL;DR

• A MASQUE proxy tunnels UDP and IP over HTTP. It uses Extended CONNECT, usually over HTTP/3 on QUIC, so the site sees the proxy's IP and the network sees HTTPS on port 443.
• Three RFCs define it. RFC 9297 adds HTTP Datagrams and capsules, RFC 9298 defines CONNECT-UDP, and RFC 9484 defines CONNECT-IP for full IP tunnels.
• It already runs at scale. iCloud Private Relay and the Cloudflare WARP and 1.1.1.1 apps run on MASQUE, and Apple publishes the Private Relay egress ranges.
• HTTP and SOCKS5 proxy users stay on TCP. Chrome uses SOCKS5 only for TCP requests and tunnels HTTP proxies through CONNECT, so a proxied browser speaks HTTP/2, not HTTP/3.

Key takeaways

• Pick the method by what must cross the tunnel. TCP web requests need HTTP CONNECT or SOCKS5; QUIC, DNS or WebRTC need CONNECT-UDP; a full VPN needs CONNECT-IP.
• Use two hops when the operator must not see both ends. Nested CONNECT-UDP with non-colluding operators splits who from where.
• Lock down a CONNECT-UDP gateway. Require authentication, refuse localhost and link-local targets, and keep congestion control on.
• Check the negotiated protocol once. Run the Cloudflare trace endpoint through the proxy and read the http= line before tuning fingerprints.
• Treat relay egress as shared. Private Relay and similar ranges carry many users per IP, so use published lists and tokens, not per-IP limits.

Read the full guide on proxymint, with the commands, tables and sources.