Introduction to Client‑Side Split‑Tunneling with Shadowsocks

Split‑tunneling is a practical approach to route only selected traffic through a proxy while leaving the rest to the native network. For site owners, enterprise admins and developers who deploy Shadowsocks for secure outbound connections, a robust split‑tunneling configuration minimizes latency, reduces server load and secures sensitive flows without disrupting local services. This guide provides actionable, technical steps and examples for setting up split‑tunneling on common client platforms using Shadowsocks, with attention to routing, DNS, firewall rules and performance considerations.

Fundamental Concepts

Before diving into platform specifics, review these core concepts:

  • Shadowsocks modes: Local proxy (ss-local) listens on localhost and proxies via SOCKS5; redir (ss-redir) hooks traffic transparently via TProxy/iptables; tun mode uses a virtual network device (TUN/TAP) to capture and route IP packets.
  • Split‑tunneling strategies: application‑level (configure apps to use SOCKS5), domain/pattern‑based (PAC files or DNS rules), and IP/subnet‑based (routing and firewall rules). Each strategy has tradeoffs in granularity and complexity.
  • DNS handling: DNS leaks undermine privacy and routing logic. Use system DNS proxies, DNS over HTTPS (DoH) or local DNS forwarders (e.g., dnsmasq, chinadns) to ensure DNS queries for proxied domains are resolved via the proxy.
  • UDP support: Many Shadowsocks implementations support UDP relay; when tunneling UDP, ensure the server and client support UDP relay and the chosen transport (e.g., KCP, WebSocket) if used for reliability.

Choosing a Split‑Tunneling Approach

Your selection depends on goals and client environment:

  • Application level — Simplest. Configure browsers or specific apps to use SOCKS5 at 127.0.0.1:1080. Best when only a few apps require proxied access.
  • PAC (Proxy Auto‑Config) — Domain/pattern matching for browsers and systems supporting PAC. Great for web traffic with complex domain lists.
  • IPset + iptables (Linux) — High performance for whole‑system routing. Use ipset to maintain large domain→IP sets and iptables to redirect matching traffic to a local transparent proxy.
  • TUN/TProxy — Captures raw IP packets. Offers full control and compatibility with non‑TCP protocols; more complex to deploy.

Linux: High‑Performance IPset + iptables Example

This approach is ideal for routers and Linux desktops where you want to route selective IP ranges through Shadowsocks transparently.

Prerequisites

  • Shadowsocks server reachable and ss-redir or a local SOCKS5 proxy running (e.g., ss-local).
  • ipset, iptables, and iptables‑nat modules installed.
  • Root access.

Typical workflow:

  • Create an ipset for proxied IPs: run ipset create proxylist hash:net.
  • Populate the ipset from domain lists with a resolver (e.g., using a script that resolves gfwlist or custom domains and adds IPs via ipset add proxylist 1.2.3.0/24).
  • Use iptables to mark and redirect traffic: iptables -t nat -A PREROUTING -m set –match-set proxylist dst -p tcp -j REDIRECT –to-ports 1081 (assumes local redirector listening on 1081).
  • Ensure local Shadowsocks instance is started in transparent redir mode (ss-redir) or use tun2socks for TUN based capture.

Important tips: keep the ipset updated; exclude local LAN subnets with additional iptables rules to avoid routing internal traffic to the proxy.

macOS and Windows: PAC and Proxy Auto‑Routing

On macOS and Windows, PAC files are a pragmatic way to implement domain‑based split‑tunneling with minimal system modification.

