Routing all system traffic through a SOCKS5 proxy using tun2socks

Standard tools like proxychains often fail when it comes to multithreaded applications, Go/Rust binaries, Electron apps and system services. Enter tun2socks — a tool that creates a virtual TUN network interface, intercepts absolutely all IP traffic of the system and transparently tunnels it over SOCKS5.

Below is a comprehensive guide to choosing an implementation, configuring on Ubuntu/Debian and troubleshooting common issues.

Comparison of current implementations (as of 2026)

Over the years several versions of the utility have appeared. Choosing the right one will save you a lot of headaches.

This guide focuses primarily on xjasonlyu/tun2socks v2 as the most stable and user-friendly solution.

How it works (Architecture)

1. A virtual network interface tun0 is created.
2. The whole system (or selected applications) sends traffic to tun0 via the routing table.
3. tun2socks reads packets from the TUN, processes them via a user-space stack (gVisor) and encapsulates them into requests to a SOCKS5 proxy.
4. Responses from the proxy are returned to the TUN and delivered to the original applications.

Main danger — routing loop. If traffic from tun2socks to the SOCKS5 server also goes into the tunnel, an infinite recursion will occur, which will instantly “freeze” the internet and load the CPU to 100%.

Basic method: Global routing

This method routes all operating system traffic through the proxy.

Step 1: Install tun2socks

Download the current binary from the GitHub releases page:

# Download the latest version (amd64 architecture)
wget https://github.com/xjasonlyu/tun2socks/releases/latest/download/tun2socks-linux-amd64.zip

unzip tun2socks-linux-amd64.zip
sudo mv tun2socks-linux-amd64 /usr/local/bin/tun2socks
sudo chmod +x /usr/local/bin/tun2socks

# Check
tun2socks --version

Step 2: Create the TUN interface

Create the interface in kernel space and assign it the subnet 198.18.0.0/15 (RFC 2544, does not overlap with common local networks).

sudo ip tuntap add dev tun0 mode tun user $USER
sudo ip addr add 198.18.0.1/15 dev tun0
sudo ip link set dev tun0 up mtu 9000

Note: MTU 9000 (Jumbo Frames) is recommended to improve performance if your proxy supports it. Otherwise leave the standard 1500.

Step 3: Protect against routing loops

Assume your proxy is located on a remote server.

• SOCKS5 server IP: 93.184.216.34
• Your ISP gateway: 192.168.1.1
• Your interface: eth0

# 1. Force traffic to the proxy IP to go via the real gateway (exclude it from the tunnel)
sudo ip route add 93.184.216.34 via 192.168.1.1 dev eth0

# 2. Route all other traffic into the TUN.
# Use two /1 masks instead of removing the default gateway (0.0.0.0/0) — this is safer.
sudo ip route add 0.0.0.0/1 dev tun0
sudo ip route add 128.0.0.0/1 dev tun0

(If the proxy is local — for example, Xray on 127.0.0.1 — you need to exclude the IP address of the remote server that Xray connects to).

Step 4: Solving DNS leaks

xjasonlyu’s tun2socks does not intercept DNS requests automatically. The most reliable way to avoid leaks is to set public DNS servers (e.g. Google or Cloudflare) so their traffic also goes into the tunnel.

sudo tee /etc/resolv.conf <<EOF
nameserver 8.8.8.8
nameserver 1.1.1.1
EOF
# Protect the file from being overwritten by system services (NetworkManager/systemd-resolved)
sudo chattr +i /etc/resolv.conf

Step 5: Run

tun2socks -device tun0 \
          -proxy socks5://user:pass@93.184.216.34:1080 \
          -loglevel info \
          -mtu 9000

Automation with Systemd

To avoid re-entering routes after every reboot, create a system service.

Create the file /etc/systemd/system/tun2socks.service:

[Unit]
Description=Tun2Socks Tunnel Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
# Configure the variables for your environment
Environment=PROXY=socks5://93.184.216.34:1080
Environment=PROXY_IP=93.184.216.34
Environment=GATEWAY=192.168.1.1
Environment=INTERFACE=eth0
Environment=MTU=9000

