A successful connection handshake doesn't always mean a working internet connection.
On restrictive or unstable networks, a VPN tunnel can appear to establish successfully while actual traffic never reaches its destination.
For developers building connectivity tools, this creates an interesting engineering problem:
How do you determine whether a connection actually works, rather than simply whether it connected?
This is one of the problems we're addressing while developing Colitu, an open-source VPN project designed for challenging network environments.
The Problem With Trusting a Handshake
Consider a typical connection sequence:
- The client contacts a remote server.
- A protocol handshake succeeds.
- The application reports that the connection is established.
- The user attempts to load a website.
- Nothing happens.
A network filter may allow the initial handshake but interfere with subsequent traffic. Another network might block UDP while allowing certain TCP connections.
From the application's perspective, the connection can look healthy even though it isn't useful.
This is why connection establishment and actual connectivity must be treated as separate states.
Different Networks Require Different Transports
There isn't one transport protocol that works equally well in every environment.
Colitu supports five connection modes across several protocol families:
- Hysteria2: A QUIC-based transport designed for efficient communication, including under challenging network conditions.
- VLESS Reality: A transport configuration designed to make connections more resistant to certain forms of network filtering.
- VLESS XHTTP: An HTTP-based transport approach providing an alternative when other connection methods are disrupted.
- Trojan: A TLS-based proxy protocol offering another encrypted connection path.
- Shadowsocks 2022: An encrypted proxy protocol designed with modern cryptographic mechanisms.
Each mode has its own characteristics, advantages, and limitations.
The goal isn't to declare one protocol universally superior.
The goal is to make connection selection responsive to real network conditions.
Introducing Adaptive Connect
Manually switching between protocols can be frustrating, especially for users who aren't familiar with networking technologies.
Colitu's Adaptive Connect system is designed to reduce that complexity.
Instead of requiring users to troubleshoot every failed connection themselves, the application can attempt alternative connection modes when the selected method fails.
How the Process Works
At a high level, adaptive connection management follows these steps:
- Server Selection: Obtain the available server configuration.
- Protocol Selection: Choose a compatible connection mode.
- Connection Attempt: Attempt to establish the encrypted connection.
- Connectivity Verification: Check whether real network traffic can pass.
- Success: Continue using the working connection mode.
- Fallback: If verification fails, attempt another available mode.
The important distinction is that a successful handshake alone is not treated as sufficient evidence of usable connectivity.
Why Connectivity Verification Matters
A VPN client should distinguish between several possible conditions:
- Disconnected: No active connection has been established.
- Connecting: The client is attempting to establish a connection.
- Connected: The selected tunnel has been established.
- Connectivity Verified: Traffic has successfully passed through the intended connection path.
- Connection Failed: The connection or its verification failed.
These distinctions make connection handling easier to reason about.
They also help developers avoid giving users a false sense of connectivity.
The Challenge of Protocol Fallback
Fallback sounds simple in theory:
If Protocol A fails, try Protocol B.
In practice, implementing reliable fallback requires several engineering decisions.
1. Detecting Failure Correctly
A timeout doesn't always indicate permanent failure.
Temporary packet loss, high latency, DNS resolution problems, and server overload can produce similar symptoms.
A good fallback strategy must balance responsiveness against unnecessary protocol switching.
2. Choosing the Next Protocol
Different networks behave differently.
For example:
- Some networks restrict UDP traffic.
- Others interfere with specific TLS connection patterns.
- Certain environments allow initial connections but disrupt sustained traffic.
- Network conditions may change while the application is running.
A fallback system should consider these differences rather than assume every connection failure has the same cause.
3. Avoiding Endless Retry Loops
Repeatedly attempting the same failing connection mode wastes time and resources.
Retry limits, timeout handling, and failure-state management are important parts of a resilient connection system.
4. Managing Platform Differences
VPN applications interact with different networking APIs across Windows, Linux, Android, and iOS.
Connection orchestration, routing, tunnel management, and background execution constraints can differ substantially between platforms.
An adaptive design must account for those differences.
Security Must Remain a Priority
Reliability should never come at the expense of user security.
A VPN must not silently fall back to an unprotected direct connection simply because an encrypted tunnel fails.
This is especially important in restrictive network environments.
Connection recovery should preserve the application's security guarantees and provide accurate status information to the user.
A failed secure connection is preferable to an unannounced loss of protection.
What Adaptive Fallback Cannot Solve
Adaptive connectivity is useful, but it is not a universal solution.
There are limitations:
- A network may block every available transport.
- Captive portals may require additional authentication.
- Some networks may disrupt encrypted traffic regardless of protocol.
- Trying multiple connection modes can increase initial connection time.
- Platform-specific routing behavior can affect the traffic that receives VPN protection.
No VPN should promise perfect connectivity under every possible network condition.
Good engineering means understanding both what a system can do and where its limitations begin.
Why We're Building Colitu in the Open
VPN software occupies a particularly sensitive position in the networking stack.
Users trust it to handle their connections and protect their privacy.
At Colitu, we're working to make our client technology transparent and open to technical scrutiny.
We believe that publishing source code, documenting engineering decisions, and welcoming technical feedback are important parts of building trustworthy software.
Of course, open-source client code alone does not verify server-side behavior or replace independent security audits.
Transparency is a process, not a marketing claim.
What's Next for Colitu?
Our focus is on continuously improving:
- Adaptive connection selection.
- Reliability under difficult network conditions.
- Connection failure detection and recovery.
- Clearer connection status reporting.
- Cross-platform compatibility.
- Open-source development and technical documentation.
We'll continue sharing engineering insights, implementation challenges, and lessons learned through the Colitu Engineering series.
Let's Talk Engineering
We're interested in hearing from other developers working on networking, transport protocols, and secure connectivity.
How do you distinguish a successfully established connection from one that is actually carrying usable traffic?
Do you use active connectivity probes, health checks, timeout-based fallback, or something else?
We'd love to hear about your approach.
Explore Colitu
Built for networks that fight back.
This article was prepared with AI assistance and should be reviewed against the current implementation before publication.
Top comments (2)
For the "intended connection path" distinction, I'd use a paired fixture: the probe endpoint is reachable over the device's direct route, while the tunnel handshake succeeds but tunneled traffic is blackholed. Verification should fail even though an ordinary fetch could succeed outside the tunnel.
Then repeat during A-to-B fallback and after a network change, checking application traffic and DNS as well as the probe. Does the verifier bind its request to the selected tunnel/interface, and invalidate an old success when routing changes? I haven't run Colitu; this is a suggested route-provenance test for the state machine described here, not a claim that the client leaks or bypasses protection.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.