Trojan VPN on Linux: Fast, Secure Client Configuration Guide

Trojan is a modern, TLS-based proxy protocol designed to mimic legitimate HTTPS traffic while providing robust privacy and resistance to censorship. On Linux, deploying a Trojan client for fast, secure connections requires careful configuration of TLS, local proxies, DNS, firewall rules, and process management. This guide walks through practical, production-ready client setups—covering trojan (original) and trojan-go clients, systemd integration, DNS and routing considerations, performance tuning, and verification steps tailored for webmasters, enterprise operators, and developers.

Why Trojan on Linux?

Trojan’s design emphasizes stealth and compatibility with existing HTTPS ecosystems. Unlike some VPN technologies, Trojan operates as an application-layer proxy using TLS semantics, which makes it harder for deep-packet inspection to distinguish from normal HTTPS traffic. For Linux servers and clients, this translates into:

• High compatibility with existing network stacks and reverse proxies (e.g., nginx),
• TLS-based security leveraging widely trusted certificates (Let’s Encrypt, commercial CAs),
• Fine-grained control over local proxy endpoints (SOCKS/HTTP) for per-application routing and split-tunneling.

Choose the Right Client: trojan vs trojan-go

There are two commonly used client implementations on Linux:

• trojan (original) — minimal, stable, and widely supported by GUI clients like Trojan-Qt5.
• trojan-go — a more feature-rich Go implementation with plugins, multiplexing, and advanced options (e.g., WebSocket, HTTP/2 transport).

For production-grade performance and advanced transport options choose trojan-go. If you need minimal footprint or GUI compatibility, the original trojan is sufficient.

Prerequisites

Before client configuration, ensure:

• You have the server address (domain or IP), port (commonly 443), and Trojan password/secret.
• Your server uses a valid TLS certificate (Let’s Encrypt recommended for automated renewal).
• Your Linux system has basic tools installed: curl, socat (optional), systemd, iptables/nftables, and net-tools.

Install trojan-go (example on Debian/Ubuntu)

Download the latest release and unpack it in /opt/trojan-go:

• curl -LO https://github.com/p4gefau1t/trojan-go/releases/latest/download/trojan-go-linux-amd64.zip
• unzip trojan-go-linux-amd64.zip && sudo mv trojan-go /opt/trojan-go/
• sudo ln -s /opt/trojan-go/trojan-go /usr/local/bin/trojan-go

Adjust the commands for Fedora/Arch packaging or use your distribution’s package manager if available.

Example trojan-go Client Configuration

Create /etc/trojan-go/config.json with a typical SOCKS5 local listener and secure TLS options:

Important fields explained:

• remote: server hostname and port.
• password: trojan password string (keep it secret and complex).
• ssl: TLS options including SNI and ALPN. Use TLS 1.3 where supported.
• localaddr/localport: local SOCKS5 listener for applications to bind to.

Example:

<pre>
{
“run_type”: “client”,
“local_addr”: “127.0.0.1”,
“local_port”: 1080,
“remote_addr”: “server.example.com”,
“remote_port”: 443,
“password”: [
“your-strong-password”
],
“ssl”: {
“verify”: true,
“verify_hostname”: true,
“sni”: “server.example.com”,
“alpn”: [“h2″,”http/1.1”],
“cipher_tls13″:”TLS_AES_128_GCM_SHA256”,
“fallback”: “”
},
“mux”: {
“enabled”: true,
“concurrency”: 8
},
“log”: {
“level”: “info”,
“access”: “/var/log/trojan-go/access.log”,
“error”: “/var/log/trojan-go/error.log”
}
}
</pre>

Notes:

• verify and verify_hostname should be true for production to prevent MITM.
• Set sni to the TLS certificate’s domain.
• mux improves performance for multiple concurrent streams—adjust concurrency to match client resources.

Systemd Service for trojan-go

Create a systemd unit at /etc/systemd/system/trojan-go.service:

<pre>
[Unit] Description=trojan-go client
After=network.target

Then enable and start:

• sudo systemctl daemon-reload
• sudo systemctl enable –now trojan-go
• sudo journalctl -u trojan-go -f

