How Tor Handles UDP vs TCP Traffic

The Tor network is designed specifically to route TCP traffic to provide online anonymity, while fundamentally lacking native support for UDP traffic. Because Tor relies on connection-oriented SOCKS proxies and multi-hop stream multiplexing, standard connectionless UDP datagrams are dropped by the client rather than routed through the circuit. Understanding the distinction between how Tor processes TCP and rejects UDP is essential for preventing IP leaks and ensuring applications maintain privacy over the network.

How Tor Handles TCP Traffic

Tor natively supports Transmission Control Protocol (TCP) streams. When an application routes its traffic through Tor, it connects to a local SOCKS proxy (typically running on localhost:9050 or localhost:9150). Tor then creates an encrypted three-hop circuit consisting of a Guard node, a Middle node, and an Exit node.

• Connection-Oriented Routing: TCP provides reliable, ordered data delivery. Tor encapsulates these TCP streams into fixed-size 512-byte cells.
• Exit Node Relaying: The Exit node unpacks the layered encryption and performs the final TCP handshake with the destination server on behalf of the client.
• DNS over TCP: While standard DNS queries usually rely on UDP, Tor intercepts domain lookups and resolves them securely over TCP via the exit node to prevent DNS leaks.

How Tor Handles UDP Traffic

Tor does not natively transport User Datagram Protocol (UDP) packets. If an application attempts to send raw UDP packets through the Tor network, the client drops the packets locally, or the connection simply fails.

• No Native Datagram Relaying: The Tor protocol relies on the SOCKS4a and SOCKS5 proxy protocols. While SOCKS5 specifications include UDP support via the UDP ASSOCIATE command, the Tor client does not implement this command.
• Silent Dropping: Applications configured to route their traffic through Tor will fail to transmit voice-over-IP (VoIP), online gaming data, WebRTC streams, or peer-to-peer (P2P) traffic that depends exclusively on UDP.

Why Tor Excludes UDP

The exclusion of UDP is a deliberate architectural and security decision:

1. Deanonymization Risks: UDP is stateless and prone to IP spoofing. Allowing arbitrary UDP traffic would create significant risks of side-channel leaks, such as WebRTC or STUN queries bypassing the proxy and exposing the user’s real public IP address.
2. Reliability and Circuit Design: Tor constructs long-lived virtual circuits optimized for stateful, ordered streams. Adapting Tor’s cell-relay structure to handle out-of-order, best-effort UDP datagrams would introduce severe protocol complexity and network overhead.
3. Bandwidth and Abuse Prevention: UDP is commonly exploited for amplification Distributed Denial of Service (DDoS) attacks. Blocking UDP prevents Tor exit relays from becoming unwilling participants in large-scale volumetric attacks.

Workarounds for Routing UDP Through Tor

To send UDP traffic over the Tor network, the datagrams must be encapsulated inside a TCP connection:

• VPN over Tor: A VPN client can encapsulate all device traffic (including UDP) inside a TCP-based VPN tunnel, which is then routed through the Tor network to the VPN server.
• TCP Tunneling Tools: Utilities such as socat or specialized SOCKS wrappers can wrap UDP packets in TCP at the client level and unwrap them on a remote VPS acting as an exit proxy.

While these workarounds make UDP communication technically possible, they introduce significant latency and packet loss, often rendering real-time UDP applications impractical.