Split-tunneling is a practical approach for organizations and advanced users who need to balance privacy, compliance, and performance when routing traffic through a VPN. For those running Trojan-based VPN clients (Trojan, trojan-go, or compatible proxies), careful split-tunneling configuration can significantly reduce latency and bandwidth costs while preserving the security guarantees of TLS-encrypted Trojan connections. This guide provides a detailed, platform-agnostic walkthrough with concrete, technical techniques—covering Linux routing and firewall tools, Windows and macOS options, DNS handling, performance tuning, and security considerations—so administrators and developers can deploy a fast, robust split-tunnel setup for Trojan VPN clients.

Why split-tunneling matters for Trojan VPN deployments

Split-tunneling lets you selectively route traffic: only sensitive or restricted flows go through the Trojan tunnel, while the rest uses the local network. The benefits include reduced load on the VPN server, lower latency to local services (CDNs, cloud APIs), and improved throughput for bulk transfers. However, misconfiguration can cause DNS leaks, break policy enforcement, or expose internal resources. With Trojan’s TLS-based design (often indistinguishable from regular HTTPS), you also gain plausible cover traffic; but that doesn’t replace precise split-tunnel rules and DNS hardening.

Core concepts to implement before tuning

Before applying advanced optimizations, ensure the following foundations are in place:

  • Deterministic routing rules: Use policy-based routing to direct marked packets into a secondary routing table instead of a single default route hack.
  • Packet marking: Tag traffic from specific UID/GID or local ports so the kernel can select the correct route table.
  • DNS isolation: Avoid system DNS leaks with per-namespace resolvers or explicit DNS-over-HTTPS/DoT configurations for tunneled traffic.
  • Firewall rules consistency: Ensure NAT/masquerading is applied to tunneled egress only when required, and exclude local subnets from being sent to the VPN.

Linux: high-precision split-tunneling using iptables/nft and ip rule/ip route

Linux offers the most flexible, high-performance primitives. The recommended pattern uses packet marks (fwmark) + policy routing. Steps:

  • Run the Trojan client as a dedicated user or bind it to specific local ports (e.g., 1080/1081).
  • Use iptables (legacy) or nftables to mark packets from that UID or port: for iptables, iptables -t mangle -A OUTPUT -m owner –uid-owner trojan -j MARK –set-mark 0x1.
  • Create a dedicated routing table entry: echo “200 trojan” >> /etc/iproute2/rt_tables; ip route add default via dev table trojan.
  • Add a rule to lookup that table for marked packets: ip rule add fwmark 0x1 table trojan.
  • Apply appropriate NAT for the tun device if the Trojan client performs full-stack proxying and requires SNAT: iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE.

For large sets of IP ranges (e.g., blocklists, CDN ranges), use ipset to store thousands of prefixes efficiently and match them in nftables/iptables rules rather than creating many individual rules.

Using network namespaces for strong isolation

Network namespaces provide a robust way to ensure that only intended processes use the VPN. Create a namespace for apps that should use Trojan, run a per-namespace resolver (such as dnsmasq or unbound) that points DNS queries through the tunnel, and start the Trojan client in that namespace. This avoids UID-based complications and makes debugging simpler (use ip netns exec nsname tcpdump, ip route show table main, etc.).

Windows and macOS: client-side split tunneling patterns

Windows and macOS lack native ip rule primitives, but split tunneling is still achievable:

  • Use the Trojan client in SOCKS mode and employ application-level proxying via proxifier tools (Proxifier on Windows, Charles/Proxifier/Proxifier-like tools on macOS). Configure rules by process name or destination network ranges. This approach is simple but operates at user-space, so it can add latency for many small flows.
  • On Windows Server/Enterprise, use Windows Filtering Platform (WFP)-based solutions or route-based tools (netsh interface ipv4 add route) to create specific routes for networks that must bypass the tunnel. Marking-by-process requires third-party drivers.
  • macOS administrators can use pf rules and route tables, or run the Trojan client inside a lightweight VM/container to isolate network flows. Tools like Viscosity/OpenVPN clients provide per-application split tunneling but not directly applicable to Trojan; combine with SOCKS-level proxifiers for per-app control.

DNS: preventing leaks and ensuring correct resolution

