How TSPU (ТСПУ) works: why a site loads on one operator and not on another
TSPU are technical means of countering threats: traffic-filtering equipment installed at telecom operators in Russia. When a site opens on one operator and does not open on another, the reason is most often TSPU: the device sits in the path of your packets and decides what to pass and what to block.
TSPU are installed by Roskomnadzor under Law 90-FZ “On the Sovereign Runet.” The device itself is an operator-side “black box” with filtering rules that arrive centrally. At the same time, the operator itself can also apply its own technical routing and priority rules. The result is a two-layer system, and this is why outcomes differ between operators.
Below we break down the mechanics without slogans: how traffic goes through TSPU, what can happen to it there, and why “the same blocking for everyone” is a simplification that does not reflect reality.
In brief
- TSPU are RKN equipment on the side of backbone and large telecom operators.
- The traffic path is: user → operator → TSPU filter → onward to the internet.
- Rule lists arrive centrally, but configuration and priorities can differ between operators.
- TSPU can block by IP, by DNS, by SNI, and by protocol signature (DPI).
- That is why the same site can open on MTS and not open on MegaFon.
- Routing also affects the result: there can be different paths to a site, and not all of them pass through identically configured nodes.
How the traffic path is organized
When you open a site, your request passes through several network layers, and blocking can trigger at any of them.
Step 1. Device → operator
The packet leaves your device for the telecom operator’s access point. At this stage there are no filters yet — this is just the access network (LTE/5G/fiber).
Step 2. Operator → TSPU
Inside the operator’s network, traffic reaches the node where TSPU is installed. This is where the initial parsing happens: connection type, destination address, domain name in SNI, protocol signature. Based on preloaded rules, the device decides whether to pass, slow down, terminate, or respond with substitution.
Step 3. TSPU → backbone → site
If TSPU passes the traffic, it goes further through backbone providers to the site’s server. The reverse side is also possible here: some services themselves restrict access from Russian IPs, and blocking “from above.”
Why different operators give different results
The lists of sites subject to restriction are shared — they are formed at the level of the RKN registry. But each operator has its own technical implementation: different TSPU hardware, different priorities for manual rules, different routing paths to the target site. As a result, one operator cuts strictly by SNI, another more softly by DNS, and a third may pass the traffic around TSPU through an international channel. The site opens selectively — and this is normal system behavior, not an error.
How to understand what exactly broke
| Symptom | Possible cause | What to check |
|---|---|---|
| The site opens on MTS but does not open on MegaFon | Different TSPU configuration at the operators | Compare measurements through Freedom Checker |
| The site does not open on any operator | It has been added to the RKN registry, or the site is blocking access itself | Check the address in the open registry |
| The site opens from home internet but not from mobile | Different TSPU in the mobile and home segments | Change operator / switch to Wi-Fi |
| It opens slowly, with drops | Traffic throttling on TSPU | Measure speed to a known unblocked site |
| ERR_CONNECTION_RESET error immediately after ClientHello | SNI filtering on TSPU | Try the request through ECH/proxy |
| It works in one region but not in another | Different filtering nodes in different regions | Compare measurements with another region |
How to check right now
To separate “it does not work only for me” from systemic operator filtering, you need measurements from different points. Freedom Checker runs the same type of availability checks for sites and services from probes at several telecom operators and in different regions. The results show whether the cause is a local failure, the TSPU configuration of a specific operator, or general blocking.
If the same page is unavailable on all checked operators, the registry of prohibited sites is almost certainly involved. If access differs from operator to operator, this is a sign of different TSPU configuration. The technical details of how the equipment works are described in detail in the article on Habr.
Failure or blocking?
A failure is when an operator node is temporarily unavailable, a route has gone down, or a backbone provider has an outage. The symptom: the problem appears suddenly, disappears by itself after an hour or two, and some users still have access.
Blocking through TSPU is stable, tied to the operator and the site, appears after a wave of rule updates, and does not go away by itself. If a site is consistently unavailable on one operator and consistently available on a neighboring one, this is no longer a failure, but a difference in filtering configuration.
What to pay attention to
- The same site can pass through different TSPU nodes, depending on the operator’s route.
- TSPU can act in a granular way: not only blocking, but also slowing down and terminating by timeout.
- Different results on different operators are normal for the system, not an error.
- Regional differences are a consequence of filtering nodes being deployed locally rather than centrally.
- A DNS check is not always indicative: if TSPU works by SNI, the DNS request passes, and the connection is cut only afterward.
- Measurements from one device are always less indicative than comparison between operators.
- Rule configurations are updated periodically, so the picture of “it worked yesterday, it does not today” is typical.
Conclusion
TSPU are operator-side traffic filtering implemented according to a unified design, but with local differences in configuration and priorities. That is why the answer to “why does the site not open for me, but opens for my neighbor” almost always comes down not to the registry, but to which exact operator you use and how its TSPU rules are configured.
The fastest way to see this is to compare measurements by operator. After that it becomes clear whether you are dealing with systemic blocking or with a local feature of one network.