SOCKS5 can carry UDP. The client opens a TCP connection to the proxy and sends the UDP ASSOCIATE command. The proxy answers with a relay address and port. The client then sends each datagram to that relay with a small header naming the real destination, and the proxy forwards it from its own address and wraps the replies the same way. The association lives as long as the TCP connection. Few SOCKS5 proxies actually do it: on 10 October 2026, 17 of 575 live public SOCKS5 proxies from our list relayed a real DNS query.
We tested this two ways that day. Our own proxy checker ran its UDP test on 692 public SOCKS5 proxies, and on 682 eight minutes later. Then our own script repeated the handshake byte by byte, to see why the others failed. The protocol facts below come from RFC 1928, the SOCKS5 standard.
How does SOCKS5 carry UDP?
In five steps, all defined by RFC 1928 (IETF, March 1996):
- The client opens a TCP connection to the proxy and agrees on a login method, as for any SOCKS5 request.
- It sends UDP ASSOCIATE, command
0x03. The request names the address the client will send from. A client that does not know it yet "MUST use a port number and address of all zeros". - The proxy answers with a relay. The reply's
BND.ADDRandBND.PORTgive "the port number/address where the client MUST send UDP request messages to be relayed". Many proxies answer0.0.0.0, which clients, ours included, read as the proxy's own address. - The client sends datagrams to the relay, each with a header in front. The proxy strips it, sends the data on, and puts the same header on every reply.
- The association ends with the TCP connection. The standard says so in one line: "A UDP association terminates when the TCP connection that the UDP ASSOCIATE request arrived on terminates".
The header on every datagram
The header in step 4 is short:
| Field | Size | What it holds |
|---|---|---|
| RSV | 2 bytes | Zero, reserved |
| FRAG | 1 byte | Fragment number; 00 for a whole datagram |
| ATYP | 1 byte | Address type: 01 IPv4, 03 domain name, 04 IPv6 |
| DST.ADDR | 4, 16 or 1+n bytes | Where the datagram should go |
| DST.PORT | 2 bytes | Its port |
| DATA | the rest | The original datagram |
For an IPv4 destination that is 10 bytes, and RFC 1928 tells clients to report that much less room for each datagram. Fragmentation is optional. A relay that does not support it "MUST drop any datagram whose FRAG field is other than X'00'".
The exchange on the wire
Here is the whole exchange against real public proxies on 10 October 2026, with every byte shown:
The third proxy shows the whole design working. It named its relay as 0.0.0.0, and the relay sat at the proxy's own address. Our DNS query went there with the header 00 00 00 01 08 08 08 08 00 35, which means IPv4 address 8.8.8.8, port 53. The answer came back with the same header and the addresses of example.com. After we closed the TCP connection, the same query got no answer.
Why does SOCKS5 UDP need a TCP connection too?
Because UDP has no connection to hang anything on. RFC 768 (IETF, August 1980) says of UDP that "delivery and duplicate protection are not guaranteed". So the TCP connection does the bookkeeping. It carries the greeting, the login and the ASSOCIATE request, and its life is the life of the relay.
The relay is quiet by design. RFC 1928 says it forwards a datagram "silently, without any notification to the requesting client", and that it "will drop datagrams it cannot or will not relay". It must also drop datagrams from any source address other than the client recorded for the association. A client therefore learns that UDP works only when an answer comes back. That is why every honest UDP test sends real traffic.
The standard names one way for an association to end: the end of the TCP connection. A Stack Overflow question from 2018 asks whether SOCKS5 has a timeout for UDP. RFC 1928 sets no idle timeout for an association; its only timer is for putting fragments back together.
How many SOCKS5 proxies actually relay UDP?
About three in a hundred, among public ones. On 10 October 2026 at 19:44 UTC, we took the 400 SOCKS5 entries of our free proxy list with the best uptime and the first 400 in its default order, 692 distinct proxies. Our checker sent each a real DNS query through UDP ASSOCIATE and counted a yes only when a DNS answer came back. 575 answered as SOCKS5, and 17 relayed the query, 3.0 percent. Eight minutes later the same selection gave 16 of 549, 2.9 percent.
Our own script then probed the same 575 proxies and recorded what each one said:
Why a yes means little
The yes answer means almost nothing. 414 proxies replied 00, succeeded. 343 of them named relay port 0, which leaves nowhere to send a datagram. 40 named a private address that cannot be reached from the internet. 15 named a real relay that never answered. Only 28 proxies said plainly that they do not support the command, with code 07.
Our September test found the same pattern on a smaller sample. On 2 September 2026, 19 of 40 high-uptime SOCKS5 entries accepted UDP ASSOCIATE, 17 of those named relay port 0, and none relayed a query. That test is described in SOCKS4 vs SOCKS5.
Relays that outlive their connection
One more finding breaks the standard. After a working relay answered, we closed its TCP connection and sent the same query again. 9 of the 16 relays still answered, and 10 of 17 in the second run. Those relays outlive the association that RFC 1928 says has ended.
Which clients can use SOCKS5 UDP?
The proxy is half of it. The client must send UDP ASSOCIATE itself, and many common clients never do:
| Client | SOCKS5 UDP | Where it says so |
|---|---|---|
| Chrome | No | Chromium docs: SOCKSv5 "cannot be used to relay UDP traffic" |
| Tor | No | Tor's SOCKS spec: UDP ASSOCIATE "is not supported" |
OpenSSH ssh -D | No | OpenSSH source: "only socks5 connect supported" |
| proxychains-ng | No | README 4.17: "It supports TCP only (no UDP/ICMP etc)" |
| PySocks (Python) | Yes, with caveats | README: "UDP mostly supported" |
| Our UDP proxy checker | Yes, as a test | It sends a real DNS query through the relay |
This answers a search that reaches us: proxychains does not carry UDP. Neither does ssh -D, which explains a 2013 Super User question about a SOCKS5 tunnel that worked for the browser and not for UDP. A tool that does support it will say so in its own documentation.
What needs UDP through a proxy?
Three common kinds of traffic:
- DNS. RFC 1035 (November 1987) gives name servers "datagram access using UDP" on port 53. That is why a DNS query makes a clean test.
- HTTP/3. RFC 9000 (May 2021) says "QUIC packets are carried in UDP datagrams". A TCP-only proxy path cannot carry them.
- Voice and video. RFC 3550 (July 2003) says applications "typically run RTP on top of UDP".
SOCKS5 is not the only route anymore. RFC 9298 (IETF, August 2022) describes "how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP". That is a separate mechanism, and our tests on this page do not cover it.
How do you test a proxy for UDP?
Send real traffic and wait for the answer. A granted UDP ASSOCIATE proves nothing, as the 343 relays with port 0 show. Our UDP proxy checker runs the full test in a browser: it opens an association, sends a DNS query for dns.google through the relay and says yes only when a DNS answer comes back. The same test is available through our checker's API with measure_udp set to true, as our free proxy checker documentation describes.
If you write your own test, keep the TCP connection open until the answer arrives, since closing it should end the relay. One timeout does not prove a proxy lacks UDP, because UDP itself promises no delivery. Try again, or try another resolver, before you conclude. In our first run, the checker said yes to 17 proxies and our script to 16, and they agreed on 15.
What SOCKS5 UDP is not
- Not encryption. RFC 1928 wraps datagrams only when the chosen login method provides its own protection, and the usual username and password method does not. One ranking page claims SOCKS5 UDP encrypts your traffic; the standard does not support that.
- Not on by default. Most SOCKS5 proxies in our test either refused UDP or said yes without a working relay.
- Not something your client does by itself. If the client only knows TCP, a UDP-capable proxy changes nothing.
Where to go from here
For the basics of the protocol, read what is a SOCKS5 proxy. For the errors a SOCKS5 client prints, see SOCKS5 proxy errors explained. On our network, Residential Premium SOCKS5 lines generated with udp: true open a UDP relay; see UDP residential proxies.
What this page could not check
Our sample came from public SOCKS5 proxies on our own free list, not from paid providers. We did not run a UDP relay through our own network for this page, because that needs a plan. Fragmentation, IPv6 relays, long-lived associations and QUIC through SOCKS5 were not tested. The two runs, eight minutes apart, used largely the same proxies, so they show a repeat and not two independent samples. The client table rests on each project's own documents and code, not on running every client. The share of public proxies that relay UDP can move as the list changes, so these numbers will be measured again by 10 January 2027.
Sources
- RFC 1928, SOCKS Protocol Version 5, IETF, March 1996.
- RFC 768, User Datagram Protocol, IETF, August 1980.
- RFC 1035, Domain Names: Implementation and Specification, IETF, November 1987.
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport, IETF, May 2021.
- RFC 3550, RTP: A Transport Protocol for Real-Time Applications, IETF, July 2003.
- RFC 9298, Proxying UDP in HTTP, IETF, August 2022.
- Chromium, Proxy support in Chrome, read 10 October 2026.
- The Tor Project, SOCKS extensions, read 10 October 2026.
- OpenSSH, channels.c in openssh-portable, read 10 October 2026.
- proxychains-ng README, version 4.17.
- PySocks README, read 10 October 2026.
- HProxy documentation: plans and line generation and the free proxy checker, read 10 October 2026.
- Questions people asked, cited as examples and not as evidence: Stack Overflow 53361320 (November 2018); Super User 639425 (September 2013).
- Our own measurements, 10 October 2026: our checker's UDP test on 692 public SOCKS5 proxies at 19:44 and 19:52 UTC, our raw-socket probe of the 575 that answered, and three byte-level traces. The probe scripts and an address-free table of every verdict are kept with this page's research.
