Reliable, automatic reconnection is a must for production-grade VPN and proxy setups. Trojan (including trojan-go and other implementations) is a robust TLS-based proxy that masquerades as HTTPS traffic, but network flakiness, NAT timeouts, ISP routing changes, or local machine sleep/hibernate events can still break client-server sessions. For site owners, enterprises, and dev teams deploying Trojan as a transport for dedicated-IP VPNs, implementing an intelligent auto-reconnect strategy ensures uninterrupted tunnels, consistent IP persistence, and minimal operational overhead.

Why auto-reconnect matters for Trojan-based VPNs

Outages or transient disruptions can be costly for automated workflows, background services, or users relying on a static egress IP. Auto-reconnect addresses several operational concerns:

  • Maintain persistent outbound IP for authentication, geo-fenced services, or security policies.
  • Reduce manual intervention so sysadmins don’t need to restart clients or reconfigure routes after dropouts.
  • Preserve active sessions for ongoing uploads, SSH tunnels, or API requests where reestablishing state is automated or tolerable.
  • Prevent DNS and routing leaks by reenabling kill-switches and restoring appropriate firewall rules when the tunnel comes back up.

Core technical concepts to implement

Before implementing reconnection logic, understand these underlying components and how they affect connection stability:

TLS session and protocol behaviour

Trojan uses TLS (mimicking HTTPS). TLS session resumption and handshake performance matter. Clients and servers with session tickets or TLS session resumption configured will handshake faster on reconnects, reducing downtime. Also ensure correct SNI and ALPN settings if mocked web server behaviour is required.

TCP keepalive and timeouts

TCP middleboxes often drop idle connections. Tune OS-level keepalive and TCP parameters to keep sockets alive:

  • Linux sysctl examples:
    • net.ipv4.tcp_keepalive_time — how long before keepalive probes are sent
    • net.ipv4.tcp_keepalive_intvl — interval between probes
    • net.ipv4.tcp_keepalive_probes — number of probes before death
  • Use TCP_USER_TIMEOUT (socket option) to limit how long outstanding data may remain unacknowledged.

Health checks and detection

Auto-reconnect systems need to reliably detect a failure. Blindly watching a process is insufficient — you must validate that the tunnel endpoint is functional and the routing/DNS state is correct.

  • Active endpoint probe: attempt an HTTP GET to an internal health endpoint, or a TCP connect to the remote Trojan port over the tunnel.
  • Network probe: verify that the client’s egress IP equals the expected dedicated IP and that DNS resolves through the expected resolver.
  • Application probe: test an application-level request that your service depends on.

Reconnection strategies

There are multiple approaches to implement an auto-reconnect mechanism. Choose one or combine several depending on scale and environment.

Supervisor / service manager (recommended for Linux)

Using systemd is the simplest, most robust approach on modern Linux servers and desktops.

Example systemd unit snippet (adjust ExecStart to your trojan client binary):

<Unit>
Description=Trojan Client (auto-reconnect)
After=network-online.target
Wants=network-online.target
</Unit>

<Service>
Type=simple
ExecStart=/usr/local/bin/trojan -c /etc/trojan/config.json
Restart=always
RestartSec=5
StartLimitBurst=10
StartLimitIntervalSec=60

Optional: Run a pre-start probe to ensure DNS is ready

ExecStartPre=/bin/sleep 2
</Service>

<Install>
WantedBy=multi-user.target
</Install>

Key fields: Restart=always and RestartSec implement immediate and automatic process restarts. Combine this with a separate health check for actual connectivity.

External watchdog script with exponential backoff

A lightweight shell script can monitor connection health and implement a reconnection policy that avoids hammering the server when the network is down. Example logic:

  • Loop: perform TCP connect to remote:port, and verify egress IP via an external service.
  • If failure detected, stop the client, sleep with exponentially increasing backoff (2s, 4s, 8s, … capped at e.g. 300s), then start the client and recheck.
  • Reset backoff after a successful validation period (e.g., 5 minutes).

Small pseudo-Bash example (conceptual):

backoff=2
while true; do
  if curl --max-time 5 -sS https://ifconfig.co/ip | grep -q "EXPECTED_IP"; then
    backoff=2
    sleep 10
    continue
  fi

  systemctl restart trojan-client
  sleep $backoff
  backoff=$(( backoff * 2 ))
  [ $backoff -gt 300 ] && backoff=300
done

Monit / supervisord / monit-based health checks

