Split-tunneling is an essential tool for administrators and developers who need fine-grained control over which traffic goes through a VPN and which traffic uses the direct Internet path. When working with Trojan-based VPN clients and proxies, implementing split-tunneling correctly can preserve bandwidth, reduce latency for non-sensitive services, and maintain compliance with access control policies. This article walks through the technical details of split-tunneling for Trojan clients, provides a concise setup guide, and outlines operational best practices for production environments.

What split-tunneling is and why it matters for Trojan clients

At its core, split-tunneling directs specified network flows through a secure tunnel (the VPN) while allowing other flows to bypass the tunnel and use the regular network interface. For Trojan-based clients—such as Trojan, Trojan-Go, Trojan-Qt5, or clients that implement the Trojan protocol—split-tunneling reduces unnecessary overhead on the VPN server and minimizes latency for services that do not require obfuscation or geo-routing.

Key reasons to consider split-tunneling with Trojan:

  • Performance optimization: Keep latency-sensitive services (e.g., VoIP, video conferencing) off the encrypted path.
  • Bandwidth savings: Avoid routing high-bandwidth but non-sensitive traffic (e.g., CDN downloads) through the VPN.
  • Selective access: Route only targeted domains, IPs, or subnets through the Trojan proxy to access intranet resources or bypass censorship selectively.

How Trojan clients typically handle traffic

Trojan is a lightweight, TLS-based proxy protocol that looks like HTTPS to evade DPI. Unlike traditional IP-layer VPNs, Trojan operates at the application layer (SOCKS/HTTP-like proxy). Common client behaviors include:

  • Local proxy listener: The client often exposes a local SOCKS5 or HTTP proxy on 127.0.0.1 with a configurable port.
  • System-wide redirection: On some systems, tools like redsocks, tun2socks, or system VPN drivers are used to funnel system traffic into the Trojan client.
  • DNS handling: Trojan clients may not handle DNS by default; DNS leaks can occur unless DNS queries are explicitly proxied.

Split-tunneling models for Trojan

Because Trojan is application-layer, split-tunneling can be implemented at several layers. Choose the model that best fits your environment:

  • Application-level split-tunneling — Configure only specific apps to use the local proxy listener. This is simple and robust for desktop deployments.
  • Per-destination split-tunneling — Use proxy auto-configuration (PAC) files or proxy-capable applications to route traffic to particular domains/IPs via the Trojan proxy.
  • System-level split-tunneling — Employ TUN/TAP devices or tools like tun2socks to intercept system traffic and implement routing rules (policy-based routing) so only selected subnets go through the tunnel.

Quick setup: basic application-level split-tunneling

This approach leverages the local SOCKS/HTTP proxy exposed by a Trojan client and configures specific applications to use it. It is the least invasive and easiest to roll out for developers and site operators.

Prerequisites

  • Installed Trojan client (Trojan/Trojan-Go/Trojan-Qt5).
  • Local proxy listener configured (e.g., SOCKS5 on 127.0.0.1:1080).
  • Applications that support explicit proxy configuration (browsers, curl, git, package managers) or system proxies via environment variables.

Steps

  • Start the Trojan client with a local proxy listener. For example, configure trojan-go’s local_addr and local_port to expose a SOCKS/HTTP listener.
  • Set application-specific proxy settings:
    • Browsers: set manual proxy for HTTP/HTTPS or provide a PAC file to selectively proxy domains.
    • Command-line tools: export environment variables such as http_proxy, https_proxy, and no_proxy.
  • Test traffic routing by checking your public IP from the proxied application vs. an unproxied one.

Note: Because DNS may be resolved locally by default, configure applications or the system to resolve DNS through the proxy if you want to avoid DNS leaks.

Advanced setup: per-destination split-tunneling with PAC files

PAC (Proxy Auto-Configuration) files allow fine-grained domain-based routing without complex system changes. A PAC file is a JavaScript function that returns the proxy for a given URL. Use PAC when you need to route specific domains or top-level paths through the Trojan proxy and leave everything else direct.

PAC file pattern

The PAC function looks like:

function FindProxyForURL(url, host) { / logic / }

  • Return values: "PROXY 127.0.0.1:1080" to route via local proxy or "DIRECT" for direct access.
  • Use domain matching, IP range checks, and custom lists for complex logic. Maintain lists in separate files and reference them to simplify maintenance.

