Introduction: Why Understanding Trojan Routing Matters

Trojan is a modern, TLS-based proxy protocol designed to blend with normal HTTPS traffic while providing high performance and compatibility with existing network stacks. For website operators, enterprise IT, and developers deploying Trojan as part of a secure access stack, the core challenge is not only running the server and client but also designing robust routing rules that ensure traffic goes where it should—efficiently, securely, and with predictable behavior.

Core Concepts: How Trojan Interacts with Network Layers

At a high level, Trojan operates as an application-layer proxy that uses TLS for transport and disguises payloads to resemble standard HTTPS. It sits above the TCP layer and below application protocols like HTTP, SOCKS, or custom multiplexers. To make routing decisions, you must bridge three domains:

  • Network layer routing (IP route tables, policy routing, PBR)
  • Transport-layer control (TCP/UDP forwarding, NAT, MTU)
  • Application-layer matching (SNI, ALPN, HTTP Host, path-based rules)

Understanding how these domains interact is critical when designing routing rules so that, for example, DNS lookups are resolved to the expected IPs and TCP flows are directed to the Trojan client daemon rather than being leaked through a direct gateway.

Transport vs Application Routing

Transport routing decisions are usually enforced by the kernel (routing table, firewall). Application routing decisions are enforced by the Trojan client and any local proxying utility (e.g., redsocks2, v2ray-plugin, or ipset-based redirectors). The most robust setups combine both: kernel-level routing prevents leaks, and application-level rules provide granular control.

Typical Deployment Topologies

Before designing rules, pick a topology that matches operational needs. The three common ones are:

  • Local transparent proxy (redirect): The Trojan client runs on the host, intercepts outbound TCP using iptables REDIRECT or nftables, and proxies traffic transparently.
  • System-wide gateway (router/server): A perimeter gateway hosts Trojan client and performs NAT/PBR for internal clients. Useful for offices or multi-device deployments.
  • Per-application proxy: Individual applications are configured to use Trojan via SOCKS5 or HTTP proxy emulators (when available). This is the most controlled but requires app-level support.

Key Building Blocks for Routing Rules

To create predictable routing behavior, you will commonly use a combination of:

  • Policy-based routing (PBR): Multiple routing tables with ip rule selectors (ip rule add from/mark lookup) to force traffic from a UID/GID or source subnet to the tunnel or proxy route.
  • Firewall marks (fwmark): Mark packets via iptables/nftables and use ip rule to map marks to alternate routing tables.
  • IP sets: Maintain large lists of IP ranges (e.g., private, local, CDN ranges) to exclude/include in redirection efficiently.
  • DNS control: Use split-horizon DNS or a local resolver (dnsmasq/unbound) so that hostname resolution matches your routing expectations and avoids leaking queries to default resolvers.
  • Transparent redirectors: Tools like redsocks2, tproxy, or socat when you need TCP/UDP transparent forwarding where direct SOCKS isn’t supported.

Why DNS Must Be Part of the Plan

If the Trojan client only proxies TCP flows but DNS queries go out the default interface, you can still leak destination information or get different resolution results (CDN-affiliated addresses) causing incorrect routing. Running a local DNS forwarder and forcing DNS to use the same routing policy as proxied traffic is a common best practice.

Example Routing Policy Patterns

Below are three practical patterns you can adapt. They are described conceptually so you can translate them to iptables, nftables, or cloud firewall rules.

1. Per-UID Routing (Desktop/Server)

  • Create a dedicated system user (e.g., trojanuser) for processes whose traffic must be proxied.
  • Mark packets originating from that UID using iptables mangle (iptables -t mangle -A OUTPUT -m owner –uid-owner trojanuser -j MARK –set-mark 0x1).
  • Use ip rule add fwmark 0x1 table 200 and configure table 200 to route via the virtual interface connected to the Trojan client (e.g., tun/tap or loopback redirection).
  • Ensure the Trojan client binds to loopback and listens for redirected connections, translating them into outbound TLS sessions to the remote server.

This method keeps proxied traffic well contained and leaves system services untouched.

2. Network Gateway (Office/Edge Router)

  • Use source-based policy routing: ip rule add from 192.168.1.0/24 table 200 to route all devices behind the gateway through the Trojan client.
  • At the gateway, intercept outbound port 80/443 (or specific ports) and redirect to the Trojan client via TPROXY. For UDP flows (e.g., DNS), forward to a local resolver that is itself routed through Trojan if needed.
  • Employ ipset to whitelist local services and known cloud provider addresses to avoid routing management traffic into the proxy path.

