

Agnė Matusevičiūtė
Last updated on
2026-10-29
5 min read
AI Summary:
Choosing a proxy protocol starts with knowing what traffic your workload needs to carry. This guide compares MASQUE, SOCKS5, and HTTP CONNECT, explains why TCP-based proxies switch browsers from HTTP/3 to older HTTP versions, and shows how Oxylabs Residential Proxies support native HTTP/3 through MASQUE's CONNECT-UDP. It also covers performance trade-offs, setup requirements, and when each protocol is the right fit.
Most proxy setups still rely on TCP-based protocols. That is not inherently a problem: SOCKS5 and HTTP CONNECT remain dependable options for many web scraping and networking tasks. But modern websites increasingly use HTTP/3, which works differently from older HTTP versions. For some workflows, the proxy protocol can now affect more than connectivity – it can affect how naturally a client reaches the target.
The key question is not whether MASQUE replaces traditional proxies, but when its HTTP/3 support makes a practical difference.
HTTP/3 runs over QUIC, which uses UDP rather than TCP. When a proxy only supports TCP tunneling, the browser uses HTTP/2 or HTTP/1.1 to reach the target instead. The request may still succeed. Yet the connection no longer follows the same path a modern browser could use directly.

MASQUE (Multiplexed Application Substrate over QUIC Encryption) is not one single protocol but a family of internet standards for proxying traffic over HTTP. It includes:
CONNECT-UDP (RFC 9298) for carrying UDP traffic;
CONNECT-IP (RFC 9484) for carrying full IP packets;
HTTP Datagrams (RFC 9297), which both rely on.
For Oxylabs' Residential Proxies, we built in CONNECT-UDP because it's the piece that carries QUIC and HTTP/3, the protocols modern browsers and websites use.
MASQUE gives proxy users a way to keep that modern path available. With Oxylabs' Residential Proxies, compatible clients can send native UDP traffic through residential exit nodes and maintain an end-to-end QUIC/HTTP/3 connection to the destination. This makes MASQUE particularly relevant for browser-based scraping of modern, protocol-sensitive sites. The approach has already proven its viability: Google has built Chrome's IP Protection feature on MASQUE.

An RFC – short for Request for Comments – is a published technical specification used to document internet standards. RFC 9298 defines CONNECT-UDP, including how an HTTP client can establish a UDP tunnel through a proxy.
Here's how the three compare, depending on whether a workload needs standard TCP proxying or benefits from native UDP and HTTP/3 support.
| Feature | MASQUE | SOCKS5 | HTTP CONNECT |
|---|---|---|---|
| Connection to the proxy | Typically HTTP/3 over QUIC/UDP | TCP | Usually TCP (can also run over HTTP/2 or HTTP/3) |
| Can carry UDP traffic? | Yes | Supported through UDP ASSOCIATE, but varies by client and setup | No |
| Can preserve native HTTP/3 to a target? | Yes | Possible with UDP ASSOCIATE, but needs a compatible client and provider | No, when using a TCP tunnel |
| Best suited to | HTTP/3, UDP-based traffic, modern browser automation | General-purpose TCP traffic and non-web tools | Standard HTTPS proxying |
| Common tooling support | Newer and requires MASQUE-compatible software | Broad | Broad |
| Example use case | Browser-based scraping of HTTP/3-enabled sites | SSH, TCP applications, flexible proxy routing | Conventional HTTPS scraping |
MASQUE is not simply a newer alternative to SOCKS5. It addresses a gap that becomes more visible as HTTP/3 adoption grows.
Browsers such as Chrome, Safari, Firefox, and Edge can use HTTP/3. Many major websites also support it, including a large share of sites served through Cloudflare’s network. If a browser connects directly to one of those sites, it may use QUIC and HTTP/3 automatically. But if that same browser is routed through a conventional TCP proxy, it generally cannot send QUIC through that TCP tunnel.
Instead, the browser typically uses HTTP/2 or HTTP/1.1 over TCP for the target connection. That switch is often invisible. A page still loads, a scraper still receives data, and the workflow may look normal from the outside. But the transport behavior is different.
For scraping teams, that difference can matter. Websites can evaluate more than page requests and IP addresses. They may also look at session behavior: browser characteristics, TLS signals, request patterns, and the network protocol used to establish the connection. MASQUE helps reduce one potential mismatch.
Browser fingerprinting involves many layers, so a proxy protocol is one piece of the picture, not all of it. But it's an important piece: MASQUE keeps the connection behavior consistent with what a modern browser is designed to do. That is a meaningful advantage when collecting data from sites that actively use HTTP/3 and evaluate transport-level behavior.
For a broader explanation of why the shift matters, see why HTTP/3 matters for web scraping & Residential Proxies.
Oxylabs' Residential Proxies use CONNECT-UDP to give compatible clients a UDP path through residential exit nodes. Because the QUIC connection is encrypted end to end between your client and the target, the proxy forwards it without reading or changing it. The content reaches the website exactly as your client sent it.
MASQUE can also be useful for UDP-based workflows beyond web scraping, including:
DNS queries;
WebRTC;
SIP and other real-time protocols.
Whether MASQUE is the right tool depends on the application: if the workload only makes standard TCP-based HTTP or HTTPS requests, a conventional residential proxy endpoint is generally simpler.
Oxylabs’ MASQUE endpoint: QUIC on UDP port 50000;
Outbound UDP access in your environment;
A MASQUE-compatible client (or a local tunnel in front of your browser).
Full configuration details are in the documentation.
Explore Oxylabs' Residential Proxies
175M+ ethically sourced IPs built for the highest reliability.

