DEV Community: Colitu VPN

Gamifying a VPN without breaking privacy: how we built Colitu Passport

Colitu VPN — Sun, 25 Oct 2026 13:23:01 +0000

Most VPN apps look the same: there's a big connect button, a list of countries and a speed number. The product works well when you never think about it, and that's a problem for us as a VPN team. Users forget you exist until something breaks.

We wanted to try something different. We didn't want another dashboard or another speed graph. We wanted a reason to enjoy opening the app.

The result is Colitu Passport: every country you connect to becomes a stamp in a personal passport. You can level stamps up, complete collections and compare passports with friends.

Gamification and privacy usually pull in opposite directions, though. Most engagement systems run on detailed behavioral data, and a VPN is the last product that should collect that. This post covers how we tried to build one without the other.

The core loop

The rules are simple:

Unlock: stay connected to a country for 5 minutes and you earn its bronze stamp.
Progress: while the VPN is on, you earn a puzzle piece at the 10th minute and another at the 60th minute of the day. That's a maximum of 2 pieces per day.
Level up: each tier costs 12 pieces. The tiers are Bronze, Silver (12), Gold (24) and Diamond (36).

The math is intentional. At 2 pieces per day, a single level takes at least 6 days. There's no way to grind faster and no way to pay to skip ahead. Progress is tied to calendar days, not hours spent online.

That cap matters for a VPN in particular. We didn't want a system that rewards leaving the tunnel on 24/7 "for the points." Two pieces a day, earned early, means a normal day of use is enough to progress.

Structure: chapters and collections

Stamps are organized on two axes.

Chapters give the passport a progression arc:

Origin: the first 10 countries (Sweden, Germany, Japan, the US and others).
Horizons: 10 more (Norway, Canada, Turkey, Australia and others).
Legacy: the mastery layer. Get every stamp to gold, then every stamp to diamond.

Collections group countries by theme: Nordic, Baltic, Across the Atlantic, Heart of Europe and Pacific Rim. Completing one unlocks its cover and seal. There's also one hidden collection, which we're not going to explain here.

On top of that come weekly expeditions (three small goals per week), achievements and titles, selectable passport covers and app icons.

Design rule #1: count minutes on the server, not the client

The first technical decision was where progress gets measured.

If the app counted connection time, the system would be trivially gameable. You could patch the client, fake the clock or replay a request. Trusting the client for rewards is a well-known anti-pattern in game development.

So connection minutes are counted by Colitu's servers, not by the apps. The VPN server already knows a tunnel is up, so it's the natural source of truth. The client only displays what the server has already decided.

This also gives us cross-platform consistency for free. The passport lives in the account, not on the device. Connect from your phone in the morning and your laptop at night, and the progress lands in the same passport. The feature ships on Android, iOS, Windows and Linux at the same time.

Design rule #2: store totals, never sessions

This is where a VPN differs from every other gamified app.

A typical engagement system logs events like user X connected to server Y at 14:02 for 37 minutes. That's exactly the kind of record a privacy-focused VPN should never create, even with good intentions.

So the passport keeps only aggregate counters. There's no per-minute record and no per-session log. Conceptually, the stored state looks more like this:

passport
├── stamps:   { country → tier, pieces }
├── today:    { pieces_earned: 0..2 }
└── profile:  { nickname, collector_no, title, cover }

and not like this:

connections: [ { country, start, end, duration }, ... ]   ← we don't keep this

The difference is that totals tell you how far someone has progressed. They don't tell you when or how they used the VPN. You can't rebuild a timeline from "Germany: Silver, 7 pieces."

When you delete your account, the passport is deleted with it. There's no separate archive and no "anonymized" copy.

Design rule #3: no dark patterns

Gamification has a bad reputation, and it's mostly earned. Loot boxes, streak anxiety and pay-to-win make the experience worse for users. We wrote down what we would not build before we wrote any code.

No randomness you can pay for. There are no loot boxes and no random paid rewards. Every reward is deterministic: you know exactly what you'll get and when.

No streak punishment. Skip a day, a week or a month and you lose nothing. There are no penalties and no broken streaks. Progress simply waits for you. We think a VPN should never make you feel guilty for not using it.

No paywall on collecting. The free plan can collect every stamp. Paid plans only change the passport cover color. That's a cosmetic difference, not a progression advantage.

These rules shaped the architecture as much as the UX. For example, a daily cap of 2 pieces plus no streak penalties means the system needs very little state. There's no streak counter, no "last active" timestamp to punish and no decay job.

Social without a social graph

We wanted people to be able to compare passports, but we didn't want to build a friend list, follower system or leaderboard. Each of those adds a social graph that has to be stored and protected.

So comparison works in person, via QR code. Your app shows a QR code that encodes a summary of your passport. A friend scans it, and the app shows the two passports side by side.

No friend relationship is stored. There's no lookup by username and no public profile. The comparison happens at the moment of the scan, between two people standing next to each other.

The visual language

Each stamp is a small illustration of a landmark: Helsinki Cathedral for Finland, the Brandenburg Gate for Germany and so on. Each one is rendered in the material of its tier. Bronze, silver and gold are metallic finishes, and diamond turns the whole stamp into faceted crystal. Collection seals use a more classic, engraved, banknote-style treatment.

The goal was for the passport to feel like an object worth keeping, not like a badge system attached to a settings screen.

What we learned

A few takeaways for anyone adding engagement mechanics to a privacy-sensitive product:

Decide what you won't store before you decide what to show. Our data model came from the privacy constraint, not the other way around.
Server-side counting solves cheating and sync at once. If the server is already the source of truth, use it.
Daily caps beat open-ended grinding. They respect users' time and keep the system cheap to run.
Removing punishment removes state. No streaks meant less data, less code and less anxiety.
Social features don't require a social graph. A QR code exchanged in person can replace a whole friend system.

Try it

Colitu Passport is live on Android, iOS, Windows and Linux. Connect to a country, wait five minutes and you'll have your first stamp.

👉 colitu.com/en/passport

We'd love to hear how others approach gamification in privacy-focused products. What would you add, and what would you never build?

Our Hysteria2 connections died after every upload speed test. The fix was 37 lines.

Colitu VPN — Thu, 15 Oct 2026 23:46:44 +0000

We build Colitu, a VPN with open-source apps for Android, iOS, Windows, Linux and a browser extension. The apps carry traffic over several transports. Hysteria2 is a QUIC-based one that our apps prefer on many networks, because it holds up well on lossy mobile links.

The apps also check their own connection. Every 5 seconds they send a small request through the tunnel. If three checks in a row get no answer within 4 seconds, the transport is declared dead, and traffic moves to a TCP spare that is already connected. Users stay online. But a transport that keeps getting declared dead is a bug, even if nobody notices.

How we noticed

We were testing port hopping for Hysteria2 on an Android phone on home Wi-Fi. With port hopping, the client moves to a new UDP port every ~30 seconds, so networks that slow down long-running UDP flows have a harder time doing it.

Hopping itself worked. We saw five hops, and the server's replies arrived on every new port.

Then we ran a speed test. Hysteria2 carried traffic for about 50–60 seconds and then stopped for good. The health check gave up and traffic went to the spare. It happened every time.

We repeated the test on a server without port hopping and got the same result. So hopping was not the cause; it was just the test that showed the bug.

What the packets said

We captured traffic on the phone. After the stall:

the QUIC connection was alive: ACKs and small control packets went both ways;
UDP datagrams still flowed: DNS and the apps' own QUIC traffic, which Hysteria carries as datagrams;
the client sent no new TCP stream data at all, not even for brand-new requests;
the server logged nothing unusual.