Systems like Monit or Supervisor provide process supervision with network and HTTP checks built in, allowing you to take actions (restart, run scripts) on failure. These are useful where you want more sophisticated alerts and state transitions.

Containerized deployments

If running Trojan in Docker or Kubernetes, leverage built-in health checks and restart policies:

  • Docker: use --restart=always and implement HEALTHCHECK in the Dockerfile to test tunnel health.
  • Kubernetes: use liveness and readiness probes. Make the readiness probe reflect whether the tunnel is operational (so services depending on the VPN are paused until the tunnel is up).

Handling routing, DNS, and firewall on reconnect

Restarting the client is only part of the solution. You must restore system state to avoid leaks and ensure traffic flows through the tunnel:

  • Reapply iptables/nftables rules (kill-switch). Use atomic scripts that apply rules idempotently on client start and on reconnection events.
  • Ensure default route and policy-based routes are re-established if you use source-based routing for the dedicated IP.
  • Flush stale DNS caches and restore DNS-over-TLS/HTTPS configuration to avoid DNS leaks.
  • Rebind route metrics and adjust MTU settings if necessary; MTU mismatches after reconnection can break large transfers.

Example route restore script

After the client restarts, run a script that:

  • Checks for the TUN/redirect local interface
  • Adds ip rule and route entries for the desired subnets
  • Applies firewall policies

Conceptual commands:

ip link set dev trojan0 up
ip addr add 10.0.0.2/32 dev trojan0
ip route add default via 10.0.0.1 dev trojan0 table vpn
ip rule add from 10.0.0.2 table vpn
iptables -F VPN-KILL-SWITCH
iptables -A VPN-KILL-SWITCH -m mark --mark 0x1 -j ACCEPT

...

Platform-specific considerations

Windows

On Windows, run the Trojan client under a service wrapper (nssm or sc.exe) and implement a PowerShell monitor to test connectivity and restart the service. Example tasks:

  • Use Test-NetConnection or Invoke-WebRequest to probe endpoints.
  • Detect changes in the primary DNS or default gateway.
  • Use Windows Firewall rules to enforce kill-switch behaviour; reapply rules when the service restarts.

macOS

Use launchd to run the client as a daemon. Add KeepAlive keys for restart behavior and a watchdog script that verifies routing and DNS. On macOS, ensure pf rules are applied after each reconnect.

Advanced topics and hardening

Logging and observability

Emit structured logs from your health checks and client for post-mortem analysis. Centralize logs using syslog, journald, or a log shipper. Track metrics such as downtime frequency, reconnection time, and backoff cycles.

Rate limiting and polite reconnects

Implement exponential backoff and jitter to avoid synchronized retry storms that may overwhelm servers. Respect server-side rate limits and TLS handshake limits.

Security checks

On reconnect, validate server certificates and fingerprint. If you use certificate pinning or TLS fingerprint verification (recommended for Trojan), fail closed on unexpected certificates. Verify that SNI and ALPN values remain consistent.

Testing and chaos engineering

Simulate network partitions, server restarts, and NAT timeouts in staging to validate your reconnection logic. Measure reconnection latency and verify the kill-switch properly blocks traffic during downtime.

Example end-to-end auto-reconnect workflow

Combining the above elements yields a robust flow:

  • Systemd ensures the client process runs and autorestarts on crash.
  • A watchdog script performs active probes (IP check + TCP connect) every 10 seconds.
  • On detection of a failure, the watchdog increments backoff, restarts the trojan service, reapplies firewall and routing rules, and verifies DPD / DNS state.
  • On successful validation, the watchdog resets backoff and resumes normal checks, while logging the event to the central logging system.

Checklist before deploying auto-reconnect

  • Enable TLS session resumption and verify certificate pinning options.
  • Set OS-level keepalive parameters to reduce NAT timeouts.
  • Configure systemd/launchd/service wrapper with restart policies.
  • Implement active health probes (IP and TCP/HTTP checks).
  • Automate reapplication of firewall, routing, and DNS configuration on reconnect.
  • Use exponential backoff with jitter to avoid retry storms.
  • Log events and create alerts for repeated reconnects or high downtime.

A reliable Trojan VPN client auto-reconnect solution blends OS-level supervision, active health checking, robust firewall and routing restoration, and careful network tuning. For site owners and enterprises that require a persistent dedicated IP and uninterrupted connectivity, investing in this stack reduces risk and operational burden.

For more implementation examples, configuration templates, and guidance on running Trojan with a dedicated IP, visit Dedicated-IP-VPN: https://dedicated-ip-vpn.com/