UDP Through Tor's SOCKS Port: What Does Not Carry

Pointing an application at a SOCKS port works for a browser and fails for a game, and the reason is not configuration. SOCKS5 defines several commands, and an implementation is free to support only some of them; Tor's interface accepts stream connections and name resolution, not arbitrary datagram forwarding. A client that sends UDP and expects the proxy to relay it is asking for a command the server does not implement. The runbook below checks that in a few minutes and then picks a transport that can actually work.

Check What the Application Actually Sends

Start by identifying the transport rather than the protocol name. A voice client may sign in over HTTPS and then carry media over UDP; a game may authenticate over TCP and play over UDP; a file transfer may use TCP for control and UDP for discovery. The first two behaviours look identical until the login succeeds and the call still fails, which is why "it connected" is not evidence that the whole application works. Some clients also fall back from UDP to TCP on their own, which makes a partially working session look like a flaky network rather than a blocked transport.

Write down the destination port and transport for the part that fails. That one line decides whether a proxy can help at all.

What Tor's SOCKS Interface Will Accept

Tor implements the SOCKS5 CONNECT command for stream connections and extension commands for resolving names, which is why a browser works through it unchanged. UDP ASSOCIATE, the command that would let a client hand datagrams to the proxy for forwarding, is not part of what Tor offers. Documentation for the extensions lives in the project's SOCKS extensions specification, and it is short reading. The absence of a datagram command is deliberate: relaying arbitrary UDP would give the network a forwarding role it was never designed to take.

This is also the answer for WireGuard, which is UDP by design and has no TCP fallback. There is no supported path that points WireGuard at a SOCKS port, and anything claiming otherwise is a wrapper with its own trust and maintenance story rather than a feature of either tool.

OpenVPN is the partial exception, because it can be configured to tunnel over TCP and it understands a SOCKS proxy option. That still requires a server configured for TCP and a deliberate decision about the performance and fingerprinting consequences, so it is a design choice rather than a compatibility fix.

Run the Check in Order

Confirm the proxy works for streams first, so a later failure cannot be blamed on an unreachable port. Then confirm the application's own traffic, and watch which sockets it actually opens.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

A successful first command and an established stream in the second line show the proxy path working as designed. The third command looks for local datagram sockets belonging to the application; if the client opens one and sends to a remote address directly, it never consulted the proxy and no proxy setting will change that. If it fails at the first step, stop and fix the proxy path before investigating the application, because two faults at once produce a report nobody can act on.

Roll Back and Choose the Right Tool

Remove any proxy environment variables or per-application proxy settings that pointed the UDP client at the SOCKS port; leaving them in place makes later tests ambiguous. Restore the previous configuration from a copy, restart the application, and confirm the original behaviour returns so the comparison is clean. A rollback that is not verified is only a hope that the state changed.

For a transport that must stay UDP, a VPN is usually the better fit: it carries the application's packets without asking the application to speak a proxy protocol, at the cost of entirely different anonymity properties. Use each tool for what it documents, and treat any bridge between them as a separate system that needs its own review. Write down which layer carries which transport in the final report, so the next person does not rediscover the same boundary with a different application.