MASQUE's performance depends on the target, client, proxy implementation, network conditions, and whether HTTP/3 is actually available. It can navigate a key limitation of routing modern traffic through a TCP-only proxy path.
TCP guarantees that data arrives in order. That reliability matters, but a single lost packet can delay data that arrives later. HTTP/2 allows multiple streams, but because they share a TCP connection, packet loss can still affect unrelated streams. QUIC handles streams differently. When packet loss occurs, it can delay only the affected stream rather than holding up every stream on the connection.
Connection setup is simpler, too. With TCP, the transport handshake has to finish before the TLS handshake can start. QUIC combines both into a single round trip, and returning clients can often send data right away with 0-RTT resumption.
RFC 9298 highlights an important caveat: proxying QUIC can create multiple layers of congestion control, so MASQUE should not be treated as a universal speed upgrade. But using HTTP/3 for the outer proxy connection avoids adding TCP’s own recovery behavior beneath the proxied UDP traffic when HTTP Datagrams are used.
In short, MASQUE preserves QUIC's strengths wherever your use case calls for it.
SOCKS5 remains one of the most flexible proxy protocols available. It is not limited to HTTP traffic, which makes it useful when a workflow includes tools outside a standard web scraping stack. For example, SOCKS5 can route TCP connections from SSH clients, database tools, command-line utilities, and custom applications. If a tool needs a straightforward TCP proxy and already supports SOCKS5, there's no reason to introduce a newer protocol.
SOCKS5 also defines a UDP ASSOCIATE feature. However, support varies between proxy services and client applications, and it isn't designed specifically to preserve an HTTP/3 connection through an HTTP-based proxy path.
Choose SOCKS5 when broad TCP compatibility matters more than native HTTP/3. It is especially practical for SSH and other non-browser workflows.
HTTP CONNECT is the conventional choice for HTTPS proxying. The client asks the proxy to open a TCP connection to a target, then performs its own encrypted TLS connection through that tunnel.
For standard HTTPS scraping, this model is mature, broadly supported, and easy to use with existing libraries and tools. It remains the sensible option when a workflow does not need UDP, QUIC, or HTTP/3.
Its trade-off is straightforward: an HTTP CONNECT tunnel is TCP-based. It can securely carry conventional HTTPS traffic, but it does not carry a browser’s native QUIC/HTTP/3 connection to the target.
The best proxy protocol depends on what the application actually needs to send.
Choose MASQUE / CONNECT-UDP for browser-based scraping of modern HTTP/3-enabled sites, native QUIC connectivity, or UDP-based workloads. It is the future-ready option when preserving a modern browser transport path matters;
Choose SOCKS5 for flexible TCP proxying, especially when working with SSH, command-line tools, or other applications beyond HTTP;
Choose HTTP CONNECT for conventional HTTPS scraping that runs over TCP and does not need native HTTP/3.
SOCKS5 and HTTP CONNECT remain the right fit for TCP-only workflows. But the web is moving toward HTTP/3, and proxies need to be able to carry that traffic without quietly changing it along the way. For scraping modern, HTTP/3-enabled sites, MASQUE is the option built for where the web is going.
The best way to see the difference is to test it. Try Oxylabs Residential Proxies with MASQUE support on a modern, HTTP/3-enabled site, and use our documentation to get set up.
SOCKS5 can relay UDP with its UDP ASSOCIATE command, but both the client and the proxy have to support it. Most browsers don't send QUIC through a configured SOCKS5 proxy. They use HTTP/2 instead.


Donata Norkūnaitė
2026-10-21


Shinthiya Nowsain Promi
2026-10-14


Shinthiya Nowsain Promi
2026-09-29
Get the latest news from data gathering world