Why one VPN works on MTS but not on MegaFon
If your VPN works on MTS but does not work on MegaFon (or the other way around), this is a normal pattern for Russia in recent years. TSPU — technical means of countering threats, through which operators filter traffic — are installed at all operators, but they are configured differently. As a result, the same server with the same protocol behaves differently across different operators.
This is not an “accident” and not an app bug. Operators differ in equipment versions, the set of enabled detectors, routes to foreign IPs, QoS policy on slow packages, and responses to “suspicious” sessions.
Below is why this happens and what a user can do in practice. At the end: how to quickly understand which operators your protocol currently works with at all, using Freedom Checker.
In short
- TSPU at different operators means different detector settings, which leads to different behavior.
- Each operator has its own route to the VPN server: different IXs, different upstreams.
- One protocol may be “transparent” at one operator and get cut at another.
- In one region, blocking at the same operator may be stronger than in another.
- If the VPN works on an MTS eSIM and does not work on the main MegaFon SIM, the phone is not the problem.
- The solution: keep two or three protocols and switch between them, or use a server with obfuscation (Reality / MTProto).
Why one VPN works at one operator but not at another
The short answer: Roskomnadzor does not press one big red “turn off VPN for everyone” button. Each operator configures its own TSPU itself, within the general requirements. The difference can be significant, especially for VPN protocols that are not formally prohibited.
TSPU is not one device, but a class of systems
TSPU are installed at the boundary between the operator’s network and the internet. This is a set of filters: blocking IPs/domains from the registry, SNI inspection, behavioral analytics, throttling. MTS, MegaFon, Beeline, Tele2, and Rostelecom have different models, different firmware versions, and different trigger policies. One detector may be enabled in “strict” mode at one operator and in “logging” mode at another.
Different routing to a foreign IP
MTS, MegaFon, and Beeline reach the internet through different exchange points and different upstreams. The route to the same VPN server in Amsterdam goes through different transit networks. On one route there is an intermediate filter that cuts UDP with a certain pattern; on another, there is not. From the outside, this looks like “WireGuard does not work on MegaFon, but flies on MTS.”
The region also matters
Even at one operator, TSPU is configured unevenly by region. In Moscow and St Petersburg, filtering is almost always stricter than in smaller cities. In some regions, “exercises” are enabled: strictness is increased locally for several hours. So complaints from Novosibirsk and Voronezh may differ even though the operator is the same.
The protocol’s behavior, not its name
TSPU detect not the “VPN app,” but a characteristic traffic pattern. UDP with a fixed handshake packet size, a repeating TLS fingerprint structure, a cluster of short packets in one direction. If a protocol is obfuscated (VLESS Reality, MTProto), it repeats the pattern of a real TLS site, and it is harder to distinguish from an ordinary browser. That is why obfuscated protocols work more stably “everywhere.”
Network type: mobile or home
On home cable, one operator may pass everything, while on its own LTE network it may cut it. This is because the mobile network goes through its own set of gateways and TSPU, different from the fixed network. So the phrase “the VPN works on MTS” only makes sense together with the network type: “works on MTS LTE in Moscow.”
How to tell that the operator is the issue
| Symptom | Possible cause | What to check |
|---|---|---|
| WG comes up on MTS, does not come up on MegaFon | UDP-pattern detector on MegaFon’s TSPU | Switch to a TCP obfuscating protocol (VLESS Reality) |
| The same VPN works at home, does not work on LTE | Different TSPU for FTTH and for the mobile network | Change the server or protocol on the mobile SIM |
| Does not work in Moscow, works in the region | Regional difference in TSPU policy | Compare through Freedom Checker by region |
| The connection is up, but there is no traffic | “Silent” throttling to zero at one operator | Change port/server, check ICMP to the VPN IP |
| Same server: MTS — 200 ms, Beeline — 1500 ms | Traffic throttling under the operator’s policy | Change the server region or use an obfuscating protocol |
| Works in the morning, does not work in the evening | Route congestion or a temporary rule | Wait, check an alternative server |
How to check right now
The most useful action is to see which operators your protocol and your set of servers currently work with at all. Freedom Checker runs checks simultaneously from different nodes and operators and shows who has a green label and who has a red one.
If your VPN does not work on MegaFon, but the map shows green for MTS and Tele2, this is specifically MegaFon’s TSPU in your region. If it is red for all operators, you have a “universal” problem: either the server or the protocol has been caught by a general detector.
Failure or blocking?
A failure looks like this: one operator “went down” for an hour or two, then came back up by itself; statistics for other operators are stable at that moment. This often coincides with backbone incidents or a TSPU reboot.
Systemic blocking is when the “does not work” result at one operator holds for days and is not fixed by changing the server within the same country. At the same time, the same server stays alive at other operators. This is already a stationary TSPU setting, and only changing the protocol (for example, to an obfuscating one) or changing the operator for testing helps.
What to watch for
- Keep two or three working protocols; do not depend on just one.
- Obfuscating protocols (VLESS Reality, MTProto) depend less on the operator.
- Distinguish between mobile internet and home cable: these are different “worlds” for TSPU.
- The region matters: what works in Voronezh may not work in Moscow.
- Compare behavior on two operators at the same time before fixing the phone.
- If a symptom repeats steadily for weeks, it is policy, not a glitch.
- Use Freedom Checker to see the current map by operator.
Conclusion
The difference between “works at one operator, does not work at another” is a normal feature of how traffic filtering is implemented at Russian operators. Do not try to defeat it with phone settings: it is outside your device.
Before changing the server, protocol, or client, see which operators the thing you need works with right now. This will save hours.