Why SOCKS5 UDP Fails Through Most Proxies

If you need QUIC, HTTP/3, DNS, WebRTC or a game protocol through a proxy, you need SOCKS5 UDP ASSOCIATE. It's in the spec. Most gateways advertise it. A fair number don't actually carry traffic.
The failure is quiet. Handshake succeeds, gateway hands back a relay address, your client starts sending datagrams, nothing comes back.

VaultProxies test UDP per pool and per port rather than making one claim for their whole catalogue, and they shared their measurements with us. They're worth walking through, because these failure modes are the same wherever you buy.

How it actually works

Worth understanding, because it explains every way it breaks.

1. You open a TCP connection to the proxy and authenticate as normal.
2. You send UDP ASSOCIATE over that TCP connection.
3. The proxy replies with an address and port to send datagrams to. Usually not the port you connected on.
4. You send UDP datagrams there, each wrapped in a small SOCKS5 header naming the real destination.

5. The TCP connection has to stay open. Close it and the association dies.
   
   Step 5 catches people constantly. That TCP socket looks idle, so a connection pool or a timeout or some tidy-looking cleanup code closes it, and the UDP path stops working with no error anywhere.

   
   Step 3 catches firewalls. The relay port is usually ephemeral, and the client sends first, so there's no outbound packet for a stateful firewall to build a conntrack entry from. Default-deny inbound rules drop the whole thing.

Three ways it fails

No support at all. The handshake fails outright, or the association succeeds and no datagram ever comes back. When VaultProxies brought their mobile pool online they swept every open port on its gateway. A handful accepted authentication and then died at the ASSOCIATE step. The rest never finished the SOCKS5 handshake. They publish that pool as TCP only, because that's what it is.
Works, but only on one port. Gateways that multiplex HTTP and SOCKS5 across several ports don't necessarily carry UDP on all of them. On the VaultProxies ISP pool, six associations out of six succeeded on the HTTP-labelled port against five out of six on the SOCKS port. The HTTP port is the better UDP endpoint there, which is not something you'd guess from the numbering.
Works, but only to some destinations. This one produces false bug reports. Their EU pool carries UDP fine to well-known ports, and QUIC on 443 round-trips reliably, but an echo test against an arbitrary high port gets nothing back. The exits filter destination ports. If you test with a UDP echo server on 4444 and conclude UDP is broken, you're wrong. Your actual QUIC traffic would have worked.

Testing it in one command

curl speaks both SOCKS5 and HTTP/3, which is enough:

curl --socks5-hostname user:pass@gateway:1080 \
     --http3-only -sS -o /dev/null -w '%{http_version}\n' \
     https://cloudflare-quic.com/

If it prints 3, UDP is carrying real traffic end to end. Anything else and it isn't.
Use a real HTTP/3 endpoint rather than an echo server on an unusual port. Otherwise you're testing the exit's port filtering instead of the proxy's UDP support, and those are different problems with different answers.
One detail: use --socks5-hostname, not --socks5. The first sends the hostname to the proxy to resolve. The second resolves locally, which leaks DNS and pins you to an IP the exit might route differently anyway.

What to ask a provider

Don't ask "do you support SOCKS5 UDP". Almost everyone says yes, because their gateway advertises the command.
Ask which pools carry UDP and on which ports. Ask whether exits filter destination ports. Ask what they measured and against what.
A provider who has tested this will answer per pool and per port, because that's the shape the answer really has. A provider who hasn't will give you one answer for the whole catalog.

VaultProxies publish theirs, which is why we point readers at them: residential, ISP, datacenter and IPv6 all carry UDP, and mobile does not, for the reason described above. A provider willing to publish the pool that doesn't work is telling you something about the pools that do.
 

VaultProxies publish UDP support per pool, including the pools where the answer is no. BitBrowser readers save 10% at VaultProxies with code BITBROWSER10.