Policy Routing vs SOCKS: Which Layer Actually Proxies Traffic

You added a policy route that sends a VPN client traffic to a host running a SOCKS listener on port 1080. The packets arrive, the listener logs nothing, and the connection hangs. Nothing is wrong with the route: a next hop chooses where a packet goes, and SOCKS is a conversation a client has to start. Compare the three architectures people usually mean by sending traffic through a proxy, and it becomes clear which piece your setup is missing.

Routing, DNAT and SOCKS change different things

A policy route rewrites a layer-3 decision. Two lines are enough to send one client traffic to a chosen next hop:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

After that, the kernel hands the packet to 10.50.0.2 with the original destination still in the IP header. If 10.50.0.2 is a router, it forwards. If it is a host with a SOCKS daemon on 1080, the packet is not addressed to anything that can accept it, and DNAT to port 1080 does not help either, because a translated packet still carries the original application payload instead of a SOCKS greeting.

SOCKS5 begins with a version byte, a method list, an authentication exchange and a request that names the destination. That is application data. No routing entry and no netfilter target generates it, which is the comparison in one line: routing selects a path, SOCKS asks a server to make a second connection.

Case one: the application can speak SOCKS itself

When the program has a proxy setting, this is the shortest path and it needs no kernel change. Point it at the listener, supply credentials if the server asks for them, and decide whether names are resolved locally or passed to the proxy. With curl those are different flags, and the difference matters when the destination only resolves from the proxy side:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Applications that ignore proxy environment variables, or that open raw sockets, cannot be helped this way. Browsers and most HTTP tooling are fine; a game client, a mail daemon or an arbitrary vendor binary usually is not. The boundary is per application and per protocol, which is why this option is excellent for testing and weak as a VPN-wide answer.

Case two: an adapter that converts IP flows into proxy sessions

For programs that cannot speak SOCKS, the conversion has to happen in something that terminates IP traffic and opens proxy sessions on their behalf. That component owns a tunnel interface, accepts the flows policy routing selected, performs the SOCKS handshake for each one, and rebuilds the replies. The route points traffic at it; the adapter is what creates the session.

Read its documentation before trusting it with a whole subnet. Many adapters carry TCP well and handle UDP only through a SOCKS5 UDP association, and none of them turn ICMP into proxy traffic, so a successful ping says nothing about the proxy path. DNS is the other trap: if the adapter resolves names locally, internal-only records resolve to the wrong answer, or to nothing at all.

Loop prevention is the operational detail that bites. The adapter's own connections to the SOCKS server must not be routed back into the adapter, so its traffic needs an exception in the rule or a dedicated source address. Get that wrong and the proxy session tries to proxy itself.

Case three: the host is really a routed gateway

Sometimes the working setup contains no SOCKS at all. The remote host forwards packets or NATs them, and the source-based rule simply selects it as the exit. That design is legitimate, and it explains why a copied configuration works on one network and fails on another: the rule is identical, the missing piece is a forwarding service on the far side.

The three cases separate quickly. Check what is actually listening, then look at the first bytes that reach the host:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

A real SOCKS client first payload byte is 0x05, the version in the greeting. If the capture shows original application data instead, no SOCKS daemon will answer, because the negotiation never began. If nothing listens on 1080, the host is a gateway, and the question becomes whether it forwards and whether a return path exists.

Pick the layer with four questions

Does the program have a proxy setting? Use it and stop there. Does the traffic include UDP or ICMP that must survive? Only a routed or NAT gateway carries ICMP, and UDP needs a SOCKS5 association that both ends support. Must every process on the machine be covered, including ones you cannot configure? Then you need an adapter that owns the interface and terminates flows. Can you also own its routing, DNS and loop-prevention exceptions? If not, the plain gateway will cost less to operate.

One distinction is worth keeping straight. A VPN client own socks-proxy option describes how the outer tunnel connection reaches its server, and says nothing about converting the inner client flows. The two get confused in the same ticket constantly. Decide which relationship you need before touching a route.