A connection that is alive but will not send stream data points at flow control, not at the network.

What we ruled out first

We tested each of these instead of assuming:

Suspect	How we tested it	Result
ISP shaping UDP	read the capture	packets kept flowing both ways; the client stopped sending
Probe starvation under load	watched after the load ended	the stall lasted for minutes after the load was gone
Congestion control	A/B build with Reno instead of BBR	died the same way
Xray's "Chrome parrot" QUIC mode	A/B build with it disabled	died the same way
Stream limit	counted streams	~90 open against a limit of 1,024
Many connections in general	1,400 short sequential connections	all fine

One more thing we tried: a bigger flow-control window (64 MB per connection, 4 MB per stream). It did not fix anything. It only delayed the stall: with 6 parallel streams it failed in round 3, with 20 streams immediately. That was the strongest hint about where to look.

Reproducing it on one PC

To get rid of the network entirely, we built the official Hysteria server v2.11.0 from source and ran it on loopback with an Xray 26.10.10 client. A small Python harness opened parallel uploads through the client, aborted them with a TCP reset, and then checked whether new requests still worked.

The only thing we changed between runs was how the upload's destination behaved:

Target mode	What the destination does	Connection stalled?
`fast`	reads everything	no
`slow`	reads 1 MB/s	no
`upclose`	closes the connection first	no
`stall`	stops reading but keeps the connection open	yes: 0 of 5 new requests worked, no recovery in 30 s

An upload speed test behaves exactly like stall. The test server stops reading once it has measured enough, while the browser's upload request is still open.

The mechanism

QUIC limits how much unread data a peer may have in flight, per stream and for the whole connection. Hysteria's defaults are 8 MB per stream and 20 MB per connection. Received bytes count against both windows until the application actually reads them.

Here is what happens:

client (Xray)                 Hysteria server                 target
     |  upload on stream A  ->  |  io.Copy(target, stream A) -> |
     |                          |                               |  stops reading,
     |                          |  target's TCP buffer full     |  keeps conn open
     |                          |  write to target BLOCKS       |
     |                          |  -> server stops reading A    |
     |  A's unread bytes keep counting against the connection window
     |  (a few streams like A fill all 20 MB)
     |
     |  new request on stream B: blocked, no connection credit left
     |  writer for A: blocked on the same window, so the client
     |  never gets to cancel A either
     |
     |  UDP datagrams: not flow-controlled -> still flowing

The client uploads through a Hysteria2 stream. The server dials the target over TCP and copies the stream into it.
The target stops reading but does not close. Its receive buffer fills, the server's Write into the target blocks, and the server stops reading from the stream.
The stream's unread upload data keeps occupying the connection-level receive window. A few such streams use up the whole window. From then on the client cannot send on any stream of the connection, including brand-new ones.
The client never gives the stream up, because its own writer is blocked on the same window. On an instrumented server, the "stream given up" signal only arrived when we killed the client process.
UDP datagrams are not covered by stream flow control, which is why DNS kept working and the connection looked healthy.

Interesting detail: we first suspected the server never calls CancelRead on dead streams. That was wrong. The stream's Close already does that. The real problem is that nothing ever reaches that Close, because the copy into the target is stuck in a blocking Write.

The fix

The server cannot tell a stalled target from a slow one by looking at the stream. It can tell by progress: a single write that makes no progress for a long time.

So the patch does two things:

Every write into a TCP target gets a fresh 10-second budget. If one write makes no progress for 10 s, the target is closed. The normal cleanup then closes the stream, which releases its share of the connection window.
When the client gives the stream up, the target is closed immediately, so both copy directions end even when the target is silent.

A slow target that keeps moving is never cut off, because every write starts a new timer. Only a target that has stopped accepting data is closed.

This is the version we sent upstream in PR #1703:

if h.config.TCPStallTimeout > 0 {
    guard := newStallGuardConn(tConn, h.config.TCPStallTimeout)
    tConn = guard
    stop := context.AfterFunc(stream.Context(), func() { _ = guard.Close() })
    defer stop()
}

// stallGuardConn closes the wrapped connection when a single Write makes no
// progress for timeout, and makes Close idempotent. Every Write gets a fresh
// timeout, so a slow target that keeps accepting data is never closed.
type stallGuardConn struct {
    net.Conn
    timeout   time.Duration
    timer     *time.Timer
    closeOnce sync.Once
    closeErr  error
}

func newStallGuardConn(conn net.Conn, timeout time.Duration) *stallGuardConn {
    c := &stallGuardConn{Conn: conn, timeout: timeout}
    c.timer = time.AfterFunc(timeout, func() { _ = c.Close() })
    c.timer.Stop()
    return c
}

func (c *stallGuardConn) Write(p []byte) (int, error) {
    c.timer.Reset(c.timeout)
    n, err := c.Conn.Write(p)
    c.timer.Stop()
    return n, err
}

func (c *stallGuardConn) Close() error {
    c.closeOnce.Do(func() { c.closeErr = c.Conn.Close() })
    return c.closeErr
}

Our production build (v2.11.0-colitu1) does the same thing with SetWriteDeadline before each write. For the upstream version we made three changes:

the check closes the connection from a timer, so it only needs Close and works with any net.Conn an outbound returns;
the timeout is configurable as server.Config.TCPStallTimeout (default 10 s, negative disables it);
Close is idempotent, because two paths can now close the target.

The PR also adds an integration test. Four streams upload into targets that never read (one end of a net.Pipe()), then a new request to an echo server must complete on the same connection. Without the fix it times out after 10 s. With it, it passes in about 3.5 s, with the stall timeout set to 2 s for the test.

One gotcha while writing that test: with one stalled stream it passed even without the fix. One stream can only fill its own 8 MB window, not the 20 MB connection window. It takes three or four.

Results

In the loopback lab:

Server	Target	Streams	New requests work again after
official v2.11.0	`stall`	6	never (> 30 s)
patched	`stall`	6	7.8 s
patched	`stall`	20	7.8 s
patched	`fast` / `slow` / `upclose`	—	0.0 s (no regression)

On the phone, we ran four speed tests in a row over 160 seconds on a patched server in Berlin. Hysteria2 was never declared dead. Before the patch it died at ~60 s every time, both in Berlin and on a server in Vilnius.

Rollout without an app update

Because the bug was on the server, the fix did not need a new app release. Our node image now builds Hysteria from the official source tag with the patch applied. We rolled it out the same night, one server at a time. Each server's VPN service restarted for about 2 seconds. Android, iOS, Windows and Linux users all got the fix at once.

Upstream

The bug is in the open-source Hysteria server, and its client-side half is in Xray, so every service that runs them is affected, not only ours. We reported both:

HyNetworks/hysteria#1702: the bug, how to reproduce it, and everything we ruled out.
HyNetworks/hysteria#1703: the fix on the current development branch, with the configurable timeout and the integration test.
XTLS/Xray-core#7169: the client side. A client that cancels the write side of a stream it no longer needs (CancelWrite, i.e. RESET_STREAM) would release the window even on servers without the fix. A contributor has since traced it on Xray's main branch, reproduced the stall on loopback, and plans a CancelWrite-based fix.

Limitations

The lab runs on loopback: no packet loss, no added latency. It shows the mechanism and the effect of the patch, not real-world timings.
The device result is one phone on one network, four speed tests over 160 seconds. Encouraging, not a long-term measurement.
For up to 10 seconds before the timer fires, TCP over that connection can still pause. The patch makes the stall short; it does not make it zero. A client-side fix would complement it.

