Why it will not connect on mobile data but works on Wi-Fi

At home everything comes up in a second, and on mobile data the connection either never establishes or establishes and dies a couple of seconds later. It is not a broken phone and not “bad signal”. We took it apart on three carriers in Moscow — by our own measurements, not by ear.

What is actually going on

A home provider usually passes the connection through as it is: what is inside is none of its business. A mobile carrier is different — its network carries equipment that looks at the shape of passing packets and decides on the very first bytes. No decryption is needed for that: for many protocols the first bytes and the lengths of service packets are constant, so the protocol is recognised from the first packet (we took this apart in “AmneziaWG: what it is and how it differs from WireGuard”).

From there two outcomes are possible, and we have seen both.

How common is this really: our own numbers

First, the size of the problem, because that part is usually written by feel. We counted it from our own connection log over 30 days (23 August to 22 September 2026), comparing attempts by the network they came from. Only attempts a person started count: when the app re-raises the tunnel by itself after a drop, that tells you about the app working in the background, not about the network.

There is a difference, and it points the way everyone says it does: on mobile data about four attempts in a hundred fail to come up, on Wi-Fi about two — half as often. But note the flip side: mobile data is not “broken” — it works 96 times out of 100. If yours fails every time, you are not in that 4 % — something specific is wrong, and it is worth working through the list of causes.

What this number does not say. It is counted over our own users and our own app across one month: 55 people on mobile data and 106 on Wi-Fi, with service accounts excluded, though the team’s own devices are in that log. It is an order of magnitude, not national statistics. A further 93 attempts did not report a network type at all — older builds do not send it, and we deliberately do not substitute “mobile” for them.

It worked yesterday and not today — on mobile internet

This is a separate question, and not the same one. “It does not work for me” and “it used to work and then stopped” are two different stories: in the second one the person usually changed nothing on their side. Since 3 September 2026 we have been seeing a shift in our own journal: the direct route started failing noticeably more often. We count only attempts that a person started themselves; when the app brings the tunnel back up on its own after a drop (background attempts), that is a different story: those speak about how the app works in the background, not about the road to the server, and we look at them separately.

This is about cellular networks only. If the question is broader — «it stopped working, what do I do right now» — the step-by-step piece is separate: it shows that almost two thirds of failures go away on the very next attempt.

Read it like this: attempts that a person starts themselves almost always go through on mobile data — both before 3 September and after. There is a shift, but a small one: two failures out of 132 and three connections that needed the backup route, against none in late August. The numbers here are very small, so the comparison is rough. Across all networks at once the same shift is clearer: since early September the direct route has failed on 7–9 % of attempts against 1 % in late August.

On its own this proves nothing: over those same days we were rolling out our own changes, and pinning any shift on the operators would be convenient and dishonest. So a second, independent view is needed. Over exactly those days news feeds report: on 5 September, “mass VPN and MTProto proxy outages have begun in Russia” (GoHa.Ru); on 6 September, “a mass internet outage in Russia hit dozens of regions” (Techora.ru); on 8 September, “VPNs in Russia have been patchy for a second day” (RB.ru). Those are other people’s claims, not our measurement, and we present them as exactly that; but when our own journal and an independent feed say the same thing on the same days, the coincidence stops being one.

What follows for you. If it stopped working in early September and you changed nothing, you most likely broke nothing: the direct route fails more often now, and not only for you. The practical conclusion is one: the app needs somewhere to step. Check that you are up to date, do not switch off “Use IPv6”, and do not forbid the backup route — it is what picks up the connection when the direct route does not pass.

What these numbers do not say. The windows are unequal (thirteen days against six), there are not many people behind them (in late August the journal had only six), the team's service accounts are excluded, and “the backup route was needed” does not equal “the operator blocked it”: the app records which step worked, not why the previous one did not. The same shift with the money side and the full numbers is in “Paid VPN not working”.

What the measurements showed

The measurements were made in Moscow, on live cellular networks, at the end of July 2026. The same app, the same server; the only thing that changed was the masking setting.

Beeline matters here no less than the others even though everything worked on it: it was the control. If masking broke a carrier that was fine to begin with, that is exactly where we would have seen it. It did not.

The port is irrelevant — it is about masking

The most common advice on the internet is “move it to port 443, ordinary HTTPS goes there, they will leave you alone”. We checked that advice with a separate measurement, and it does not work.

On Megafon the same connection on port 443 but without masking failed exactly as it did on an ordinary port. With masking it came up and delivered 117 Mbit/s. The conclusion is simple: what is being looked at is not the port number but how the packets themselves look. The port is the address on the envelope; the decision is made from what the envelope looks like from the outside.

A second observation comes from the same run. A plain HTTP request to the very same server did not get through on Megafon — it timed out — while a masked tunnel to that same server did get through and worked. So the server address is not on any blocklist: the filter works on the protocol and the shape of the traffic, not on where you are going.

Megafon and MTS break it differently

The difference is worth knowing, because the symptom tells you what is happening.

• Megafon cuts earlier and harder. There is no handshake at all: the app shows “Connecting…” for a minute and gives up. The connection never gets to happen.
• MTS lets the beginning through. The handshake passes, the tunnel comes up, the “Protected” badge appears — and two or three seconds later traffic stops. From the outside that looks like “connected, but no internet”, and we have a separate write-up for that symptom: “Connected”, but no internet.

