Blog

Does SOCKS5 Support UDP? Yes, but Few Tools Use It

Does SOCKS5 support UDP? The protocol does, through UDP ASSOCIATE. Many servers and clients do not. Here is how it works and what to check.

6 min read

Does SOCKS5 support UDP? On paper, yes. The SOCKS5 protocol (RFC 1928) has a command called UDP ASSOCIATE that relays UDP datagrams. In practice, many SOCKS5 servers do not implement it, and most clients never send it.

So "SOCKS5 supports UDP" is true for the protocol and often false for the proxy you bought. You have to check the server, and you have to check the app.


Key takeaways

  • RFC 1928 defines three commands: CONNECT, BIND and UDP ASSOCIATE. UDP rides on the third one.
  • A server does not have to implement UDP ASSOCIATE. Many reply "Command not supported" (code 0x07).
  • Chrome and Firefox cannot send UDP through a SOCKS5 proxy. curl cannot send HTTP/3 through one.
  • A server can accept the request and still drop your datagrams.
  • "UDP proxy" can also mean udpxy or MASQUE. They are different things.

How UDP ASSOCIATE works

SOCKS5 starts with a TCP connection to the proxy. The client logs in, then sends a command. For UDP, the command is UDP ASSOCIATE (value 0x03).

Here is the flow.

client                          proxy                  target
  |-- TCP connect + login ------>|
  |-- UDP ASSOCIATE ------------>|
  |<-- reply: BND.ADDR/BND.PORT -|
  |                              |
  |== UDP datagram + SOCKS hdr =>|== plain UDP ========>|
  |<= UDP datagram + SOCKS hdr ==|<= plain UDP =========|
  |                              |
  |-- TCP connection closes ---->| relay ends

The steps in plain words.

  1. The client opens a TCP connection and authenticates.
  2. The client sends UDP ASSOCIATE. It puts its own expected address and port in the request, or all zeros if it does not know them yet.
  3. The server replies with BND.ADDR and BND.PORT. That is the relay address. The RFC says this is where the client must send its UDP messages.
  4. The client wraps each datagram in a small SOCKS UDP header. The header holds a reserved field, a fragment number, the target address type, the target address and the port. Then the data follows.
  5. The server unwraps the datagram, sends it to the target, and wraps any reply the same way.

The TCP connection is the control line. It must stay open. The RFC says the UDP association ends when the TCP connection it came from ends. If your app drops that TCP connection, the relay stops.

The fragment field is optional. A value of 0 means the datagram is standalone. A server that does not support fragments must drop any datagram with a different value.

Details are in RFC 1928.


What people mean by "UDP proxy"

The search term covers three unrelated things.

  • SOCKS5 UDP. The one in this post. A general proxy for UDP traffic from any app that supports it.
  • udpxy. A small program that turns UDP multicast streams into HTTP streams. It is used for IPTV. It is not a SOCKS proxy and it is not for rotating IPs.
  • MASQUE / CONNECT-UDP. RFC 9298 defines a way to proxy UDP inside HTTP. It works over HTTP/1.x, HTTP/2 and HTTP/3. It needs an HTTP proxy that speaks it. It is a different protocol from SOCKS5.

Elusive proxies are SOCKS5 only, so the first meaning is the one that applies here.


Which clients can send UDP through SOCKS5

Most everyday tools cannot. Here is what the primary sources say.

  • Chrome: the Chromium docs say SOCKS5 "is only used to proxy TCP-based URL requests. It cannot be used to relay UDP traffic." So no QUIC and no WebRTC UDP through a SOCKS5 proxy. See also our guide to Chrome and SOCKS5 passwords.
  • Firefox: a Mozilla developer wrote "our SOCKS proxy layer does not support UDP traffic" (bug 1882018, closed as a duplicate of bug 1808692, "SOCKS implementation does not support UDP"). When we checked, bug 1808692 was still open.
  • curl: curl has no UDP relay through SOCKS. In issue 7533, the maintainer called it a feature nobody had implemented. A later comment says current builds report that HTTP/3 is not supported over a SOCKS proxy. More in HTTP/3 and QUIC over SOCKS5.
  • tun2socks: its SOCKS5 package has UDP ASSOCIATE built in. It is a tool that turns a network interface into SOCKS traffic, so it can carry UDP from apps that know nothing about SOCKS.
  • gost: as a client it can use relay=udp to send UDP through a SOCKS5 proxy. As a server it must be started with udp=true.