Takeaways

"Connected but silent" usually means flow control. If ACKs and datagrams flow but stream data doesn't, look at windows before you blame the network.
A bigger window that only delays a failure is a clue, not a fix.
Make the destination's behaviour a test variable. Four target modes (fast, slow, upclose, stall) narrowed this down faster than any amount of packet reading.
Write the test that fails first. Ours passed until we used enough streams to exhaust the connection window, which taught us something about the bug itself.

If you run Hysteria2 and your users see TCP die after big uploads while DNS keeps working, this is probably it. The PR is small and easy to apply to v2.11.0.

Full report with setup details: lab.colitu.com/research/hysteria2-stall-after-upload. Our apps are open source at github.com/colitu. Questions and corrections are welcome in the comments.

We Broke Our VPN on Purpose: 11 Network Failures, 29 Servers, and What Adaptive Connect 2.0 Taught Us

Colitu VPN — Sat, 10 Oct 2026 06:04:37 +0000

An engineering deep dive into fault injection, silent VPN failures, protocol recovery, warm spare reliability, and the uncomfortable difference between implementing a fix and proving it works.

By Colitu Engineering | October 10, 2026

A VPN Can Be Connected and Still Be Broken

There is a particularly frustrating kind of network failure.

Your VPN application says Connected.

The tunnel is established. The process is running. The connection has not been explicitly terminated.

But websites stop loading. Messages remain undelivered. Requests time out.

From the operating system's perspective, the connection may still exist. From the user's perspective, the internet is gone.

This is one of the problems we are trying to solve with Colitu Adaptive Connect 2.0.

Modern restrictive networks do not always block connections outright. Some allow the initial handshake, exchange a small amount of data, and then silently stop forwarding traffic.

Others selectively interfere with UDP, terminate particular TCP connections, introduce packet loss, or make an otherwise healthy server temporarily unreachable.

Supporting multiple protocols is useful, but it does not automatically solve these problems.

A fallback system can select the wrong alternative. A health monitor can mistake an established socket for a working connection. A backup tunnel can silently die without being replaced.

And sometimes the mechanisms designed to improve reliability become the reason recovery takes longer.

We wanted to understand these failures at the level where they actually happen.

So we built a fault-injection experiment around a real Android device on a restrictive residential network in Russia.

We deliberately broke its network paths.

Then we watched how Adaptive Connect responded.

The experiment exposed two important flaws in our recovery logic. We implemented fixes, but the subsequent device test did not conclusively exercise either fix.

That distinction is central to this report.

This article explains what we tested, what failed, what we changed, and what still needs to be verified.

The original research, including the raw measurements, is available at Colitu Lab.

1. The Engineering Problem: Connectivity Is Not a Boolean

Many networking applications treat connectivity as a relatively simple state:

Connected
Disconnected

Real network behavior is considerably more complicated.

A useful connection is not merely one that successfully negotiated a transport.

It must continue carrying application traffic.

Consider a simplified connection lifecycle:

CONNECTING
    |
    v
HANDSHAKE SUCCESSFUL
    |
    v
TUNNEL ESTABLISHED
    |
    v
APPLICATION TRAFFIC WORKING
    |
    v
TRANSPORT STALLS
    |
    v
SOCKET STILL APPEARS CONNECTED
    |
    v
APPLICATION TRAFFIC FAILS

The dangerous transition happens between the last three states.

The transport may remain established even though it is no longer useful.

If the application relies on connection status alone, it may never recognize the failure promptly.

The restrictive-network problem

Our test environment exhibited a particularly interesting behavior.

Several TCP-based VPN transports could establish connections successfully, but traffic stopped progressing approximately 30–50 seconds later.

Hysteria2, which uses UDP, remained functional under the observed baseline conditions.

This created an unusual recovery problem.

The fallback system had several transport options available, but most of them could not sustain traffic on that network.

A successful handshake was therefore not sufficient evidence that a fallback would work.

Why adding more protocols is not enough

Suppose a client supports four transport options:

Hysteria2
VLESS Reality
Trojan
VLESS XHTTP

At first glance, this appears to provide considerable redundancy.

But imagine the following network conditions:

Hysteria2       WORKING
VLESS Reality   CONNECTS -> STALLS
Trojan          CONNECTS -> STALLS
VLESS XHTTP     CONNECTS -> STALLS

The client has four choices, but only one is useful.

If the working transport fails temporarily, blindly cycling through the other three may prolong the outage.

Even worse, a cooldown mechanism might prevent the client from returning to the only transport that can actually carry traffic.

Protocol diversity provides opportunities for recovery. It does not guarantee recovery.

This distinction shaped our fault-lab design.

2. Why We Built a Fault-Injection Lab

Traditional connectivity tests answer questions such as:

Can the client connect?
Does the server respond?
Can the tunnel carry a request?
What is the latency?

Those are useful measurements.

They are also insufficient for evaluating a system that claims to recover from failures.

We needed answers to harder questions.

What happens when the active protocol disappears?

How quickly does the client detect a tunnel that has silently stopped forwarding data?

Does a backup connection actually survive until it is needed?

If a network restriction is removed, how quickly does the client return to a working transport?

Can a recovery mechanism accidentally prevent its own recovery?

These questions are difficult to answer using ordinary uptime monitoring.

A server can remain healthy while a particular client's route to that server is unusable.

A connection can remain established while application traffic is broken.

And a failure may last only long enough to affect a user without appearing in coarse monitoring data.

We therefore designed a controlled fault-injection suite.

Experimental environment

Parameter	Configuration
Application	Colitu for Android
Baseline version	2.8.0
Test-build version	2.8.0+ac2fix
Device	VIA E30, Android 11
Network	Residential Wi-Fi in Russia
Connection mode	Automatic
Servers in scope	29
Failure scenarios	11 in the baseline suite
Fault duration	90–120 seconds
Traffic probe	HTTP request through VPN every 5 seconds
Measurement	Probe success and interruption duration
Test date	October 10, 2026

We selected a real device rather than relying solely on a simulated VPN client.

That matters because actual devices generate background traffic, change connection states, and interact with the networking stack in ways that simplified test environments may not reproduce.

As we discovered, ordinary background traffic was enough to expose one of our bugs.

3. How the Fault Lab Works

The fault injector operates through controlled firewall rules on Colitu infrastructure.

For each scenario, rules are applied to the relevant servers, targeting the test connection's public IP address.

Every rule is tagged so that it can be identified and removed.

Server-side expiry timers provide an additional safety mechanism: faults are not intended to persist indefinitely if the controlling process fails.

The test device continues sending real HTTP requests through its VPN tunnel at five-second intervals.

The experiment records:

Whether each request succeeds.
The longest observed interruption during the fault and its recovery window.
The first successful request after fault injection begins.
The time until successful traffic is observed after the fault is removed.

The following diagram illustrates the measurement approach.

             ANDROID TEST DEVICE
                     |
                     |
             Adaptive Connect
                     |
                 VPN Tunnel
                     |
                     v
             COLITU SERVERS
                     |
             Fault Injector
                     |
       +-------------+-------------+
       |             |             |
   Drop UDP      Reset TCP     Drop Server
       |             |             |
       +-------------+-------------+
                     |
                     v
              HTTP PROBES
              Every 5 sec
                     |
                     v
               RESULT LOG
                     |
          +----------+----------+
          |          |          |
       Success    Outage     Recovery
         Rate     Duration      Time

