Split‑tunneling with Shadowsocks lets you send only selected traffic through an encrypted SOCKS5 proxy while the rest uses the direct network. For site owners, developers, and enterprises that need precise control over routing — to reduce latency, conserve bandwidth, or meet compliance constraints — understanding how to implement split‑tunneling securely and reliably is essential. This article walks through practical architectures, client and server tooling, routing mechanisms, DNS handling, and concrete examples for Windows, macOS, Linux, Android, and iOS environments.

Why split‑tunneling with Shadowsocks?

Pure VPNs tunnel all traffic by default, which can be unnecessary and inefficient. With Shadowsocks split‑tunneling you can:

  • Reduce latency for domestic or latency‑sensitive services by avoiding unnecessary proxy hops.
  • Save bandwidth on the proxy server by limiting proxied flows to only those that require circumvention or geolocation.
  • Increase resilience by allowing local services (internal tooling, printers, local APIs) to bypass the proxy.
  • Improve security posture by selectively routing sensitive traffic through hardened proxy nodes while keeping other traffic direct.

Core components and concepts

Effective split‑tunneling requires three things: a Shadowsocks server, a client able to apply routing rules, and a routing engine that enforces per‑destination or per‑application decisions.

Shadowsocks server

The server provides a SOCKS5‑like endpoint to forward traffic. For production deployments use a maintained implementation like shadowsocks-libev or compatible servers that support plugins (obfuscation, TLS, mTLS) and UDP relay if needed. Configure strong ciphers and authentication keys, and run the server on a hardened host.

Client software

Clients vary by platform:

  • Windows: Shadowsocks‑Win, ShadowsocksR forks, and system proxies such as Proxifier for per‑app rules.
  • macOS: ShadowsocksX‑NG, which supports PAC (Proxy Auto‑Config) and system proxy settings.
  • Linux: shadowsocks‑libev clients (ss-local, ss‑redir), and utilities like redsocks, tun2socks, and iptables/nftables to redirect traffic.
  • Android: Shadowsocks for Android supports routing modes and per‑app bypass. Newer OS versions also allow VPN‑based routing.
  • iOS: Shadowrocket, Quantumult, or NEKit‑based clients provide per‑domain rules and bypass lists.

Routing engines and methods

Three common routing approaches:

  • PAC / HTTP Proxy mode: Best for browser traffic — the PAC file decides whether to use proxy by domain. Easy but limited to proxy‑aware apps.
  • Per‑application proxies: Proxifier, ProxyCap, or app‑level settings route selected applications. Works on Windows/macOS but requires supported apps.
  • Layer‑3/L3 redirection (transparent proxy): Using iptables/nftables and tun/tap devices with tools like ss‑redir, tun2socks, or redsocks to transparently redirect selected IP ranges or ports to the local SOCKS5 endpoint. Most flexible and works for all apps, including UDP with proper setup.

Design patterns for selective routing

Choose a design based on your needs:

Domain‑based selective routing (PAC)

Use a PAC file when your main need is web traffic control. A sample PAC rule:

if (shExpMatch(host, “*.internal.example.com”)) return “DIRECT”;
if (dnsDomainIs(host, “blockedsite.com”)) return “PROXY 127.0.0.1:1080”;

Advantages: simple, cross‑platform for browsers. Limitations: non‑HTTP/HTTPS traffic and non‑proxy‑aware apps are unaffected.

IP/range based split‑tunneling (recommended for full control)

Use routing tables and firewall marks to direct traffic by destination IP ranges. Typical pattern on Linux:

  • Create a TUN device and run a SOCKS‑to‑TUN forwarder (e.g., tun2socks), or use ss‑redir with iptables REDIRECT.
  • Populate an IP list (China netblocks via chnroute, or corporate IP ranges) and configure iptables/nftables to exclude these ranges from redirection.
  • Mark packets with iptables and use ip rule/ip route to send marked packets via the TUN interface.

Application‑level split‑tunneling

On Windows/macOS, use per‑app proxy tools to send only selected processes through Shadowsocks. This is the simplest approach for mixed environments with specific desktop apps requiring proxying.

Practical Linux example: iptables + tun2socks

