How long a VPN connection takes — and why it varies

Most of the time a second passes between the tap and a working tunnel. Sometimes eight. Occasionally twenty — long enough for you to decide something is broken. We keep a connection log, so instead of guessing we can take those seconds apart: what each step costs, why the number jumps, and when “slow” is simply the correct answer.

What it actually takes

These figures come from our own connection log: the app records every attempt to go online, successful ones included. The measurement was taken on 29 August 2026 and covers the whole log — which begins on 21 August, so the window is nine days, not a month. It holds 366 attempts by four real people; our own service handsets are excluded from the sample, and that subtraction matters more than it sounds.

The clock stops not at the “connected” icon but at a confirmed way out: the app sends a real request through the tunnel and waits for the answer. Until the answer arrives, the stopwatch is still running.

“Direct” in the table means straight from the phone to the server of the chosen country, and it comes in two flavours: over IPv6 and over IPv4. The bottom two rows are spare routes to that same server, and the app reaches for them rarely.

The median is the midpoint: half the connections are faster, half slower. We publish it instead of the average because averages lie about this kind of quantity — a single 286-second outlier (we have one, on an old build) drags the “average” up for everybody and paints a picture that never happened.

Both direct variants together: 338 connections, median 1.24 s. 209 of them finished within two seconds, 300 of 338 within five.

Where the seconds go

The app times the individual steps too: ask the server for the connection settings (when they were not prepared in advance), resolve the server name to an address, wait for the IPv6 pre-flight verdict, bring the tunnel up on the phone itself, exchange the handshake and, finally, confirm there is a real way out. Here are their midpoints across the same direct connections, in the order they happen. The sample sizes differ because some steps do not happen every time, and some app builds do not report them yet.

Add the last three rows and you get roughly nine tenths of a second — which is exactly what a good connection feels like. Note the proportions: the cryptography itself costs a quarter of a second, while proving the link is real costs more than twice that. We think the trade is worth it. A “connected” badge with nothing behind it only means the app is pleased with itself.

Why the same phone takes one second, then eight

The spread on the direct route is wide: one connection in ten finishes within 0.74 seconds, and one in ten takes longer than 6.79 seconds. These are the causes we can see in the log.

• The settings were ready in advance — or they were not. The moment you pick a country from the list, the app fetches the connection settings in the background and keeps them warm. That is why the “ask the server” step appears in only 29 of 338 connections; the rest already had everything in memory. When it does happen it costs three quarters of a second at the midpoint, and several seconds in the worst cases. Practical upshot: choose the country before you need the connection.
• A device’s very first connection is always slower. Once the server has issued the settings, your phone still has to appear on the exit server as an authorised peer. That rollout takes up to fifteen seconds (measured on our own infrastructure). It is a one-off price: the second time the slot is already there.
• Whatever the network is doing at that moment. A handshake is a round trip, so it costs precisely as much as the network charges for carrying a packet. In our log the same servers produced handshakes from 0.25 to 6.2 seconds.
• IPv6, if your carrier gives you one. Across our four handsets the IPv6 route is slightly quicker: a 1.09 s median against 1.34 s. The gap is small and the sample is tiny, so we call that an observation, not a rule.
• Tapping again does not speed anything up. A tap during “Connecting…” is read as cancel, not as “hurry up”, and the clock starts over.

Where the twenty-second figures come from

The direct route is not the only one: the app has spare routes to the same server and occasionally uses them. The important part is that a long total does not mean a slow spare route — it means waits added together.

The app does not guess which route is alive; it tries one and looks at the result. Every attempt has a deadline. No answer within it — move on to the next route, and the time already spent does not come back. The log writes the ladder out as plain text, so the arithmetic is visible. Two real entries:

• direct ✗ 6.1 s · RU ✗ 6.1 s · bridge ✓ — 13.5 seconds in total, 12.2 of which were spent on two attempts that produced no answer.
• IPv6 ✗ 10.3 s · direct ✗ 7.9 s · RU ✗ 6.1 s · bridge ✓ — 26.7 seconds in total, 24.3 of them spent waiting.

The handshake on that last rung took 2.4 seconds at the midpoint of those five cases: the rung itself was not the slow part, the road to it was. Hence the rule we use for picking deadlines. Too short, and the app abandons a working route over one lost packet. Too long, and you stare at “Connecting…” for no reason. Right now an unanswered attempt costs about six seconds, which is what the trace above shows.

The last rung has no deadline at all. If nothing above it worked there is nowhere left to hurry to, so the app patiently waits out those fifteen seconds a new device needs to appear on the server. Connecting on the twentieth second beats not connecting.

How the ladder itself is built, and what the “Direct”, “Via Russia” and “Backup” labels mean, we covered separately in “One tap, three paths: how Mayak connects”.

Why our numbers look bigger than everyone else’s

Compare our median with the promises on other services’ front pages and we look slow. The difference is not speed, it is where you decide the connection ended. There are three candidate moments, and almost a second separates them:

1. the tunnel is up on the phone — 0.06 s;
2. the handshake with the server completed — add 0.25 s;
3. a real request went out and an answer came back — add another 0.60 s.

We stop the clock at the third, because the first two promise you nothing: a tunnel with no traffic flowing through it comes up exactly as fast as a working one. The number ends up larger, but it means what it says.

What these numbers do not tell you

This is the important part, and we would rather say it ourselves.

• This is not “user statistics”. Four people, 366 attempts, nine days. A sample that size can explain how something works; it cannot promise you the same result.
• Service handsets are subtracted — and the picture changes without that. Of the 16 accounts in our database 11 are our own, and they connect more often than the real people do. Leave them in, and the entry point in Russia acquires an impressive-looking “median 10.81 seconds over 30 connections” — whereas real people made exactly one such connection in nine days. We have twice caught ourselves in measurements where our own machines were posing as visitors, so we now subtract them by an explicit flag in the database rather than by eye.
• The lower rungs are individual cases, not statistics. One connection and five connections. We give the count and list them one by one instead of deriving percentages from them.
• The log is younger than a month. It starts on 21 August 2026, so “over 30 days” here would just mean “all of it”. In a month these same rows will carry different weight.
• 22 attempts out of 366 ended without a connection on any route. That is six per cent, and we are not hiding it: the figure is more useful than a round number would be.

If you would like to check your own connection instead of taking anybody’s word for it, we have a separate walkthrough: “How to check that your connection is really protected” — four checks in about a minute.