The fault injector and the traffic probes are conceptually separate.

The injector changes network conditions.

The probe system measures the resulting user-visible connectivity.

This separation is important: a successful control operation does not necessarily mean that the intended application path was disrupted.

The experiment must verify both.

Eleven failure scenarios

The baseline suite covered the following conditions:

Scenario	Injected failure
1	Block Hysteria2 on all servers
2	Block VLESS Reality
3	Block Trojan
4	Inject TCP resets into VLESS Reality
5	Freeze TCP flows after 16 KB
6	Block UDP across all servers
7	Introduce 5% packet loss
8	Introduce 20% packet loss
9	Attempt a selected-server outage
10	Cut the server carrying the active tunnel
11	Block VLESS XHTTP

The suite contains several distinct failure classes.

Protocol blocking tests whether a client can recover when a transport family becomes unavailable.

TCP resets model abrupt connection termination.

The 16 KB freeze models a more subtle situation: an initial exchange succeeds, then forwarding stops.

Packet loss examines behavior under degraded transport conditions.

Server removal tests whether the client can recover when the problem is not limited to a specific protocol.

Not every injected fault is expected to interrupt active traffic.

If the user is connected through Hysteria2 and Trojan is blocked, the existing connection may remain entirely unaffected.

That is not a failed experiment.

It is an important distinction between injecting a fault and causing an outage.

4. Baseline Results: Android 2.8.0

We began with the released Android application running Adaptive Connect 2.0.

The results immediately revealed areas requiring investigation.

Overall results

Metric	Baseline result
Total HTTP probes	466
Successful probes	397
Failed probes	69
Probe success rate	85.19%
Longest observed outage	100.2 seconds
Unrecovered scenarios	0

A success rate of 85.19% is not particularly impressive in isolation.

But this was not a normal-usage benchmark.

The network was deliberately disrupted, repeatedly, using several different failure mechanisms.

The important question was not simply how many requests succeeded.

It was why particular interruptions lasted as long as they did.

Outage breakdown

Injected failure	Longest observed outage
Hysteria2 blocked globally	95.2 s
VLESS Reality blocked	25.0 s
Trojan blocked	0 s
VLESS Reality TCP resets	0 s
TCP frozen after 16 KB	0 s
UDP blocked globally	100.2 s
5% packet loss	0 s
20% packet loss	0 s
First selected-server scenario	0 s
Active server removed	45.1 s
VLESS XHTTP blocked	0 s

The zero-second entries require careful interpretation.

They indicate that the measurement did not observe a sustained interruption under the corresponding fault.

They do not establish that a protocol or application is immune to that class of failure.

With five-second probes, sufficiently short interruptions can also be missed.

Two failures stood out:

The unusually slow return after UDP became available again.

The prolonged interruption when the active server disappeared.

We investigated both.

5. Failure #1: A Cooldown That Delayed Recovery

One of the most revealing results came from the global UDP block.

The injected fault lasted 120 seconds.

The longest observed interruption was approximately 100 seconds.

More importantly, after the fault was removed, traffic did not resume immediately.

Recovery took approximately 31 additional seconds.

This was particularly interesting because Hysteria2 had previously been the transport that worked on the network.

Why was the application not returning to a known-good transport promptly?

The ten-minute penalty

When Hysteria2 stalled in the middle of an established session, Adaptive Connect placed the transport at the back of that server's candidate list for ten minutes.

The intention was reasonable.

If a transport fails, avoid repeatedly selecting it and entering an endless failure loop.

However, the observed network conditions made that policy problematic.

Hysteria2 had been the only transport capable of sustaining traffic in the original environment.

The alternative TCP transports could establish connections, but subsequently stalled.

The client therefore spent time exploring alternatives that could not reliably carry traffic.

Meanwhile, the transport that had demonstrated actual connectivity remained penalized.

When failure memory becomes harmful

This illustrates a broader networking problem.

A recovery system needs memory.

Without it, the client may repeatedly choose the same failing route.

But memory can become harmful when it does not distinguish between different kinds of failure.

Consider the difference between:

A transport that has never successfully worked on the current network.
A transport that previously worked and then failed during a temporary restriction.

These situations should not necessarily receive identical penalties.

The first may indicate a fundamentally unsuitable route.

The second may indicate a temporary condition that has already disappeared.

Treating both equally can delay recovery.

The additional missed-probe problem

The logs exposed a second timing issue.

Adaptive Connect enforced a 60-second minimum interval between automatic switches.

That interval was intended to avoid excessive switching.

However, the missed-probe counter was being reset before the minimum interval was evaluated.

The consequence was subtle.

A tunnel could already be demonstrably broken, yet the client would wait for the switching interval.

After the interval ended, the client still required three more missed checks before initiating another switch.

In other words, the system could spend time rediscovering a failure it already knew about.

The changes we implemented

We adjusted the recovery logic in two ways.

1. Shorter penalties for previously successful transports

A transport that has already worked on the current network now receives a 90-second mid-session penalty in the test build.

Other transports retain the ten-minute penalty.

The intent is to preserve caution around historically unsuccessful paths while allowing previously functional transports to return sooner.

2. Miss counters continue through the switching interval

Missed checks are no longer discarded merely because the minimum switching interval has not yet elapsed.

When that interval expires, the client can act on accumulated failure evidence rather than restarting the detection process.

Conceptual illustration

The following pseudocode illustrates the policy difference. It is explanatory, not a copy of Colitu's production implementation.

def failure_penalty(transport, network):
    if transport.previously_worked_on(network):
        return 90  # seconds

    return 600  # seconds


def should_switch(health, elapsed_since_switch):
    if health.consecutive_misses < 3:
        return False

    if elapsed_since_switch < 60:
        return False

    return True

The key idea is that health.consecutive_misses remains meaningful while switching is temporarily restricted.

It should not be reset simply because the application is observing a minimum transition interval.

The deeper lesson

A cooldown is not a substitute for understanding the failure.

Recovery policy must balance the risk of retrying too aggressively against the risk of excluding the only usable path.

The correct answer depends on what the transport has demonstrated on the current network.

6. Failure #2: Our Warm Spare Was Dead When We Needed It

Adaptive Connect 2.0 includes a warm spare mechanism.

The basic design maintains a primary path and a backup path within the running VPN connection.

When the primary path stops working, traffic can move to the backup without requiring a full VPN disconnect-and-reconnect sequence.

At least, that is the intended behavior.

A simplified architecture looks like this:

                 DEVICE
                    |
                    v
              VPN BALANCER
                    |
          +---------+---------+
          |                   |
          v                   v
      MAIN PATH          WARM SPARE
          |                   |
          v                   v
       Server A             Server B
          |                   |
          +---------+---------+
                    |
                    v
                 INTERNET

The backup provides useful redundancy only if it remains healthy.

And this is where our implementation encountered a problem.

The observed failure

During the baseline test, we deliberately removed the server carrying the active tunnel.

The client experienced a 45-second interruption.

When we inspected the logs, the relevant backup path was already dead.

It had not been replaced.

The system had a warm spare mechanism, but it did not have a usable spare at the moment of failure.

Why the spare was not replaced

Replacing a spare requires reloading part of the underlying connection core.

That operation can cause a brief interruption.

We therefore designed the application to prefer an idle moment before replacing a dead spare.

The original threshold required less than 10 KB of traffic over a ten-second interval.

This was intended to protect active user sessions.

However, the test device was not truly idle.

Background synchronization, application traffic, and connectivity checks generated approximately 15–30 KB over each ten-second observation window.