PAC basics

  • A PAC file is JavaScript that returns PROXY or DIRECT for each URL. Example logic: return “PROXY 127.0.0.1:1080” for .example.com, otherwise “DIRECT”.
  • Deploy the PAC file on a local webserver (http://127.0.0.1/pac) or host it remotely.
  • Configure system proxy settings to use the PAC URL. Browsers that follow system proxy will use it for HTTP/S; for non‑HTTP protocols, use application‑level settings.

Advantages: easy to test, minimal admin privileges. Limitations: PAC controls only applications that respect system proxy; DNS leakage is possible if the browser resolves domain names locally—use browsers with DNS over HTTPS or system DNS proxying to mitigate.

Android and iOS: App‑Level, VPN APIs and Tun2socks

Mobile platforms vary significantly.

Android

  • Apps like Shadowsocks for Android provide per‑app proxying (select which apps use the proxy) and a TUN mode using Android VPN API that captures traffic and routes selected flows through SSR/SS. Use the “Bypass LAN” and “Bypass China” lists to create split rules.
  • Advanced users can combine iptables (root) with ipset similar to Linux for better performance.

iOS

  • On iOS, Shadowsocks clients use the NEPacketTunnelProvider (VPN extension) to set up a TUN and perform split‑tunneling. Clients typically expose options to include/exclude domains and apps.
  • Because iOS restricts low‑level network access, rely on trusted clients and ensure DNS settings are routed correctly to prevent leaks.

TUN / TProxy: Full‑Packet Capture Use Cases

When you must proxy UDP or non‑TCP protocols, TUN based solutions (tun2socks, tun2socks + shadowsocks) or TProxy are necessary. Typical deployment steps:

  • Create a virtual interface (tun) and assign an address.
  • Set system routes to push selected subnets via the tun interface.
  • Run tun2socks to forward packets from the tun device to the local SOCKS5 (127.0.0.1:1080) or to a transparent reds.
  • On some Linux distros, combine with ip rule/ip route and firewall marks (fwmark) to ensure replies go back through the proxy path.

Note: TUN/TProxy provides flexibility but requires careful route and firewall setup to avoid routing loops and to maintain proper MTU and fragmentation behavior.

DNS: Preventing Leaks and Ensuring Correct Resolution

DNS handling is crucial for split‑tunneling:

  • For domain‑based proxying, resolve proxied domains through the server: use a local DNS forwarder that forwards to a remote DNS over the tunnel or runs DoH/DoT over the proxy.
  • Use chinadns or dnsmasq with custom rules to direct DNS for selected domains via the proxy and others via local DNS. Example: forward .example.com to DNS server reachable only via the tunnel.
  • Validate using online DNS leak tests while the split rules are in effect.

Performance, Encryption and Reliability

Optimize for throughput and availability:

  • Use AEAD ciphers (e.g., aead_chacha20_poly1305, aes-256-gcm) supported by modern Shadowsocks implementations for performance and security.
  • Enable TCP fast open and tune socket buffers if you manage the client on Linux servers.
  • Monitor latency and packet loss. For high‑latency networks consider using KCP or mKCP‑like transports (if supported) to improve UDP reliability.
  • Keep MTU in mind when using TUN solutions; adjust to avoid excessive fragmentation (e.g., set tun MTU to 1400 or 1300 depending on encapsulation overhead).

Testing and Troubleshooting Checklist

When your split‑tunnel rules aren’t working, follow this checklist:

  • Confirm the Shadowsocks client is running and listening on the expected port (1080 for SOCKS5, 1081 for redir).
  • Check iptables rules and ipset membership on Linux: iptables -t nat -L -v, ipset list.
  • Verify DNS queries for proxied domains are resolved via proxy: use tcpdump or wireshark on the outbound interface and compare resolver addresses.
  • Inspect application proxy settings or PAC file logic for typos. Test PAC via a browser that exposes PAC evaluation diagnostics.
  • Examine shadowsocks logs for errors related to crypto or connection drops; check server logs for concurrent connection limits and CPU bottlenecks.

Security Considerations

Maintain a secure configuration:

  • Use strong, up‑to‑date ciphers and rotate keys per organizational policy.
  • Limit server access via firewall to trusted client IP ranges where possible.
  • Monitor for DNS leaks and force DNS for proxied domains through encrypted channels.
  • Be cautious when using obfuscation plugins: they help evade detection but may affect performance and complicate troubleshooting.

Conclusion and Recommended Workflow

For most site operators and enterprise users, start with the simplest approach that meets requirements: application‑level proxies or PAC for web traffic, escalate to ipset/iptables for whole‑system performance, and use TUN/TProxy only when UDP or low‑level protocol routing is required. Always combine split‑tunneling with secure DNS and robust cipher choices, and implement logging and monitoring to ensure consistent operation.

For more practical tips, scripts and prebuilt configurations tailored to server or client OS variants, visit Dedicated‑IP‑VPN at https://dedicated-ip-vpn.com/.