DNS and Leak Prevention

Because Trojan is a proxy at the application layer, DNS queries must not leak to the local network. Options:

• Use a DNS resolver routed through the proxy (e.g., configure systemd-resolved to forward to a local DNS proxy bound to the SOCKS5 endpoint using tools like dns2socks or pdnsd).
• Configure applications to perform DNS over HTTPS (DoH) or DNS over TLS (DoT) via local clients (e.g., cloudflared, dnscrypt-proxy).
• For global protection, replace /etc/resolv.conf with a local resolver and block outbound DNS (port 53/UDP) at the firewall.

Firewall and Kill-Switch Configuration

To prevent accidental traffic leakage if the client stops, implement a kill-switch that prevents outbound traffic except through the local proxy. Example using iptables:

• Allow loopback: iptables -A OUTPUT -o lo -j ACCEPT
• Allow trojan process outbound to server IP/port (use owner match or allow by destination):
• iptables -A OUTPUT -p tcp -d server.ip.address –dport 443 -m comment –comment “trojan server” -j ACCEPT
• Drop or REJECT other outbound traffic by default: iptables -P OUTPUT DROP

Alternatively use nftables or UFW with similar restrictions. Ensure administrative SSH access is preserved (allow SSH to known management addresses) before applying restrictive rules.

Split Tunneling and Per-Application Routing

You can route only selected applications through the trojan SOCKS5 proxy rather than system-wide tunneling:

• Use application-level SOCKS5 settings (browsers, git, package managers).
• Use proxy wrappers like tsocks, proxychains, or socat to bind individual CLI tools to the proxy.
• For GUI apps on Linux desktops, configure the browser’s proxy settings or use extensions that respect SOCKS5 with DNS over SOCKS.

Performance Tuning

To achieve low latency and high throughput:

• Enable TCP Fast Open on both client and server if kernel supports it.
• Use newer congestion control like BBR: sysctl -w net.ipv4.tcp_congestion_control=bbr
• Increase file descriptor limits (LimitNOFILE in systemd service and ulimit settings).
• Adjust mux concurrency and worker threads in trojan-go to match CPU cores and network capacity.
• Prefer TLS 1.3 and modern cipher suites; avoid ECDHE suites that are known to be slow on constrained devices.

Troubleshooting and Verification

Use the following steps to verify connectivity and TLS handshakes:

• Test SOCKS proxy with curl: curl –socks5-hostname 127.0.0.1:1080 https://ifconfig.me
• Check trojan-go logs: sudo journalctl -u trojan-go –no-pager
• Validate TLS certificate and SNI with openssl: openssl s_client -connect server.example.com:443 -servername server.example.com -alpn h2
• Network capture: tcpdump -i any host server.ip.address and inspect TLS ClientHello to verify ALPN and SNI fields.

If the connection fails, examine TLS errors first (certificate mismatch or hostname verification), then network/firewall rules and DNS resolution.

Common Pitfalls

• Using invalid or self-signed certificates without disabling verification—this is insecure.
• DNS leaks due to applications performing system DNS lookups instead of proxying DNS.
• Overly restrictive firewalls locking you out—always test rules in an open terminal session before committing.
• For GUI apps, some do not support SOCKS5 hostname resolution, causing hostname leaks; prefer SOCKS5 hostname-aware options.

Security Best Practices

To maximize security:

• Use a strong, unique password for Trojan and rotate it periodically.
• Prefer TLS 1.3 with modern ciphers and set ALPN to include typical HTTP values to mimic browser traffic.
• Pin server certificates where feasible for enterprise deployments to mitigate CA compromises.
• Ensure logs are rotated and sensitive information is not written to world-readable files.

Trojan on Linux provides a flexible and stealthy way to secure client connections without the overhead of full-layer VPNs. By combining a robust trojan-go configuration, systemd management, strict DNS/firewall policies, and performance tuning, you can achieve a highly reliable proxy client suitable for both individual webmasters and enterprise deployments.

For deployment-ready configurations, scripts, and commercial-grade dedicated IP options, visit Dedicated-IP-VPN.