This was enough to keep the replacement operation deferred.

And deferred.

And deferred again.

The application was trying to avoid disrupting traffic.

As a consequence, it indefinitely postponed restoring redundancy.

A liveness problem hidden inside a safety mechanism

This is a classic engineering tradeoff.

We wanted to preserve two properties:

Safety: Avoid interrupting useful foreground traffic during backup replacement.

Liveness: Eventually restore a healthy backup after the current one fails.

Our original idle rule favored safety so heavily that liveness was not guaranteed.

Under persistent low-volume background traffic, there might never be an eligible replacement window.

The backup could remain unavailable indefinitely.

Our revised replacement policy

The test build introduces a more flexible rule.

Initially, the application still prefers an idle moment.

However, after waiting two minutes, light traffic no longer prevents replacement.

The revised threshold allows replacement below 32 KB per ten-second window.

This is not a guarantee that every replacement will be invisible.

It is an attempt to balance the risk of a brief maintenance disruption against the greater risk of remaining indefinitely without a working backup.

Why this matters beyond VPN software

The same failure pattern can appear in many fault-tolerant systems.

Imagine a database replica that is never rebuilt because the primary system is never fully idle.

Or a service worker that is never replaced because the application continuously receives a small amount of traffic.

Or a load balancer that indefinitely delays restoring a failed backend.

In each case, a mechanism intended to reduce disruption can prevent the system from returning to a resilient state.

Redundancy is not only about having a backup. It is about continuously maintaining the conditions that make the backup usable.

That is the engineering principle this failure exposed.

7. A Separate Windows and Linux Finding: Network Memory Must Have Boundaries

Adaptive Connect maintains information about transport behavior on different networks.

That memory helps the application avoid repeating known failures.

For example, a protocol that fails on a restrictive mobile network may still work perfectly well on home Wi-Fi.

Those environments should not share the same recovery assumptions.

A separate Windows investigation exposed a problem with how previous network state could influence a newly joined network.

Information such as stalled transports and the last successful transport could persist into a different network context.

We changed the relevant Windows and Linux source logic so that failure history from the previous network is not applied to the new one.

These changes are covered by unit tests.

However, they were not validated by the Android fault-injection experiment described here.

That distinction matters.

The existence of unit tests supports confidence in specific implementation behavior.

It does not establish end-to-end reliability across every operating system or network transition.

A complete evaluation still requires device-level testing of Wi-Fi changes, mobile handovers, and other transitions.

8. The Second Run Looked Dramatically Better

After implementing the changes, we ran the suite again using a test build.

The top-level results were striking.

Metric	Released 2.8.0	Test build
HTTP probes	466	526
Successful probes	397	518
Success rate	85.19%	98.48%
Longest outage	100.2 s	35.1 s
Unrecovered scenarios	0	0

Some of the individual failure results also appeared substantially better.

Failure	Released app	Test build
Hysteria2 globally blocked	95.2 s	0 s
VLESS Reality blocked	25.0 s	0 s
UDP globally blocked	100.2 s	0 s
Active server removed	45.1 s	35.1 s

It would be tempting to publish this table with a headline such as:

Our fixes increased connectivity from 85% to 98%.

That would be an unsupported conclusion.

And the reason is important.

The two runs did not start from equivalent conditions

During the second run, the device had settled on a different server.

On that server, a TCP-based transport was functioning.

The initial restrictive-network behavior was therefore not equivalent to the first run.

When Hysteria2 was blocked, the device did not need Hysteria2.

When UDP was blocked, the active TCP connection continued carrying traffic.

These faults therefore did not recreate the condition that exposed the original cooldown problem.

The improved numbers are real observations.

But they are not proof that the cooldown fix caused the improvement.

The warm spare fix was not exercised either

During the second run's active-server outage, the logs once again showed that the spare was unavailable.

The client experienced an interruption of approximately 35 seconds.

The revised spare-replacement mechanism did not get the opportunity to demonstrate the intended recovery behavior.

As a result, this experiment cannot verify that the revised idle threshold solves the original problem on the device.

One scenario was skipped

The second run also did not execute every intended server-removal scenario.

One additional active-server cut was skipped because the test tool could not identify the tunnel on a listed server during its capture window.

That limitation is recorded in the raw result file.

The second run therefore has a different number of executed fault episodes from the first run.

It is not a perfectly matched before-and-after comparison.

What we can legitimately conclude

The second run provides evidence that the test build continued functioning under the faults it actually encountered.

It did not reveal a new failure in those observed conditions.

However:

The revised Hysteria2 recovery policy was not conclusively validated.
The revised warm spare replacement policy was not conclusively validated.
The two probe-success percentages cannot be attributed solely to the code changes.
The second run is not a controlled A/B comparison.

A better benchmark result is not the same thing as verified causality.

This is perhaps the most important methodological lesson from the experiment.

9. We Also Found Problems in the Test Infrastructure

Fault injection tests application behavior.

But they also test the assumptions made by the people designing the experiments.

Our first attempts exposed several problems in the testing infrastructure itself.

Problem A: Incomplete server coverage

An early version of the suite targeted eight servers.

The client eventually moved to a server outside the target list.

Subsequent injected faults did not affect the active tunnel.

The test tool continued working, but the experiment no longer exercised the intended application path.

We expanded the target scope to all 29 servers the test device could select.

We also added logging to identify which server was carrying the tunnel before each fault.

This provides a basic but essential validation step:

Did the experiment actually affect the intended target?

Problem B: Public-IP targeting and NAT

The firewall rules targeted the test device's public IP address.

This seemed like a convenient way to isolate traffic belonging to a particular experiment.

However, multiple devices on a residential network can share the same public IP through NAT.

During testing, other computers in the same home also experienced connectivity interruptions.

This did not imply that unrelated Colitu customers elsewhere were affected.

It did reveal that public-IP isolation was not equivalent to individual-device isolation.

The operational procedure was adjusted to announce fault runs in advance and move the control workstation to a server excluded from the experiment.

This limitation should remain explicit in any description of test safety.

Problem C: Sequential fault application

When a failure must affect many servers, sequentially applying firewall rules introduces timing differences.

One server may start dropping packets before another.

If an operation hangs, the entire sequence may stall.

We updated the control mechanism to apply server-side changes in parallel.

The tooling also supports continuing from a selected fault after interruption.

This improves consistency and operational robustness.

It does not eliminate every source of timing uncertainty, but it makes the injected scenarios more controlled.

10. What This Experiment Taught Us About Failover Design

Beyond the individual bugs, the experiment revealed several general principles.

Principle 1: A working socket is not evidence of a working network

Health checks should verify actual application-level progress.

A handshake is useful evidence.

An open socket is useful evidence.

But neither establishes that payload traffic can continue flowing.

This is especially important when failures are silent rather than explicit.

Principle 2: Recovery policy must remember context

A route that has never worked should not necessarily be treated like one that worked successfully until a temporary outage.

Failure memory must reflect observed behavior on the relevant network.

Otherwise, a policy intended to prevent repeated failures may accidentally prolong them.

Principle 3: Backup availability is a continuously maintained property

A spare path is not useful simply because it existed at some point.

It must remain healthy and be replaced when necessary.

Backup maintenance requires its own monitoring and eventual recovery guarantees.

Principle 4: Avoid treating idle time as a guaranteed event

Real devices are rarely completely quiet.

Background synchronization, health checks, notifications, and system services may generate continuous low-volume traffic.

Maintenance operations that require perfect idleness can suffer indefinite postponement.