# Prepare the interface
ExecStartPre=/bin/sh -c 'ip link set dev tun0 down 2>/dev/null || true'
ExecStartPre=/bin/sh -c 'ip tuntap del dev tun0 mode tun 2>/dev/null || true'
ExecStartPre=/bin/sh -c 'ip tuntap add dev tun0 mode tun && ip addr add 198.18.0.1/15 dev tun0 && ip link set dev tun0 up mtu $MTU'

# Routing
ExecStartPre=/bin/sh -c 'ip route add $PROXY_IP via $GATEWAY dev $INTERFACE 2>/dev/null || true'
ExecStartPre=/bin/sh -c 'ip route add 0.0.0.0/1 dev tun0 && ip route add 128.0.0.0/1 dev tun0'

# Start
ExecStart=/usr/local/bin/tun2socks -device tun0 -proxy ${PROXY} -loglevel info -mtu ${MTU}

# Cleanup on stop
ExecStopPost=/bin/sh -c 'ip route del 0.0.0.0/1 dev tun0 2>/dev/null || true'
ExecStopPost=/bin/sh -c 'ip route del 128.0.0.0/1 dev tun0 2>/dev/null || true'
ExecStopPost=/bin/sh -c 'ip route del $PROXY_IP via $GATEWAY dev $INTERFACE 2>/dev/null || true'
ExecStopPost=/bin/sh -c 'ip link set dev tun0 down && ip tuntap del dev tun0 mode tun'

Restart=on-failure
RestartSec=3
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW

[Install]
WantedBy=multi-user.target

Activation:

sudo systemctl daemon-reload
sudo systemctl enable --now tun2socks
sudo systemctl status tun2socks

Advanced: Policy Routing (fwmark) for selective routing

Changing the default gateway is not suitable for everyone. In complex systems (where Docker is present or you run your own VPN server) intercepting all traffic will break everything. Policy Routing allows sending only chosen applications through the proxy based on a user group (GID).

1. Configure routing tables

Create tun0, but instead of global routes create a separate table (e.g. 100).

sudo ip tuntap add dev tun0 mode tun user $USER
sudo ip addr add 198.18.0.1/15 dev tun0
sudo ip link set dev tun0 up mtu 9000

# All packets with mark 0x1 go to table 100
sudo ip rule add fwmark 0x1 table 100

# In table 100 route all traffic to tun0
sudo ip route add default dev tun0 table 100

2. Marking via iptables

Create a group tunapp. Traffic from any processes running as that group will be sent to the proxy.

# Add the group and add your user to it
sudo addgroup tunapp
sudo usermod -aG tunapp $USER

# Mark (fwmark 0x1) outgoing packets of this group
sudo iptables -t mangle -A OUTPUT -m owner --gid-owner tunapp -j MARK --set-mark 0x1

3. Usage

Run tun2socks as usual. Now the whole system works directly, without the proxy. To run an application through the tunnel, use the sg (switch group) utility:

# Regular request (your real IP)
curl ifconfig.me

# Request via the proxy
sg tunapp -c "curl ifconfig.me"

# Run a browser or torrent client through the tunnel
sg tunapp -c "google-chrome"

Advantage of the method: complete guarantee against routing loops, because the proxy client (for example, local Xray) runs under your normal user and its traffic is not marked.

Debugging and common issues

• Routing loop (100% CPU, log spam, no internet): Ensure the route to the proxy IP is hard-coded via the physical interface (ip route show).
• TUN is up but sites won’t load: Check DNS (/etc/resolv.conf). Check packet counters: ip -s link show tun0. If RX increases but TX stays at zero — tun2socks is not pulling packets from the kernel (check service logs).
• Low speed: Make sure MTU matches on the interface and in the program arguments (-mtu 9000). If you are CPU-limited (weak router), switch the implementation to hev-socks5-tunnel.
• Need IPv6: Add routes for IPv6 traffic analogous to IPv4:

sudo ip -6 route add ::/1 dev tun0
sudo ip -6 route add 8000::/1 dev tun0