Russia's TSPU Explained: Why It Blocks 90% of VPNs and What the 10% Do Differently

I've been documenting TSPU behavior systematically since 2023 — running controlled experiments on multiple Russian mobile operators, tracking blocking events, and correlating them with Xray-core release notes and Russian-language security research. What I've found is that TSPU is more sophisticated than most English-language coverage suggests, and understanding its architecture explains precisely why VLESS Reality works when everything else fails.

TSPU (Технические Средства Противодействия Угрозам / Technical Means for Countering Threats) is the deep packet inspection infrastructure Russia mandated ISPs to install beginning in 2019 under Federal Law 90-FZ ('Sovereign Internet Law'). The primary hardware supplier is EcoFilter, a Russian company with ties to state security apparatus.

Common misconception: TSPU is not primarily a blocklist system. DNS-based and IP-based blocking had existed for years before TSPU. What TSPU adds is protocol-level traffic analysis — the ability to identify traffic patterns even when the content is encrypted, and to apply different policies to different protocol types.

By 2026, TSPU is deployed at all Tier-1 Russian ISPs (Rostelecom, MTS, Beeline, MegaFon, Tele2, TransTeleCom) and operates in what researchers describe as 'layered detection mode': multiple analysis passes on each flow, each targeting different detection vectors.

The most basic layer. TSPU maintains a database of protocol signatures — characteristic byte patterns in the first packets of a connection. WireGuard's handshake produces a unique UDP packet structure identifiable in the first two packets. OpenVPN's TLS handshake has characteristic certificate exchange behavior. These are blocked immediately, within 1–2 seconds of connection establishment.

This layer catches: WireGuard (standard), OpenVPN, IKEv2/IPSec, L2TP, PPTP, standard Shadowsocks (since late 2025), and most commercial VPN protocols.

More sophisticated. JA3 and JA4 are hashes computed from parameters in the TLS ClientHello message — specifically the cipher suite list, extension list, elliptic curves, and signature algorithms. Every TLS implementation has a characteristic combination. Chrome 124 has a specific JA4. Firefox 121 has a different one. Golang's standard crypto/tls library has yet another.

The attack: even if a VPN correctly impersonates a legitimate website at the certificate level, if its TLS ClientHello was generated by Golang's default library instead of matching Chrome's actual parameters, the JA4 fingerprint reveals the mismatch. This was the specific vulnerability that caused the January 2026 blocking wave — many VLESS Reality servers were using default Golang TLS, not browser-matching fingerprints.

The hardest layer to defeat. Normal HTTPS browsing has a characteristic shape: TCP connection, TLS handshake (~0.5s), small initial request, larger response, user pause (variable), next request. VPN tunnel traffic has a different shape: connection, handshake, then continuous bidirectional flow with small periodic keepalive packets at regular intervals.

TSPU's behavioral analysis uses this distinction. Even a connection that passes Layer 1 (no signature) and Layer 2 (correct JA4) can be flagged if its traffic timing pattern matches known VPN keepalive patterns rather than browser request/response cycles.

Separate from the three detection layers above, mobile operators enforce a white-list mechanism: on 3G/4G/5G connections, TCP sessions to non-whitelisted destinations are terminated after ~16–20 KB of data transfer. This isn't protocol-specific — it's destination-specific. The ~1,000 whitelisted domains are Russian government, banking, and major commercial sites. Everything else is throttled.

This layer is why 'VLESS Reality that works at home' can fail on mobile data: the mobile white-list layer operates independently of protocol detection.

VLESS Reality doesn't have a recognizable protocol signature because it genuinely looks like a standard TLS connection. There's no VLESS-specific byte pattern at the connection level — the connection initiation is indistinguishable from any HTTPS connection.

With fingerprint=chrome or fingerprint=firefox configured in Xray-core, the TLS ClientHello parameters exactly match those of a real browser. The JA4 hash is identical to Chrome 124. This was the configuration change that fixed the January 2026 blocking wave — updating Xray-core to v24+ and setting the correct fingerprint parameter.

VLESS Reality's traffic timing is designed to match legitimate HTTPS browsing patterns rather than VPN keepalive patterns. The Reality protocol handles this partially; xHTTP (the next evolution) handles it more completely by wrapping traffic in actual HTTP request/response cycles.

VLESS Reality servers present as connecting to whitelisted domains (microsoft.com, cloudflare.com) via their TLS impersonation. From the mobile operator's perspective, the TCP connection appears to be going to a whitelisted destination, so it's not terminated at 16–20 KB.

Understanding the four layers explains why 'VLESS Reality' as a category isn't uniformly effective — configuration quality matters enormously.

Configuration Issue Which Layer Breaks Observable Symptom fingerprint=golang instead of chrome Layer 2 — JA4 mismatch

Works at home, fails randomly; affected by Jan 2026 wave

Low-traffic steal target domain

Layer 3 — behavioral anomaly

Outdated Xray-core (pre-24.x)

Layer 2 — old fingerprint

This is the core argument for using a managed service like INFOCROSS rather than self-hosting: configuration correctness requires tracking Xray-core releases, monitoring blocking events in Russian operator networks, and updating server configurations promptly. INFOCROSS manages this for users — when the January 2026 wave hit, correctly configured managed services recovered within hours. Self-hosted servers with outdated configs stayed broken for days.

✅ Bottom Line

TSPU has four detection layers: signature matching, JA4 fingerprinting, behavioral analysis, and mobile white-list enforcement. VLESS Reality passes all four when correctly configured (Xray-core 24+, fingerprint=chrome, high-trust steal target). INFOCROSS @infocross_bot manages server configuration — users get working keys without understanding these parameters.