This weekend was all about 'Connection Reset.' While news channels vaguely reported that 'users are complaining about outages,' I was in chats and on test servers trying to understand the physics of the process.
Spoiler alert for fans of the 'they blocked all VPNs' theory: no, not all of them. But Roskomnadzor (RKN) has clearly rolled out new signatures for their TSPU (DPI systems) to production (so far only in the regions). And, as usual, they threw the baby out with the bathwater — clean, legitimate traffic within Russia also got caught in the crossfire.
Below is a concise summary of what we managed to dig up over 48 hours of testing and debugging.
Anatomy of the Block: Targeting the Handshake
The main myth is 'they banned hosting provider IPs.' That's not true. 'Samovars' (personal VPS for a single user) that had been running for years on obscure IPs were taken down just like public services.
What we managed to find out through experimentation (thanks to the community and sleepless nights):
1. The Magic of Port 443
In many cases, the block is strictly tied to the standard HTTPS port.
Test: VLESS+Reality on port 443 — instant drop or speed throttled to zero.
Test: The same config moved to a random high port (e.g., 47000+) — up to 80% of packets get through. The TSPU is apparently too lazy to deep-inspect all ports, saving hardware resources.
2. SNI and Fingerprints
The most interesting part. Reality masquerades as other websites (Microsoft, Yahoo, etc.).
Changing the SNI (fake/real/whitelisted) — doesn't help.
However, an empty SNI suddenly lifts the block in 100% of cases.
Removing the fingerprint (setting an empty value to show the default Go fingerprint) also helped to get through.
Collateral Damage: Friendly Fire
The funniest (and saddest) part. During testing, it turned out that the TSPU, in its zeal, began to cut off regular HTTPS traffic to Russian hosting providers.
In browsers (Edge, Firefox), with a large number of connections, access to web servers on Selectel within Russia would fail. This supports the theory that the blocking is not based on 'blacklists,' but on a flawed heuristic: 'I see TLS 1.3, I see active packet hammering -> DROP'.
How to Save Yourself (Working Schemes)
While the XRay core developers (RPRX) are preparing a patch (and they are already aware and will likely release something soon), here are the options:
Shadowsocks-2022. The classics are immortal. The combination with chacha20-ietf-poly1305 encryption works. Yes, 'someone' knows how to detect it, but right now, resources are focused on the war with VLESS, and 'shadows' are slipping through.
Chains. A scheme for the paranoid: User -> Russian VPS (Wireguard/VLESS) -> Foreign VPS. The TSPU sees a connection to a Russian IP and (usually) doesn't touch it, and the Russian server then routes the traffic abroad. The downside is double the ping and cost.
xHTTP. A new transport. It works, but requires tuning.
Opinion: many are writing about xHTTP + CDN Cloudflare. It works, but it's expensive (CDN isn't unlimited) and slow. xHTTP has a right to exist even without a CDN, directly, simply as a way to change the traffic pattern.
The 'Corrupted Memory' Hypothesis or On-the-Fly Modification
A very plausible theory about what's happening has emerged in threads on GitHub and specialized forums. Judging by the traffic behavior, the TSPU isn't just dropping packets but may have started modifying the first bytes of the TLS Client Hello or randomly changing bits in the payload.
Why is this important?
Browsers (Chrome, Firefox) have retransmission mechanisms (TCP retransmission). If a packet arrives corrupted, they will request it again. That's why the regular web (sometimes) works, albeit with some issues.
VLESS/XRay — are strict protocols. Upon seeing a violation of cryptographic integrity or an invalid structure, the client or server instantly terminates the connection, assuming they are being scanned (Active Probing).
This also explains the strange behavior of WireGuard. Within the country (between two routers in different Russian cities), it works perfectly — which means the protocol is not blocked globally. But as soon as you try to create a tunnel abroad, the packets die at the border gateways. The TSPU clearly distinguishes: 'our' traffic is left alone, 'foreign' traffic is filtered by signatures.
The Debate About 'Premium' Setups and xHTTP
Right now, everyone is advising to switch to the xHTTP transport wrapped in a CDN (usually Cloudflare). Yes, it works, but let's be honest: it's not a solution for everyone.
Cost and Complexity. Routing traffic through a CDN increases latency (ping) and risks getting your Cloudflare account banned for violating the TOS (they don't like being used as a VPN pipe on free plans).
The Alternative. Tests show that xHTTP is also viable in Direct mode (directly to the server), without a CDN layer. Its main advantage right now is that it changes the traffic pattern in a way that RKN's current filters don't 'match' it yet. You don't have to overcomplicate the setup if the goal is simply to change the signature.
The Irony of Whitelists
Users of mobile operators (Yota, MegaFon) report that in some regions, an IP-based 'White List' mode has been enabled. The irony is that many Russian banks and services didn't make it onto the whitelists, but Cloudflare's IP ranges did. As a result, we have an absurd situation: to access the website of, say, Sber or Gosuslugi, people have to turn on a VPN because their provider's local network has become useless.
The Death of the 'One-Button' Solution and What Regular Users Should Do
This whole weekend situation has revealed an unpleasant truth: the era of 'buy a cheap VPS, run a script for 5 minutes, and forget about it' is definitively over. If you have your own server, you are no longer just a user; you are a sysadmin on duty. You need to monitor ports, change the SNI, figure out why YouTube is down, and update the XRay core.
What should those who can't be bothered do?
The VPN market is currently transforming. Survival isn't for those with the 'fastest server,' but for those who provide multi-protocol support. If RKN blocks VLESS, you should be able to switch to Shadowsocks-2022, WireGuard (for Russia), or xHTTP in a second.
I see how approaches are changing across different projects:
There's the Amnezia (Self-hosted) path — a cool open-source solution that gives you the tools to set everything up yourself. But if your server's IP gets banned, it's still your problem (buying a new VPS, migrating).
There are major players like PaperVPN or Red Shield — they are reliable, but due to their large user base, they often become the first target for blocks, and their protocols aren't updated as quickly as one might like.
And then there's a layer of modern aggregator services (like hynet.space), which operate on the 'Swiss Army knife' principle and provide a choice of multiple protocols at once, rather than just one specific one.
Why is the 'Swiss Army knife' winning right now?
On Saturday, when Reality went down, a regular user with a personal VPS was left without internet. A user of a service with protocol selection simply clicked a button, switched the transport to Shadowsocks or gRPC, and continued watching videos.
The point is a paradigm shift. In 2024-2025, connection 'survivability' is more important than server cost. If you're not ready to debug logs at night, look for the services I mentioned above that offer at least 3-4 different protocols in a single subscription and automatic port rotation.
A standalone VLESS is no longer a warrior.
Conclusion
VLESS isn't dead; it's just entering a phase of active warfare. The free ride of 'set up Reality and forget' is over. We're waiting for core fixes, stocking up on clean IPs, and learning to load balance.
Write in the comments: what provider do you have, and is YouTube still working through Reality? It feels like MTS is currently the most aggressive in terms of testing.