Principle 5: The active network path matters more than the protocol list

Blocking an unused protocol may have no effect on the user.

Blocking the only viable transport may produce an unavoidable outage.

A meaningful fault-injection report must record the active transport and server before and during each scenario.

Without that context, the results can be misleading.

Principle 6: Recovery cannot create a working route where none exists

During the baseline experiment, the network already exhibited widespread TCP transport freezes.

When Hysteria2 was also unavailable, the client could temporarily have no usable route.

No fallback policy can guarantee continued connectivity if every available path is unusable.

The engineering objective is therefore not to promise impossible availability.

It is to identify usable alternatives quickly, avoid unnecessary recovery delays, and restore traffic as soon as a viable path returns.

Principle 7: A successful test result must be interpreted against its starting state

Different network conditions can produce dramatically different results with identical software.

Controlled comparisons require equivalent initial state, including the active server, active transport, relevant failure memory, and injected fault.

Otherwise, a change in the environment can be mistaken for a change in software quality.

11. Designing the Next Experiment

The immediate priority is not producing another large success-rate figure.

It is verifying that the fixes actually address the failures they were designed to solve.

We see several important next steps.

Experiment A: Verify recovery after temporary UDP loss

The test should deliberately begin with Hysteria2 carrying traffic.

The sequence would be:

1. Establish a working Hysteria2 tunnel.

2. Verify continuous application traffic.

3. Block UDP to the relevant servers.

4. Confirm that Hysteria2 stops working.

5. Allow the client to enter its recovery process.

6. Remove the UDP restriction.

7. Measure the time until traffic resumes.

8. Inspect transport-selection and cooldown logs.

9. Repeat with the baseline and test builds.

The critical measurement is recovery behavior after the original usable route becomes available again.

We should compare the released version and revised version under equivalent conditions.

Repeated trials would help distinguish a consistent improvement from ordinary network variability.

Experiment B: Verify warm spare replacement

A separate test should target the spare-liveness problem directly.

The setup must ensure that the client initially has a healthy main connection and a healthy spare.

Then the experiment should deliberately make the spare unusable while the primary continues carrying traffic.

After that, the client should be observed under controlled background-traffic levels.

The essential questions are:

Does the client recognize that the spare has failed?
Does it attempt replacement?
Can background traffic postpone that replacement indefinitely?
Does the new threshold allow a replacement under light traffic?
Is the replacement itself disruptive?
Once a new spare is ready, does it carry traffic when the main path fails?

The last step is crucial.

A successful replacement log is not enough.

The replacement must demonstrate that it can perform its intended function.

Experiment C: Improve measurement resolution

Five-second HTTP probes provide a useful starting point.

They do not capture every short-lived interruption.

Future experiments could use more frequent probes and correlate them with transport-level events.

Useful metrics include:

Metric	What it tells us
Failure detection latency	How quickly the client identifies a broken path
Failover latency	Time between detecting a failure and selecting an alternative
Traffic restoration time	When application traffic becomes usable again
Backup readiness	Whether a healthy spare exists when needed
Recovery p50 / p95 / p99	Distribution of recovery times across repeated trials
Probe success ratio	Fraction of successful application requests
False-positive switches	Healthy paths abandoned unnecessarily
Switching frequency	Whether recovery policy creates excessive oscillation

A single maximum outage is useful.

A distribution across repeated, controlled trials is far more informative.

Experiment D: Validate the security properties during recovery

Connectivity is only one part of VPN reliability.

A future security-focused experiment should also measure what happens when the tunnel fails.

Important questions include:

Does the operating system ever send protected traffic outside the VPN?
Does the kill switch behave correctly during transitions?
Are DNS requests handled safely during recovery?
Can changing servers expose unexpected routing behavior?
Do failed connections leave temporary routing or firewall inconsistencies?

These measurements are not provided by the present fault-injection dataset.

They require their own test design and validation.

A system should not trade away its intended privacy guarantees merely to restore connectivity more quickly.

Experiment E: Expand platform coverage

The current experiment was performed on one Android 11 device.

That is valuable, but narrow.

A broader evaluation should eventually include:

Android devices with different networking stacks.
Windows under Wi-Fi and Ethernet transitions.
Linux under changing routes and interfaces.
iOS under mobile and Wi-Fi handovers.
Different network providers and filtering environments.

Platform-specific behavior matters.

A recovery mechanism that succeeds in one operating system's networking environment may behave differently in another.

12. Reproducibility Is Part of the Engineering Work

One reason we publish Colitu Lab research is to make the underlying measurements available for inspection.

For this experiment, the raw baseline and test-build results are published as JSON.

You can inspect the exact probe totals, fault definitions, durations, and recorded outages.

Raw data:

Research and methodology:

The GitHub repository contains broader VPN protocol experimentation resources. It should not be treated as proof that every script used in this particular Adaptive Connect regression experiment is already independently reproducible from that repository.

Complete reproduction requires the experiment-specific scripts, compatible infrastructure, configuration, and documented execution procedure.

Publishing result files is useful transparency.

Making the complete experiment repeatable by independent engineers is a further step.

Both matter.

13. What We Are Not Claiming

Technical reports become less useful when their conclusions extend beyond the evidence.

So it is worth stating explicitly what this experiment does not establish.

We are not claiming that Adaptive Connect delivers 98.48% availability across restrictive networks.

That number describes successful HTTP probes during one specific test-build run.

We are not claiming that the fixes reduced outages from 100 seconds to 35 seconds.

The two runs did not begin from equivalent network conditions.

We are not claiming that the warm spare replacement fix is verified on Android.

The second device run did not exercise the intended replacement behavior.

We are not claiming that eleven injected faults represent every real-world network restriction.

Real interference can involve more complex conditions, including latency manipulation, DNS behavior, route instability, and protocol-specific inspection.

We are not claiming that the Windows and Linux changes have passed equivalent live-network tests.

The changes described here were covered by unit tests, while this particular fault lab targeted Android.

Finally, the fixes described in this report were present in a test build at the time of the experiment.

They should not be confused with independently verified behavior across every released Colitu client.

These limitations do not make the experiment useless.

They define what its results can responsibly support.

14. Why We Believe Testing Failure Is More Valuable Than Demonstrating Success

It is relatively easy to demonstrate a successful VPN connection.

Open the application.

Select a server.

Connect.

Load a website.

That verifies an important basic function.

But it tells us very little about resilience.

The harder questions only appear when something goes wrong.

What if the server disappears after the connection has been established?

What if a transport works for 30 seconds and then silently freezes?

What if all UDP traffic is blocked?

What if a backup is unavailable when it is needed?

What if the network recovers, but the application's own cooldown policy delays reconnection?

These are the situations in which recovery architecture is tested.

And they are also the situations in which seemingly reasonable engineering assumptions can fail.

Our fault lab found a ten-minute transport penalty that was poorly suited to a particular recovery scenario.

It found a backup maintenance rule that could postpone replacement indefinitely.

It found limitations in the test infrastructure itself.

None of those findings is especially flattering when presented as a product benchmark.

But they are useful engineering results.

They identify specific behavior that can be changed, measured, and tested again.

More importantly, they help turn vague claims about reliability into concrete, falsifiable expectations.

Instead of saying:

The application automatically recovers from network failures.

We can ask:

When Hysteria2 is the only working transport and UDP becomes available again, how quickly does the client restore application traffic?

Instead of saying:

The application maintains a backup tunnel.

We can ask:

After the backup fails under continuous low-volume traffic, does the client eventually replace it, and can that replacement take over when the primary path disappears?

