Introduction

High availability (HA) is a critical requirement for any production-grade VPN deployment. For services using the Trojan protocol (commonly implemented via trojan-go or trojan), ensuring uninterrupted connectivity means preparing for server failures, network blips, maintenance windows, and DDoS incidents. This guide provides a practical, technically detailed walkthrough for building a robust multi-server failover architecture for Trojan VPN, aimed at site owners, enterprise operators, and developers who need predictable availability and graceful failover.

Design goals and failure modes to plan for

Before coding and provisioning, define your availability objectives. Typical goals include:

  • Seamless client reconnection with minimal service interruption (seconds).
  • Automatic traffic rerouting when a server or network path fails.
  • Geographic redundancy to mitigate datacenter outages.
  • Defence against targeted attacks like volumetric DDoS that might take down a single endpoint.
  • Preservation of security properties (TLS/XTLS integrity, client authentication).

Common failure modes to address:

  • Single server process crash or restart.
  • Host network outage, BGP flaps, or ISP failure.
  • Certificate expiration or misconfiguration.
  • Resource exhaustion due to attack or traffic spikes.

High-level architectures for Trojan HA

There are three practical multi-server architectures you can choose from, each with trade-offs:

1. Active-passive with virtual IP (keepalived/VRRP)

In this design, one machine holds a virtual IP (VIP) and runs the Trojan server. A secondary node monitors health and takes over the VIP when the primary fails using VRRP (commonly implemented by keepalived). Advantages: simple to implement, transparent to clients. Drawbacks: single VIP limits scaling and can be affected by the network path to that IP.

Key points:

  • Use keepalived with health checks that probe Trojan’s socket (e.g., curl to TLS endpoint or tcpcheck). Configure short advert intervals for quick failover but balance against split-brain risk.
  • Ensure VIP moves cleanly between hosts—configure sysctl settings such as net.ipv4.ip_nonlocal_bind=1 and persistent ARP announcements if needed.
  • Automate TLS certificate management on both nodes with certbot or acme.sh; ensure both hosts can obtain/renew certificates or share certs via secure sync (rsync over SSH).

2. Load-balanced active-active (HAProxy, Nginx stream, LVS)

Use a front-end load balancer to distribute traffic among backend Trojan servers. This enables horizontal scaling and graceful failover when individual servers go down. Common frontends are HAProxy, Nginx stream module, or Linux LVS. You can place the load balancer on dedicated hosts or use cloud-managed load balancers.

Implementation notes:

  • Configure the balancer to use TCP mode (Layer 4) for Trojan TLS passthrough, preserving end-to-end TLS. HAProxy supports TCP health checks and backend weights.
  • For session affinity, use consistent hashing by client IP if desired, but be mindful that clients often share NAT IPs; stateless backends are preferable.
  • Use TLS termination at the backends to preserve Trojan’s client certificates. The balancer should not terminate TLS unless you intentionally want to inspect traffic and re-encrypt.

3. DNS-based multi-endpoint with health checks (geo/dns failover)

Split clients among several server endpoints using DNS. Use low TTLs and an authoritative DNS provider that supports health checks and automatic failover (e.g., Cloudflare, NS1). This approach is cloud-friendly and scales globally; however, DNS caching can delay failover.

Best practices:

  • Set TTL to a low value (e.g., 60 seconds) but accept that some resolvers cache longer.
  • Combine with client-side multi-server lists: Trojan clients can include multiple server addresses in their config so they will try the next server if the first fails.
  • Use Anycast or BGP for ultra-fast network-level failover across regions if you operate your own IP space.

Trojan-specific configuration considerations

Trojan relies on TLS and optional XTLS (trojan-go) features. HA planning must preserve authentication and encrypted channels.

TLS certificate handling

Certificates must be valid at the endpoint where TLS is terminated. For active-passive VIP, both nodes should have the certificate and private key locally. For a load-balanced architecture with passthrough, each backend must host the certificate. Use automated renewal and deployment:

  • Use acme clients in non-interactive mode (certbot, acme.sh) with DNS or HTTP challenge depending on topology.
  • Synchronize certs using a secure mechanism (rsync+ssh, scp, or a secrets manager). Make sure to reload the Trojan server on certificate renewal.

XTLS and TLS passthrough