Some antidetect browsers and VPN-style apps also route UDP, but it depends on the product and the version. We could not verify specific ones, so check your tool's docs for "UDP" next to "SOCKS5".

The pattern is clear. Apps that speak SOCKS5 natively mostly use TCP only. For UDP you usually need a tool that works at the network level, or an app built for it.


Servers that do not implement it

RFC 1928 lists the three commands. It does not require a server to support all of them. The only thing it makes mandatory is authentication (GSSAPI required, username/password recommended).

So servers vary.

  • microsocks says plainly "TCP (no UDP at this time)".
  • Tor does not implement UDP ASSOCIATE. A 2014 bug fixed its answer to be a proper "command not supported" reply.
  • Dante supports it, but only if a rule allows it. See the error guide.
  • gost supports it, but it is off by default.

Providers often say "SOCKS5 supports both TCP and UDP" on a product page. That is a sentence about the protocol. It does not tell you the servers answer UDP ASSOCIATE. Ask, or test.


Why an "accepted" request can still fail

You send UDP ASSOCIATE. The server says success and gives you a relay address. Then nothing comes back. Common reasons.

  • The relay port is firewalled. The TCP port works, but the UDP relay port the server picked is blocked.
  • The relay address is wrong. The server may reply with an internal or 0.0.0.0 address. Your client has to use the proxy's public IP instead.
  • Source mismatch. The RFC says the relay must drop any datagram from a source IP other than the one recorded for the association. If your NAT changes the source, packets disappear.
  • The TCP control connection closed. The relay ends with it.
  • Wrong header. Missing the SOCKS UDP header, or a non-zero fragment byte, gets the datagram dropped.
  • The target blocks UDP, or the reply path is filtered.

To find out which one, see how to test SOCKS5 UDP.


UDP on Elusive

Every Elusive proxy is SOCKS5 with a username and password. Some of them support UDP through UDP ASSOCIATE. The catalog marks them, and you can filter for them. Not every proxy has it. On Static ISP, UDP is offered in the US, Canada, Germany, the UK and the Netherlands.

UDP matters for VoIP, WebRTC, games, DNS and HTTP/3 (QUIC). Pick a UDP-marked proxy in the catalog if your app needs one.


Common mistakes

Assuming a proxy supports UDP because it is SOCKS5. Check the listing or ask the provider.

Testing UDP in a browser. Chrome and Firefox will not send it. Use a tool that can.

Closing the TCP connection. The UDP relay ends with it.

Using socks5h and expecting it to change UDP. The h is about DNS lookups. Read socks5 vs socks5h.


FAQ

Does SOCKS5 support UDP?

The protocol does, through UDP ASSOCIATE in RFC 1928. A given server may not. Many return "Command not supported".

Does SOCKS4 support UDP?

No. SOCKS4 has CONNECT and BIND only. UDP ASSOCIATE is a SOCKS5 command.

Can Chrome send UDP through a SOCKS5 proxy?

No. The Chromium docs say SOCKS5 is only used for TCP-based URL requests and cannot relay UDP.

Is a UDP proxy the same as SOCKS5?

Not always. SOCKS5 UDP, udpxy (IPTV multicast) and MASQUE (UDP inside HTTP) are three different things.

How do I know if my SOCKS5 proxy supports UDP?

Ask the provider, and test it. A failed test often shows a reply code 0x07. See UDP ASSOCIATE command not supported.

Get a proxy for your profiles

SOCKS5 with a username and password, ready to paste as HOST:PORT:USER:PASS. Sticky IPs for up to 24 hours, Static ISP for 7 to 90 days, or Rotating by the GB.