DNS leaks undermine any split-tunnel configuration. Two patterns mitigate leaks:

  • Per-namespace or per-process resolvers: For Linux network namespaces, bind a resolver to the namespace and configure it to use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) via the Trojan tunnel. Tools: dnscrypt-proxy, cloudflared, unbound.
  • Policy-based DNS routing: Use iptables/nft matches for DNS (UDP/TCP port 53) to direct queries into the same fwmark/policy route that sends traffic through the Trojan client. Alternatively, rewrite /etc/resolv.conf for tunneled processes to point to a local resolver that forwards via the tunnel.

Always validate DNS behavior with tools like dig +trace, tcpdump -i port 53, and online DNS leak tests while scoped to the relevant process.

Performance tuning and throughput optimization

Trojan uses TLS sessions that can be tuned in several places for lower latency and higher throughput:

  • MTU/MSS adjustments: Path MTU issues can fragment TLS records, adding overhead. Reduce MTU on the tunnel interface (for example, ip link set dev tun0 mtu 1400) or clamp MSS with iptables/nft: iptables -t mangle -A FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu.
  • TLS session reuse and keepalive: Ensure the Trojan server and client support TLS session resumption (session tickets) and set appropriate keepalive intervals so short-lived flows do not incur full handshake penalties. Configure TCP_KEEPIDLE/KEEPINTVL in client code if available.
  • Cipher selection: Choose performant ciphers supported by both ends. On modern CPUs without AES-NI, ChaCha20-Poly1305 can be faster. For AES, ensure hardware acceleration is enabled on the host. Balance between privacy and CPU cost depending on server load.
  • Concurrency and connection pooling: Where the Trojan client supports multiplexing or connection pooling (e.g., trojan-go supports connection multiplexing), enable it for workloads with many simultaneous short connections to reduce TLS handshake overhead.
  • Offload and kernel bypass: For high-throughput appliances, consider NIC offloading features and userland kernel-bypass stacks (DPDK/AF_XDP) for proxying; this is advanced and usually necessary only for gateway-grade deployments.

Security considerations specific to split-tunneling

Split-tunneling reduces the protection surface; adopt compensating controls:

  • Explicit deny rules: Instead of relying purely on ‘allow’ lists for tunneled traffic, implement deny rules for sensitive local networks and ensure services that must not traverse the public internet are bound to internal interfaces.
  • Audit and logging: Collect per-route logs and flow records (conntrack, iptables LOG, or eBPF-based tracing) to detect unexpected egress attempts. Maintain TLS server logs to identify abnormal client behavior.
  • DNS and WebRTC leaks: Browser-based applications often bypass system proxies (WebRTC). Use browser configuration or extensions to disable WebRTC or route browsers into the tunneled namespace/process group.
  • Certificate and SNI hygiene: Ensure Trojan server certificates are valid and pinned where possible; avoid exposing server SNI or use SNI that matches legitimate-looking domains to maintain traffic stealth while abiding by policy.

Testing and validation checklist

Before rolling out to production, verify the deployment with the following tests:

  • Traceroute and mtr from tunneled and non-tunneled apps to confirm different paths.
  • tcpdump or tshark to ensure DNS and IP packets for tunneled processes exit via the proper interface and that TLS flows are intact.
  • Iperf3 tests between client and server to measure throughput with and without split-tunneling enabled, and with different MTU/cipher choices.
  • DNS leak tests and browser WebRTC leak checks to ensure no data bypasses the intended route.
  • Load tests on the Trojan server if you enable connection pooling/multiplexing to confirm it handles the intended concurrency.

Operational best practices

Maintainability and observability are as important as the initial configuration. Recommended practices:

  • Store routing and firewall rules in version-controlled configuration scripts to facilitate repeatable deployment.
  • Automate namespace or service startup with systemd units (systemd-networkd + systemd-nspawn or systemd-run) for consistent ordering.
  • Monitor CPU, TLS session counts, and network latency on both client and server. Track certificate expiry and automate renewal where possible.
  • Document exception rules (which apps are proxied and why) and review periodically to close stale tunnels that may expand attack surface.

Split-tunneling for Trojan VPN clients, when done with careful policy routing, DNS isolation, and performance tuning, yields a secure and high-performance setup that meets enterprise needs without sacrificing privacy. The combination of ip rule/ip route on Linux, namespaces for isolation, application-level proxying on desktop platforms, and DNS hardening provides a flexible toolbox to adapt to diverse environments. For production deployments, include thorough testing, monitoring, and automation to maintain security posture and performance.

Dedicated-IP-VPN — for more detailed configuration examples and managed Trojan server options visit https://dedicated-ip-vpn.com/