If you use trojan-go’s XTLS mode for better performance, ensure the load balancer supports TCP passthrough and does not attempt to parse TLS. For balancers that support SNI routing, avoid termination. In active-passive VRRP setups, XTLS works unchanged.

Client configs for failover

Modern Trojan clients support multiple server entries. Provide clients with a prioritized server list so that if the primary endpoint fails, the client tries the next entry. Example logical flow:

  • Client attempts primary host:port; on connection timeout or TLS handshake error, it switches to the next server immediately.
  • Clients should implement exponential backoff but also periodic probing of the primary so it can be restored automatically once healthy.

Health checks and monitoring

Reliable failover depends on accurate and timely health checks.

  • Active checks: probe the Trojan endpoint by establishing a TLS connection and performing a minimal handshake or protocol-specific probe. For trojan-go, you can attempt a TCP connect to port and verify the certificate subject or SAN.
  • Process and resource checks: monitor trojan process status, CPU, memory, and file descriptors. Scripts should mark a node unhealthy if resource exhaustion occurs.
  • Network checks: perform traceroute/ping to important upstream peers to detect partial network failures.
  • Centralized monitoring: collect metrics with Prometheus node exporter + trojan exporter or custom scripts; alert via Alertmanager to email/Slack/SMS.

For HAProxy or keepalived, configure health check scripts that exit non-zero when the Trojan process is unhealthy. Example check logic: tcp connect to localhost:trojan_port -> TLS handshake -> verify expected certificate CN -> exit 0/1.

Automated failover orchestration

Automation reduces human error and improves mean time to recovery (MTTR).

  • Use systemd unit files that ensure trojan restarts on failure (Restart=on-failure, RestartSec=5).
  • In keepalived, set track_script to run health checks and adjust priority to trigger failover.
  • Use orchestration tools (Ansible, Terraform) to provision consistent configurations across servers and to rotate keys/certs.
  • For DNS failover, leverage provider APIs to programmatically update records when health checks fail.

Scaling and DDoS protection strategies

High availability must coexist with capacity planning and abuse protection.

  • Shard users across multiple servers or regions to reduce blast radius. Use geo-aware DNS to send clients to nearest healthy datacenter.
  • Front Trojan endpoints with DDoS mitigation services (cloud scrubbing, CDN TCP proxies) when termination at their edge is acceptable. If end-to-end encryption must be preserved, prefer providers that offer TCP passthrough or mitigate at the IP layer via BGP nullroutes or scrubbing centers.
  • Rate-limit at the balancer using connection limits (HAProxy maxconn, per-IP limits) to protect backends.

Operational checklist and runbook

Prepare a runbook that operators can follow under incident conditions. Include:

  • Steps to verify server health: systemctl status trojan, tail logs, prometheus dashboards.
  • Procedure to force failover (e.g., stop keepalived on primary, change VIP ownership) and to revert once the primary is healthy.
  • Certificate renewal troubleshooting checklist.
  • Contact escalation matrix for network provider or datacenter support.
  • Regular DR exercises: simulate primary server failures and measure recovery time; test client reconnection behavior.

Example deployment components and interactions

A robust deployment might include:

  • Two or more trojan-go backends configured with identical TLS certificates and authentication secrets.
  • A pair of keepalived-managed load balancers providing VIPs to client endpoints in active-active mode (VIPs backed by HAProxy). Alternatively, a cloud load balancer with health checks pointing to multiple origins.
  • CI/CD pipelines that roll out configuration changes with canary testing across a subset of servers before global rollouts.
  • Monitoring stack (Prometheus + Grafana) with alerts for high latency, TLS handshake failures, certificate expiry (alert at 30 days before), and connection counts.

When designing the topology, document the security boundary and ensure keys and certificates are handled per your organization’s secret management policy.

Conclusion

Building high availability for Trojan VPN services requires combining robust network architecture, careful TLS/XTLS management, reliable health checks, and automated operational playbooks. The right approach depends on scale and constraints: keepalived for simplicity, load balancers for scale, and DNS-based methods for global distribution. Whatever architecture you select, emphasize automated certificate renewal, centralized monitoring, and regular failover testing to keep your service resilient in production.

For more detailed guides, templates, and managed configuration examples, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.