“Works on 4G, fails on 4G+” — it was the signal, not the mode

Once on Megafon we saw this: on 4G+ the connection did not come up, the phone switched to 4G by itself — and the same connection came up. It looked as if the filter were stricter in 4G+ mode. But that test ran in a room with a weak signal. Re-checked where reception is normal: the same connection came up on 4G+ within a second, with no switch needed.

The takeaway: the network mode does not matter; the weak signal did. With poor reception the first packets get lost, and it looks exactly like blocking — an endless “Connecting…”. So if it will not connect and you have one or two bars, first try where reception is better (by a window, outdoors), and only then conclude that the app or the operator is at fault.

There are only four networks in Russia

Knowing this saves time. There are four physical mobile networks in Russia: MTS, Megafon, Beeline and Tele2 (also known as t2, also Rostelecom mobile). Everything else is a virtual operator on someone else’s towers:

• Yota — on Megafon’s network; the separate write-up — what that means for a Yota SIM;
• T-Mobile (T-Bank) and SberMobile — on Tele2’s;
• Tele2 = t2 = Rostelecom mobile — one and the same network under different names.

So if you are on Yota, expecting Megafon’s behaviour is reasonable. But reasonable to expect, not “guaranteed”: a virtual operator may have its own gateway, and filtering can differ from the host network. We did not measure Yota separately, and we did not test Tele2 at all — and we will claim nothing about them.

Beeline, on the other hand, behaved differently from Megafon and MTS in our measurements: it was the control network — the connection came up and stayed up. So if you are on Beeline and something is broken, the operator is the wrong place to look: that is what the separate Beeline write-up is about.

What to do

If it will not come up on mobile data — in order, top to bottom:

1. Update the app. Masking is on by default in recent builds; older ones cannot do it at all, and on Megafon and MTS that alone decides everything.
2. Do not turn off “Use IPv6”. Since August the app first tries to reach the server over a newer-style address, and on Megafon that path behaves differently from the familiar one: in our measurement on 23 August the connection came up in 0.9 seconds where the ordinary path without masking would not come up at all. That is a single measurement, on one phone, in Moscow — we are not putting it in the table above. But the practical point stands: turning this switch off deprives the app of an attempt that may be the only fast one on your carrier.
3. “Settings” → “Check the connection”. The app goes through every way of connecting in turn and tells you which one fails for you. A minute of your time instead of guessing.
4. If the direct route never works on your carrier — turn on “Always use backup channel”: the connection takes the detour straight away instead of spending time on a direct attempt.
5. Try another country. Routes to different countries differ, and what does not get through to one often gets through to another.

Short answers

Why does it work on Wi-Fi but not on mobile? A home provider usually passes the connection through as it is, while a mobile carrier looks at the shape of the packets and gets in the way of the ones it recognises.

Only the government portal, the bank and marketplaces open, nothing else — is that the same thing? No, that is a different case: the mobile network has been left with a list of approved services only. Our measurements below say nothing about it — what that mode is and what works in it. The check is the same: on Wi-Fi everything opens.

Will switching to port 443 help? On its own, no — measured: the same connection on 443 without masking failed, with masking it came up.

Is the carrier blocking the server address? In our measurement, no: plain HTTP to the same server did not get through, while a masked tunnel did.

Are Yota, SberMobile and T-Mobile separate carriers? No, they are virtual operators: Yota on Megafon’s network, T-Mobile and SberMobile on Tele2’s.

Will mobile data work with a VPN at all? In our 30-day log — yes, in 95.7 % of attempts. A cellular network and a tunnel get along 96 times out of 100; the question is not “does it work at all” but “why does it fail for me”.

Why does everything come up over Wi-Fi but not over mobile data? A home line usually passes the connection through as it is, while a cellular network has equipment on the path that looks at the shape of the packets. Hence the gap in our numbers: 98.0 % against 95.7 %.

It worked yesterday and stopped today — is it me or everyone? If it is the direct route that does not pass, most likely not only you: since early September it has failed noticeably more often, and the backup route picks up the connection. But attempts that a person starts themselves still almost always go through for us: on mobile data over 3–8 September, 130 of 132. It is still worth checking your own side, but you need not start from “what did I break”.

Which operator blocks VPNs the least? The honest answer: choosing an operator on that basis is a poor lever. In our July measurement in Moscow, Beeline was the control network (the connection came up and lived), on MegaFon it did not come up at all without masking, and on MTS it came up and died after two and a half seconds. But that is Moscow and late July, and by September the picture shifted for all of them at once. We do not advise changing a SIM for this: what decides is not the choice of operator but whether the app can walk several routes.

The phone has internet, sites open, but the VPN will not come up. That is the normal and most common picture: the operator did not switch off your internet, it is getting in the way of one particular kind of traffic. Hence the treatment — not “fix the internet” but change the shape of the connection: update the app (masking is on in recent builds), keep “Use IPv6” on, and let the app move to the backup route.

Do your numbers hold everywhere? No. The operator measurements were made IN MOSCOW, at the end of July 2026; the before-and-after comparison for 3 September comes from our journal and a small number of people. In another city and another month the picture may differ — which is why we say where and when we measured.