When a VPN Says "Connected" but Traffic Is Dead: Building Adaptive Connect 2.0

Description and use

The article explains how Colitu faced a VPN that reports connected yet stops traffic after 30–50 s. Adaptive Connect 2.0 solves this with real‑traffic verification, per‑network history, backup‑aware health checks, and bounded parallel probing, achieving 98.8 % success in a 60‑minute fault‑injection test.

Problem

A VPN can display a connected indicator while application traffic stops flowing after 30–50 seconds, even though the TCP tunnel remains open.

Outcome

Adaptive Connect 2.0 achieved a 98.8% HTTP probe success rate over 60 minutes with 11 injected faults, maintaining connectivity during a 101‑second primary server outage and limiting interruptions to ~5 seconds.

Workflow

• Measure server latency
• Select server
• Establish tunnel
• Verify real traffic via external endpoints
• Report connection as functional only after traffic passes
• Maintain bounded local history per network
• Use backup route only when primary fails
• Track primary and effective health separately
• Parallel probe best candidates with bounded retries
• Inject faults to test resilience

Evidence

A VPN can establish a tunnel, complete its handshake, display a reassuring green Connected indicator, and still fail at its most important job: carrying traffic.

Source

Adaptive Connect 2.0 treats a connection as functional only after useful traffic successfully passes through the selected tunnel.

Source

In the 60‑minute endurance test, we used eight servers and injected 11 controlled failures lasting roughly 60–120 seconds each. An HTTP probe was sent through the VPN approximately every five seconds.

Source

Successful HTTP probes 741 / 750, HTTP probe success rate 98.8%

Source