This example shows how to route only traffic to specific external networks through Shadowsocks while keeping local and trusted destinations direct. It assumes a local SOCKS5 proxy at 127.0.0.1:1080 and a tun device managed by tun2socks.

  • Create a new routing table (in /etc/iproute2/rt_tables): add “200 ss”.
  • Start tun2socks and bring up a TUN0 interface (example uses gvisor-tun2socks or similar) so proxied traffic exits via TUN0.
  • Add an ip rule to route marked packets:
    ip rule add fwmark 0x1 table ss
  • Set default route for table ss via the TUN0 gateway:
    ip route add default dev tun0 table ss
  • Mark packets that should go via the proxy with iptables:
    iptables -t mangle -A OUTPUT -p tcp -d 203.0.113.0/24 -j MARK –set-mark 1
  • Ensure local LAN and private ranges are bypassed:
    iptables -t mangle -A OUTPUT -d 10.0.0.0/8 -j RETURN and similar for 192.168.0.0/16 and 127.0.0.0/8.

Notes:

  • For UDP, ensure your client supports UDP relay or use a UDP proxy solution. Shadowsocks UDP relay via shadowsocks-libev and a compatible client is necessary.
  • Always add reverse rules to allow DNS responses and ICMP where required.

Handling DNS leaks and reliability

DNS is a common leakage vector. Options to mitigate:

  • Use proxy‑aware DNS: Configure the client to do DNS over the proxy (e.g., DNS queries over SOCKS5 or shadowsocks local DNS resolver).
  • Encrypted DNS: Run DoH/DoT locally and direct only DoH/DoT traffic through proxy unless you trust the upstream resolver.
  • Force DNS via TUN: Use iptables to redirect UDP/TCP DNS ports (53) for selected destinations through the TUN device so resolution happens in the proxied path for targeted domains.

Advanced considerations: UDP, MTU, and performance

UDP support matters for games, VoIP, and DNS. Shadowsocks supports UDP relay when both server and client implement it. If you use tun2socks, be aware of MTU and fragmentation:

  • Set TUN MTU slightly lower than the physical interface to avoid fragmentation, e.g., 1400 bytes.
  • Monitor for increased CPU usage; user‑space packet forwarding and encryption add overhead. Consider using higher performance implementations (shadowsocks‑libev, BBR congestion control) and multi‑core tuning.
  • Use SOCKS5 UDP ASSOCIATE or UDP encapsulation plugins appropriately. Verify server firewall allows UDP forwarding.

Platform‑specific tips

Windows

Use Shadowsocks‑Win in conjunction with Proxifier or built‑in system proxy: set a PAC file for browsers and use Proxifier rules for other applications. For enterprise use, deploy Proxifier profiles via group policy or configuration management to ensure consistent routing across workstations.

macOS

ShadowsocksX‑NG supports PAC and system proxy toggles. For transparent routing, consider creating a TUN device with a tool like sshuttle or use pf rules to redirect traffic selectively. Use per‑domain bypass with /etc/hosts for internal names if necessary.

Android

Shadowsocks for Android supports per‑app routing and bypass modes. Newer Android versions allow VPN‑based implementations that can provide system‑wide split tunneling. For managed devices, configure per‑app VPN profiles through EMM/MDM.

iOS

Use clients that leverage the Network Extension framework (Shadowrocket, Quantumult) for per‑domain and per‑app rules. For enterprise deployments, configure per‑app VPN via MDM so only specific managed apps use the proxy.

Security hardening

Beyond routing, protect the tunnel and endpoints:

  • Use strong ciphers (AEAD modes like AES‑GCM or ChaCha20‑Poly1305) and rotate keys periodically.
  • Run the Shadowsocks server behind a hardened firewall and limit management ports.
  • Use transport obfuscation plugins (v2ray‑plugin, simple‑obfs) or TLS wrapping if threat actors perform DPI.
  • Log minimally and monitor for anomalies; enforce rate limits and IP whitelists when possible.

Operational checklist before production rollout

  • Define which destinations must be proxied and which must remain direct (create authoritative lists).
  • Test DNS resolution paths and ensure no leaks using tools like dnsleaktest and packet captures.
  • Validate performance: latency, throughput, and CPU usage under realistic loads.
  • Create rollback and emergency bypass plans (disable proxy or switch to full direct routing quickly).
  • Document configuration and automation scripts for reproducible deployments.

Split‑tunneling with Shadowsocks gives you the flexibility to route selectively, balancing performance and privacy. The right approach depends on your environment: PAC and per‑app proxies work well for user‑facing desktops, while transparent L3 redirection is better for servers and full‑stack control. Combine DNS hardening, UDP support, and routing table practices to build a robust, secure selective routing solution.

For more implementation guides and managed solutions, visit Dedicated‑IP‑VPN.