3. Split Routing (By Destination)

  • Maintain an IP set of “proxied destinations” (e.g., geo-blocked IP ranges or competitor networks). Use firewall rules to mark packets whose destination matches the set.
  • Route marked packets via the proxy table while keeping everything else direct for latency-sensitive services like VoIP/CDN edge nodes.

Practical Configuration Considerations

When implementing the above patterns, pay attention to these operational details:

Firewall and NAT Order

In iptables, packet traversal order matters (PREROUTING, INPUT, OUTPUT, POSTROUTING). For transparent redirection of locally generated traffic, use mangle/OUTPUT for marking and nat/PREROUTING for redirected flows arriving via routing. With nftables, define consistent chains and priorities to avoid unintended matches.

TPROXY vs REDIRECT

Use REDIRECT when you want to send traffic to a local listening socket on the same IP/port. Use TPROXY when preserving original source address is necessary (typical for gateway scenarios where backend servers rely on client IP). TPROXY requires enabling transparent proxy capabilities and appropriate capabilities for the proxy process.

MTU and MSS Clamping

Tunneling and TLS wrapping increase packet size. If you see fragmentation or connection stalls, implement MSS clamping (tcp_mss) to avoid IP fragmentation issues. In iptables: -m tcpmss –mss 1:1452 -j TCPMSS –clamp-mss-to-pmtu as an example; adjust based on your path MTU and encapsulation overhead.

TLS and SNI Handling

Trojan relies on TLS to blend into HTTPS. Proper SNI and ALPN handling is essential if the remote server offers multiplexed services or you use domain-based routing at the server side. Ensure your Trojan server certificate is valid for the SNI you present and that ALPN negotiation matches expectations (e.g., http/1.1 or h2) if using HTTP-based multiplexers.

Operational Hardening and Monitoring

Routing is not a “set and forget” task. Implement these practices to keep things reliable and secure:

  • Logging: Enable detailed logs on the Trojan client for connection establishment, TLS negotiation and errors. Correlate with firewall logs for packet drops or DNAT failures.
  • Health checks: Periodically probe proxied flows via synthetic transactions to validate path health and DNS correctness.
  • Fail-open vs Fail-closed: Decide whether the system should fall back to direct routing if the proxy fails. For enterprise environments, fail-closed (blocking traffic) can be safer to prevent leaks.
  • Metrics & Alerts: Export connection statistics, error rates, and latency graphs. Alerts for routing table changes or unexpected DNS responses can preempt outages.

Troubleshooting Checklist

When traffic does not flow as expected, use this checklist:

  • Verify that DNS resolves to expected IPs when queried locally versus when routed through the proxy.
  • Confirm firewall rules are hit using packet counters (iptables -L -v or nft list ruleset) and kernel packet/byte stats.
  • Ensure ip rules and route tables are ordered properly (ip rule show; ip route show table <id>).
  • Check the Trojan client logs for TLS handshake failures, SNI mismatches, or capacity issues.
  • Validate MTU/MSS settings to rule out fragmentation issues.
  • Test direct TCP connections to the backend server from the host to confirm reachability outside of the proxy path.

Scaling and Performance

For high-throughput deployments:

  • Run multiple Trojan client instances pinned to CPU cores to avoid event-loop bottlenecks.
  • Use kernel bypass techniques or user-space TCP stacks only when necessary and after careful benchmarking.
  • Cache DNS and avoid per-connection DNS lookups; combine with persistent TLS sessions and connection pooling where supported.
  • Offload TLS to hardware accelerators or a dedicated TLS terminator if server-side CPU becomes a bottleneck.

Example Checklist for Production Rollout

Before moving to production, ensure:

  • All necessary ip rules and tables are present and persisted across reboots.
  • Firewall rules have proper rate limiting and logging to detect abuse.
  • DNS is under your control or uses trusted resolvers to avoid hijacking.
  • Failover mechanisms are in place (secondary Trojan servers, automated routing switch-over).
  • Operational runbooks and rollback steps are documented and tested.

Designing routing for Trojan-based deployments is about aligning network-layer mechanisms with application-layer expectations. Combining policy routing, packet marking, DNS control, and thoughtful firewall rules produces a secure, resilient environment for proxied traffic. Monitoring, testing, and incremental rollouts will safeguard against leaks and outages.

For more guidance and advanced templates tailored for server and gateway setups, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.