System-level split-tunneling: TUN/TAP and policy routing

For server-grade control and full-system transparency, use a TUN/TAP device and policy-based routing. This is appropriate when you need to ensure non-proxy-aware apps still can be routed selectively through Trojan.

Core components

  • TUN/TAP device — provides a virtual network interface to capture IP packets.
  • tun2socks — converts captured IP packets from the TUN device into SOCKS/HTTP connections to the local Trojan proxy.
  • Policy routing / iptables — mark packets and use ip rule/ip route to route marked packets into the TUN device.
  • DNS interception — iptables or DNS proxies (e.g., dnsmasq) redirect DNS queries to a controlled resolver to avoid leaks.

Typical flow

  • Create tun device and configure routing table for tunneled traffic.
  • Use iptables to mark packets matching selected source IPs, destination IP ranges, or ports.
  • Use ip rule to route marked packets into the custom routing table where the default route points to the TUN device.
  • Run tun2socks to read from the TUN device and forward traffic to the Trojan local proxy listener.

This architecture allows selective subnets or processes to be captured at the IP layer without requiring per-app proxy configuration.

DNS and leak prevention

DNS is a common source of leaks. Because Trojan operates at the application/proxy level, DNS queries from the system resolver may bypass the proxy. Recommended strategies:

  • Use DNS-over-HTTPS/DoT inside proxied applications or route DNS to a private resolver via iptables redirection.
  • When using tun2socks, run a DNS proxy (e.g., pdnsd, dnsmasq) bound to the TUN device and configure /etc/resolv.conf accordingly.
  • On Windows, consider forcing DNS through the proxy using proxy-aware DNS clients or by using the system’s VPN driver when available.

Security considerations

Implementing split-tunneling introduces potential security trade-offs. Address these proactively:

  • Data exfiltration risk — Ensure only non-sensitive traffic is excluded from the tunnel. Use application allowlists/deny-lists and endpoint controls.
  • Authentication/token leaks — Tokens stored locally may be used by direct-networked apps. Consider rotating credentials and enforcing multi-factor authentication (MFA).
  • DNS manipulation — Monitor for DNS spoofing when queries are direct. Route critical DNS queries through encrypted channels.
  • Logging and monitoring — Instrument both tunneled and direct paths to detect anomalies and to satisfy compliance auditing.

Operational best practices

Follow these recommendations to run Trojan split-tunneling reliably in production.

Design and policy

  • Define clear policies on which hosts, subnets, and applications must always use the tunnel vs. those allowed direct access.
  • Document the rationale for exclusions (e.g., latency-sensitive services) and enforce them via automation.

Automation and configuration management

  • Deploy Trojan clients and routing rules with configuration management tools (Ansible, Puppet, Chef) to ensure reproducibility.
  • Store PAC files, routing rules, and DNS configs in version control.

Monitoring and observability

  • Monitor proxy metrics (connection counts, handshake failures, RTT) and system metrics (CPU, memory of tun2socks/trojan process).
  • Log queries and flow metadata with retention policies that meet privacy and compliance requirements.

Fail-safe behavior

  • Define fail-closed vs. fail-open semantics. In high-security environments, prefer fail-closed so traffic stops if the tunnel fails.
  • Implement service meshes or sidecars for critical services that must continue working even when the proxy is down.

Troubleshooting checklist

When split-tunneling behaves unexpectedly, use this checklist:

  • Verify the Trojan client local listener is reachable (telnet 127.0.0.1 port).
  • Check DNS resolution path for leaks (use online detectors from a browser that is proxied and one that is direct).
  • Validate iptables marks and routing table entries with iptables -t mangle -L -v and ip rule show.
  • Inspect tun2socks logs for connection errors and retransmissions.

Conclusion

Split-tunneling for Trojan clients offers a flexible way to balance security, performance, and cost. Choose the appropriate model—application-level, PAC-based, or system-level—based on your operational constraints and security policy. Pay special attention to DNS handling, routing correctness, and fail-safe semantics to avoid leaks and ensure predictable behavior. With proper automation, monitoring, and well-documented policies, split-tunneling can be a reliable part of an enterprise or developer toolkit for selective traffic routing.

For additional resources, configuration examples, and managed solutions, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.