Those are questions that a serious fault-injection experiment can answer.

And if it cannot answer them yet, the report should say so.

15. Where Adaptive Connect Goes From Here

Adaptive Connect 2.0 is an attempt to make VPN connectivity more responsive to the conditions users actually encounter.

Its mechanisms include transport selection, network-specific failure memory, application-level health monitoring, server fallback, and warm spare recovery.

Each mechanism addresses a different part of the problem.

Together, they create a more complex system.

And complexity introduces interactions that are difficult to predict from isolated unit tests.

A transport penalty interacts with failure detection.

Failure detection interacts with switching intervals.

Backup maintenance interacts with ordinary device traffic.

Network memory interacts with interface transitions.

A useful test strategy must examine those interactions rather than evaluating each component only in isolation.

That is the direction we want Colitu Lab to pursue.

The next meaningful milestone is not a larger marketing number.

It is a controlled experiment demonstrating that the identified failure conditions are handled correctly by the revised implementation.

From there, the same methodology can be extended to more devices, more networks, and more realistic combinations of faults.

The long-term objective is straightforward:

When a usable network path exists, the client should find it, recognize when it stops working, and recover without unnecessary delay or loss of the protections users expect from a VPN.

That is an engineering objective, not a universal availability guarantee.

And it is something we can continue testing.

Final Thoughts

We began this experiment with a simple idea:

Break the network deliberately and measure what happens.

The baseline run produced 397 successful HTTP probes out of 466.

The revised test build produced 518 successful probes out of 526.

But the most useful results were not those percentages.

They were the two bugs found in the recovery logic, the implementation changes made in response, and the realization that the second experiment did not actually verify those changes under equivalent conditions.

That leaves us with unfinished work.

The Hysteria2 recovery adjustment needs targeted device validation.

The warm spare replacement policy needs a test that first kills the spare and then verifies replacement and takeover.

The experiment needs stronger control over its starting state.

And the measurement process can become more precise.

This is what meaningful reliability engineering often looks like.

Not a perfectly clean graph.

Not an uninterrupted sequence of successful demonstrations.

But a cycle of designing systems, breaking assumptions, examining evidence, correcting behavior, and testing again.

At Colitu, we want to keep publishing that process, including the parts that do not yet work as intended.

Because a VPN should not merely know how to connect.

It should know when its connection has stopped being useful.

And its recovery mechanisms should be tested just as aggressively as the networks they are designed to survive.

Built for networks that fight back.

Colitu — Connection Liberty Tunnel

Explore the research: Colitu Lab

Read the technical architecture: Adaptive Connect 2.0

Explore the project: colitu.com

Open-source networking experiments: github.com/colitu/vpn-lab

This article is based on Colitu Lab's October 10, 2026 fault-injection investigation. Results describe the measured experimental conditions and should not be interpreted as universal performance or security guarantees.

We Put Colitu's VPN Verification to the Test. Here's What Changed.

Colitu VPN — Sat, 10 Oct 2026 04:32:19 +0000

We Put Colitu's VPN Verification to the Test. Here's What Changed.

Good engineering gets stronger when people challenge it.

On October 10, 2026, a DEV Community member, @launchgatecheck, suggested an interesting test for Colitu's VPN connection verification system.

The question was simple but important:

What happens if a VPN handshake succeeds, but the tunnel itself cannot carry traffic? Could the application mistakenly report a working connection?

Rather than speculate, we reproduced the scenario, examined the results, made improvements, and published our findings through Colitu Lab.

The test

We built a controlled environment where a VPN server accepts the handshake but silently drops traffic inside the tunnel, while verification endpoints remain accessible through the normal internet connection.

We also examined automatic fallback between servers, DNS routing, and network changes.

The testing identified three areas requiring improvements.

What we improved

1. Tunnel-bound verification

We identified a case where certain follow-up verification requests could be affected by split-tunneling rules, potentially reporting a successful connection through the wrong route.

We corrected this behavior. Connection checks now use a dedicated, tunnel-bound verification path that cannot be redirected by ordinary routing rules.

2. Network transition recovery

We improved how the Windows application responds when the same Wi-Fi adapter connects to a different network.

Colitu now detects address and gateway changes, invalidates previous verification, and begins reconnecting within seconds.

3. DNS consistency

Our tests also revealed an opportunity to improve DNS handling on one Windows transport path.

We standardized tunnel adapter handling so DNS resolution follows the VPN tunnel across the tested Windows transports.

Released and documented

These improvements are available in Colitu Windows 2.8.4 and Linux 1.4.3, including fixes introduced in earlier releases.

Our published research includes the test methodology, results, technical changes, and testing limitations. Windows was tested on real devices; Linux verification used automated tests and the same fixture logic. Mobile platforms were outside the scope of this investigation.

Thanks to the community

Special thanks to @launchgatecheck for proposing the test scenarios that prompted this investigation.

This is exactly why we believe open technical discussion matters.

At Colitu, constructive criticism is an opportunity to validate assumptions, improve our engineering, and make our results publicly available.

Read the full technical research:

Colitu Lab — Does the connection check really go through the tunnel?

Colitu — Connection Liberty Tunnel

Built for networks that fight back.

Website | Research Lab

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

Colitu VPN — Sat, 10 Oct 2026 00:26:43 +0000

A connection is not proof of connectivity. Here's what we learned while building a VPN that has to survive networks that silently stop forwarding traffic.

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.

This is not a theoretical edge case.

While developing Colitu, an open-source VPN project focused on reliable connectivity in restrictive network environments, we encountered a frustrating failure mode: some transports connected successfully, then approximately 30–50 seconds later, application traffic stopped flowing.

The TCP connection remained open. The VPN appeared connected. But websites would not load.

Restarting the connection sometimes restored traffic, only for the problem to return.

A successful handshake wasn't enough. A low-latency server wasn't enough. Even a backup route wasn't enough if the health monitor misunderstood what was happening.

These experiences became the foundation of Colitu Adaptive Connect 2.0.

In this article, we'll cover the engineering decisions, the mistakes, the experiments, and the problems we haven't solved yet.

1. The problem: a tunnel that looks alive but isn't

Many VPN clients follow a familiar process:

Measure server latency.
Select a server.
Establish a tunnel.
Report that the VPN is connected.
Reconnect when the tunnel terminates.

That strategy assumes transport failure will be obvious. In restrictive networks, it often isn't.

On one network, we observed VLESS Reality, VLESS XHTTP, and Trojan connections successfully establish sessions and then stop carrying traffic after roughly 30–50 seconds. Hysteria2 continued working on the same network.

The important distinction is between transport state and application-level reachability.

A socket remaining open does not prove that useful traffic is passing through it.

This exposed a weakness in Adaptive Connect 1.x: in-session monitoring covered Hysteria2 but not every transport. We needed a health model based on what users actually depend on.

2. Verify real traffic, not just handshakes

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

Instead of relying exclusively on Colitu infrastructure, connection-time checks use established external connectivity endpoints to help distinguish three states:

State	Why it matters
Transport established	The protocol completed a connection attempt.
Application traffic verified	Actual requests can traverse the VPN.
Underlying network unavailable	The device itself may have lost access.

Each attempt has a bounded time budget. Failed candidates are followed by alternatives rather than endless retries. On Android, the UI presents a verification phase instead of immediately claiming success.

A critical detail: the primary route has its own verification path.

If normal traffic is already passing through a backup, a generic health check might report success even while the primary route is broken. The dedicated local-only verification entry point tests the primary route without letting the backup conceal a failure.

