Reach UDP: carrying the traffic that tunnels usually droperic

Ask most proxies to carry a file download and they're flawless. Ask them to carry a voice call, a video meeting, a game, or anything else built on UDP, and things get quiet — sometimes literally. TCP is the happy path for tunnels; UDP is the one that gets dropped, blocked, or silently degraded. That's a problem, because the traffic people most notice breaking — calls, Teams, games — is exactly the UDP traffic.

Reach now carries UDP. The interesting part isn't "we added UDP support"; it's how, because there is no single UDP transport that is simultaneously fast, firewall-friendly, and hard to block. So instead of picking one, Reach picks the right one per connection.

Three transports, one selector

Under the hood there's a shared UDP layer with three pluggable transports:

• Direct — the datagram goes straight out, no tunnel. Right for LAN peers and, by default, for real-time media where latency is king.
• QUIC datagrams — UDP carried inside a QUIC connection (ALPN reach-udp), with a short control stream that carries your key. Fast and modern where the network allows it.
• UDP-over-WebSocket — datagrams wrapped in a WebSocket to the gateway. Slower than QUIC, but it looks like ordinary web traffic, which is what you want when the network is hostile.

In front of them sits a small classifier and policy engine. The classifier buckets each flow — LAN, Media (STUN/TURN, the common RTP ranges, Teams), or Other. The policy then decides: LAN stays direct; media stays direct for latency (or rides WebSocket when you've asked Reach to stay disguised); everything else prefers QUIC, falls back to WebSocket, and only then gives up. Pick the "slow/disguise" connection mode and tunnelled UDP deliberately steps down to the most resilient option. One flow can be direct while another is relayed — the selector is per-connection, not a global switch.

Where it terminates

Tunnelled UDP has to exit somewhere, and that turned out to dictate the architecture. Serverless platforms can't egress raw UDP (we tried, historically, and reverted it). So tunnelled UDP terminates on a small Go sidecar — reach-relay — running on the VM gateways, which dials the real target itself and relays the datagrams back. Each gateway advertises its UDP capabilities in its /meta document, so the client knows whether a given gateway can do udp-relay, udp-quic, or neither, and routes accordingly. QUIC, because it bypasses the usual web front door, gets its own DNS-only endpoints and a dedicated firewall opening.

On the client side, the desktop gained SOCKS5 UDP ASSOCIATE — the standard way for an application to hand UDP to a proxy — wired into the same adaptive selector. So a UDP-capable app points at Reach's local SOCKS proxy and its datagrams flow through whichever transport the policy chose.

The honest caveats

Per our usual rule — the trade-offs, stated plainly:

• Desktop today; mobile is coming. The desktop client ships the full adaptive UDP path. Mobile needs a from-scratch native "protected socket" hook (so the VPN doesn't loop its own traffic), which is a separate build effort in progress — not shipped yet.
• QUIC does not help in China. The Great Firewall throttles and blocks UDP to foreign IPs, QUIC included. There, the resilient path is UDP-over-WebSocket in disguise mode — which is exactly why the selector exists rather than a single "use QUIC" flag.
• Rolling out across the fleet. The UDP sidecar and QUIC are live on most of our gateways, not yet every one. The client degrades gracefully: no UDP transport available on a gateway means it falls back (and, worst case, the app's own direct path), never a hard failure.
• Metering. Tunnelled UDP isn't byte-metered yet — a deliberate interim choice while the design settles.

The point of all this machinery is a simple outcome: the real-time traffic that used to be the first casualty of turning on a tunnel now has a way through — and Reach spends its effort choosing the right way, connection by connection, instead of forcing one and hoping.