Why proxied traffic felt slow

Local proxy mode in a SASE client usually means a trade-off: security at the cost of speed. When traffic is routed through a local SOCKS5 or HTTP proxy, users often experience sluggish browsing, slow file transfers, and choppy video calls. In many cases, the proxy itself gets blamed, even when the real constraint is architectural.

Cloudflare ran into this exact problem while building the client for its Cloudflare One platform. The client’s proxy mode had to bridge two different networking layers. Incoming application traffic is Layer 4 (L4) TCP, but the underlying tunnel was built on WireGuard, a Layer 3 (L3) protocol. To move L4 streams into an L3 tunnel, the client relied on smoltcp, a Rust-based user-space TCP stack designed primarily for embedded systems.

That conversion worked, but it imposed real limits. smoltcp lacks modern TCP features, and the Cloudflare edge had to reverse the conversion—turning L3 packets back into L4 streams. For users on media-heavy sites, where browsers open dozens of concurrent connections, the added translation overhead showed up as higher latency and longer load times, even on fast connections.

Moving to direct L4 proxying over QUIC

The fix was to remove the L3 conversion step entirely. Cloudflare rebuilt the client’s proxy mode to use QUIC streams for direct L4 proxying, dropping WireGuard from the proxy path altogether. The client already used MASQUE (which builds on QUIC) for IP packet proxying; now it also leverages QUIC streams for L4 traffic.

By using HTTP/3 CONNECT (per RFC 9114), traffic stays at the application layer. When a browser sends a SOCKS5 or HTTP request to the client, the data is encapsulated directly into a QUIC stream instead of being packetized into L3 format.

This change brings three concrete benefits:

  • No more smoltcp: Removing the L3 translation layer eliminates IP packet handling and the TCP stack limitations of smoltcp.
  • Native QUIC advantages: Flow control and congestion control are now handled by QUIC’s transport layer rather than a user-space TCP implementation.
  • Tuning flexibility: Both the client and Cloudflare’s edge can adjust QUIC parameters to optimize performance as needed.

In Cloudflare’s internal tests, download and upload speeds roughly doubled, and latency dropped noticeably.

Where the improvements matter most

Faster proxying helps broadly, but three use cases stand out.

Coexistence with third-party VPNs: When a legacy VPN or a second SASE deployment is required for on-prem resources or compliance, proxy mode is the standard way to secure web traffic without a full tunnel. This update keeps that layered setup from degrading user experience.

High-bandwidth application partitioning: Proxy mode is often used to steer only browser traffic through Cloudflare Gateway while leaving the rest of the OS on the local network. With the performance ceiling removed, high-definition streaming and large dataset transfers can run through the proxy without noticeable slowdown.

Developers and power users: Those relying on the SOCKS5 secondary listener for CLI tools or scripts will see faster remote API calls and data transfers, matching the low-latency performance of Cloudflare’s global network.

Enabling the updated proxy mode

The improved proxy mode is available from client version 2025.8.779.0 on Windows, macOS, and Linux. To turn it on:

  1. Log in to the Cloudflare One dashboard.
  2. Go to Teams & Resources > Devices > Device profiles > General profiles.
  3. Edit or create a profile, then set Service mode to Local proxy mode and Device tunnel protocol to MASQUE.

You can verify the active protocol on a client machine with a terminal command:

For detailed setup instructions, refer to Cloudflare’s documentation on enabling local proxy mode.