That distinction informs future transport decisions.

3. Give each network its own memory

A transport that fails on home Wi-Fi may work perfectly over mobile data. Adaptive Connect 2.0 keeps bounded, device-local history based on network context.

Observation	Retention
Last working server	24 hours
Last working transport per server	24 hours
Transport freeze marker	Normally up to 6 hours
Server-wide failure	30 minutes

The local history is capped at 200 entries.

These limits are intentional. A failed connection should affect subsequent ranking, but it should not make a transport permanently unusable.

Failure history should guide exploration, not make recovery impossible.

4. Learn from network conditions without collecting browsing history

Local memory helps a device make better decisions. Aggregated network observations can also help identify where particular transports are failing.

Adaptive Connect 2.0's reporting design uses:

HMAC-signed network tokens carrying country and ASN information, valid for 48 hours.
Hourly success/failure counters grouped by country, ASN, and transport.
Temporary keyed pseudonyms to count distinct devices.
Seven-day retention of aggregated counters.

This design does not require URLs visited, browsing history, or application payloads to produce transport recommendations.

For example, the ASN-level rule requires observations from at least five devices and a success rate below 20% over the previous 24 hours before deprioritizing a transport. With insufficient evidence, the system falls back to broader signals rather than declaring a protocol blocked.

These are engineering safeguards, not a claim of perfect anonymity or immunity to malicious telemetry.

5. Our first backup strategy was wrong

At first, transport diversity seemed like the natural basis for failover.

If the primary uses UDP, choose a TCP-based backup:

Primary: Hysteria2 (Server A)
Backup:  Trojan   (Server B)

That sounds sensible: different transports might fail differently.

But on the network we were testing, multiple TCP-based transports suffered the same freezing behavior. A different protocol was not necessarily a working alternative.

We had confused protocol diversity with failure independence.

The revised strategy prefers a transport already proven to work on the current network, even when that means using the same transport on a different server:

Primary: Hysteria2 (Server A)
Backup:  Hysteria2 (Server B)

This was not about declaring Hysteria2 universally superior. It was about choosing the best observed independent route for the network at hand.

Lesson: Protocol diversity does not guarantee failure independence.

6. A backup-aware health monitor

One of our early failure-injection tests exposed a subtle bug.

We disabled the primary route. After approximately 12 seconds, the backup began carrying traffic. That looked like successful failover.

But the old health monitor still saw the failed primary, classified the whole VPN as unhealthy, and restarted the tunnel.

The watchdog destroyed the recovery the backup had achieved.

We changed the health model to track two separate questions:

Primary health: Can the original route carry traffic?
Effective connection health: Can traffic still pass through any usable route, including the backup?

Primary route	Effective route	Correct response
Healthy	Healthy	Continue normally.
Failed	Healthy	Preserve the session; record primary failure.
Failed	Failed	Start recovery or reconnection.

The backup is configured inside the running tunnel and used on demand. It is not a continuously active second VPN tunnel.

We also encountered an Xray observer/balancer detail: prefix-based tag matching could accidentally include the backup route in a primary-only health check. Making primary and backup tags non-overlapping removed that ambiguity.

This is why a failover design cannot be validated just by reading its configuration.

7. Parallel probing without unbounded retries

Sequentially trying every transport on every server can be painfully slow when packets are silently dropped.

Adaptive Connect 2.0 uses bounded selection:

The best two connection candidates may be tested in parallel.
The first candidate that successfully carries real traffic wins.
Automatic server fallback is limited to three servers in one connection attempt.
Transport, server, and overall attempts each have time budgets.
Previous network observations influence the initial ordering.

The parallelism is inspired by the Happy Eyeballs approach described in RFC 8305.

This is not a newly invented connection algorithm. The engineering value is in combining bounded candidate racing, network-specific history, and real-traffic verification.

8. Testing the system by deliberately breaking it

We built an internal fault-injection tool to selectively disrupt one client's access to a server or transport, without intentionally affecting other users.

The experiment took place on October 9–10, 2026, using one Android 11 phone connected to one home Wi-Fi network in an environment where DPI was present.

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.

Results

Measurement	Result
Test duration	60 minutes
Servers involved	8
Controlled fault injections	11
Successful HTTP probes	741 / 750
HTTP probe success rate	98.8%
Primary-server outage	101 seconds
Interruption observed during that outage	~5 seconds
Longest observed interruption	40 seconds

The most encouraging event was a 101-second outage of the active primary server. The VPN remained in its connected state, the backup carried traffic, and the observed interruption was approximately five seconds.

However, a separate test revealed a hard limit: when Hysteria2 was disabled across all tested servers, the same network's TCP transport freezes left no usable alternative. That caused a 40-second interruption.

Some injected faults targeted servers or transports that were not carrying the active session. Those produced zero observed downtime, but should not be represented as successful active-path recoveries.

We believe that distinction matters more than a single flattering availability percentage.

Important test limitations

This was:

One device and one home Wi-Fi network.
One hour of controlled experiments.
Mostly injected server/transport failures, not a comprehensive reproduction of real-world censorship.
Not a cross-platform or independently verified reliability benchmark.

The 98.8% figure describes successful HTTP probes within this specific test, not worldwide Colitu availability.

9. What Adaptive Connect 2.0 does not solve

Existing TCP sessions are not guaranteed to survive server failover.

Keeping the VPN interface active and keeping an established application connection alive are different engineering problems. A download may still stop when its underlying exit path changes.

We have not proven the same results across every platform or network.

Different mobile operators, Wi-Fi environments, devices, and censorship systems may produce very different outcomes.

Controlled fault injection is not equivalent to every real censorship event.

Actual interference can be less predictable and may respond dynamically to a client's behavior.

No software can route traffic through a path that does not exist.

If every accessible route is unusable, Adaptive Connect cannot manufacture connectivity.

10. Next: session continuity across transports

Our next research question is harder than reconnecting a VPN:

Can existing application sessions survive a transport change without having to reconnect?

The proposed Colitu Session Layer (CSL) separates a logical session from its underlying transport. Early laboratory work is promising, but CSL is not a production capability of Adaptive Connect 2.0.

There is also an important distinction between switching protocols on one server and moving an established session to another server with a different egress address. The latter requires additional session and egress management.

We are approaching that work as research, not as a feature we can already promise.

What we learned

The biggest lesson from Adaptive Connect 2.0 is not that one VPN protocol is better than another.

It's that connectivity is a changing, measurable property of a network.

A working socket is not proof of working traffic.
A different protocol is not necessarily an independent backup.
A health monitor that ignores backup behavior can trigger avoidable outages.
Failure observations should inform decisions without preventing exploration.
Controlled experiments should report failures as clearly as successes.

Reliable connectivity is less about choosing the perfect tunnel and more about continuously verifying that a usable path still exists.

That's the problem we're trying to solve at Colitu.

Read the research and source code

Full Adaptive Connect 2.0 technical report: https://docs.colitu.com/en/adaptive-connect-paper
Open-source Colitu clients: https://github.com/colitu
Project website: https://colitu.com

We're interested in feedback from developers working on networking, transport protocols, privacy-preserving telemetry, fault injection, and censorship circumvention.

What failure modes would you test next? How would you design a health monitor that distinguishes a dead primary from a healthy session on its backup?

Colitu Engineering

Built for networks that fight back.

Why a VPN's “Connected” Status Isn't Enough: Building Adaptive Protocol Fallback

Colitu VPN — Fri, 09 Oct 2026 01:07:53 +0000

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.