How it works
Timed sessions, three speeds, one tap.
Free time arrives in blocks. You choose the block before you connect, the app shows the countdown the whole way, and a short ad buys another block when you need it.
Pick a mode
Each mode trades time for speed. Marathon gives 80 minutes at the base speed. Balanced, the default, gives 40 minutes at twice that. Sprint gives 20 minutes at four times the base speed, for a download you want done now. The choice is made before you connect and stays fixed for the session; to change it, end the session and start another.
Standard speed for the longest stretch.
Twice the speed. The default.
Four times the speed for a quick job.
Time remaining, and the warnings
The app shows the time left in the status line, in the progress bar, and in the ongoing notification, all driven by the same one-second countdown against the expiry the server set. Our server marks a session “low” when 15% of its window remains and “critical” at 5%. Those levels change the colour of the bar and show a prompt to extend. They never end the session; the clock does that.
Extending with an ad
When time is running low, watching a short rewarded video adds another block of your mode’s length: 80, 40 or 20 minutes. Remaining time is capped at three hours in one stretch, so an extension can add less than a full block, or nothing at all. When that happens the app tells you exactly how much was added instead of pretending.
How often an ad is required is a setting we control remotely, and it can be zero. When it is zero, extensions are granted without one. When it is one, every extension asks for one. We publish the current state on the transparency page whenever it changes.
Why a session can end early
The server, not the app, owns expiry, and it ends a session before its time in six situations. Each one frees the server for someone else:
- Time ran out. The ordinary end. The app disconnects about thirty seconds before the server does, so you are never cut off mid-transfer.
- The tunnel went idle. No WireGuard® handshake for five minutes, which usually means the phone lost its network or went to sleep.
- It never connected. A session was created but no handshake arrived within three minutes.
- A newer session replaced it. One session per user is active at a time; starting another ends the previous one.
- The server is under capacity pressure. Idle sessions are reclaimed first when the server is full.
- A peer was left behind. A failure on our side left a tunnel with no live session attached; it is cleaned up.
Reconnecting after any of these starts a fresh session with a fresh key.
When the tunnel dies
If your phone loses its network for longer than the idle limit, the server reclaims the session. When the network returns, the tunnel on the phone is still up but carries nothing. NetCloak watches for exactly this: it reads how long ago the tunnel last completed a handshake, checks that the phone has a working network outside the VPN, and confirms that its own status checks are failing. When all three hold, it ends the session and shows a notice saying the connection was lost, rather than leaving a screen that says “Protected” over a dead tunnel. It does not reconnect by itself, because that would spend a new session, and possibly an ad, without asking you.
What the server keeps while a session runs is on the transparency page. The exact rules are in the terms of use.
