Three Ways Russia Breaks Your Xray Server, and Only One of Them Is a Block

Every few weeks the same ticket arrives. A customer's VPS worked from Russia, then one day it did not, and now the address looks dead from Moscow while answering perfectly from everywhere else. The conclusion writes itself: the DPI fingerprinted VLESS, the server went on a list, the IP is burned.

Sometimes that is exactly right. More often it is one of two other things that feel identical from the client's chair and need completely different fixes.

That matters, because the usual advice — "switch the transport to gRPC" — is half right in a way that makes it hard to argue about. It genuinely does help, for a reason worth understanding precisely. It just does not help with the failure that actually costs you the address, and a lot of people reach for it instead of the thing that would.

Here is what is actually happening, in the order of how much damage it does.

1. The scan: your server answers a probe, and the answer gives it away

This is the one that really does cost you the whole IP.

In May 2026 someone ran a Russian-style VPN scanner against their own server and published the report. It is the most useful document on this subject, because it shows the reasoning rather than the verdict. 7

The scanner does not limit itself to 443. It sweeps the full port range, 1 to 65535, with 500 threads, and throws several different probes at anything that answers: an HTTP GET, a CONNECT, a TLS ClientHello with a deliberately invalid SNI, and raw binary. Then it compares the replies.

A real web server reacts differently to different rubbish. A proxy with a static fallback does not. On the server under test, port 2096 returned the same 41 bytes, byte for byte, to every probe, beginning with the status line HTTP/0.0 307 Temporary Redirect. No real nginx, Apache or Caddy emits an HTTP/0.0 version. That single reply is close to a confession.

The report stacks up several other soft tells:

• No Server: header. Every mainstream web server sets one. Its absence says "custom handler", not "website".
• A certificate with six days of total validity. Public CAs issue for 30 to 90 days. Anything under about a fortnight says hand-rolled, which says test rig, which says proxy.

The scanner scored the host 48 out of 100 and returned the verdict OBVIOUSLY-VPN. The consequence, in the report's own words, is that accumulated anomalies cross the TSPU threshold and "the IP gets added to the reputation list and future flows are dropped/throttled until the signature changes."

That is the mechanism people mean when they say the IP got blocked. It is real, it is address-level, and it is triggered by what your server says when it is spoken to — not by the protocol you are tunnelling.

2. The burst: three handshakes inside fifty milliseconds

The second mechanism is behavioural and has nothing to do with probing.

A thread filed against Xray-core describes the TSPU reading the TLS ClientHello and scoring it on the server's subnet and autonomous system, the SNI, and the browser fingerprint. Chrome, Safari and iOS fingerprints from a suspicious range are held; Firefox, Android, OkHttp and Edge pass. 3

What trips it is intensity. Three or more concurrent TLS connections to the same host inside roughly 20 to 50 milliseconds freezes the lot for about 120 seconds. If the client responds by rotating its fingerprint mid-freeze, that becomes 600 seconds.

This is why a browser opening a page over the tunnel is so much worse than a single download. Modern browsers fan out six connections at once by design. That is the exact shape the detector is looking for.

3. The counter: your fifteenth kilobyte

The third is cruder and, on its own terms, elegant. The censor watches a TLS connection to a foreign server and freezes it once the data returned passes roughly 15 to 20 KB — later pinned down as about 25 packets in either direction.

The thread that documents it, opened on 27 June 2025, is explicit that this is not a protocol matcher: "It doesn't matter whether it's 'legitimate' HTTPS traffic or whether someone is mimicking it." 2

This is the "works for a few seconds and then dies" report. A handshake and a couple of small requests fit in the budget. A page with images does not.

Telling them apart, in one test

The three look the same because the censor freezes connections rather than resetting them. No RST, no ICMP — the handshake simply never completes and the client sits there until it times out, which is indistinguishable from a blackholed route.

From the affected network, fetch something small and plain over HTTP from the same address.

• Plain HTTP works, TLS does not — mechanism 2 or 3. The address is fine. In a November 2025 report of REALITY being blocked on a Russian ISP, the reporter checked exactly this and found the site on the same IP still loaded. 4
• Nothing answers at all — mechanism 1. You are on the reputation list and a new address is the only thing that helps.

The distinction is worth the two minutes, because replacing a server for mechanism 2 or 3 buys you about fifteen kilobytes of relief before the new address behaves the same way. People read that as the new IP being burned instantly. Nothing was burned. The budget was simply spent again.

Where gRPC actually helps, and where it does not

Operators keep reporting that gRPC survives for weeks on connections where plain TCP was detected in days. That is not folklore, and it is not luck. It is mechanism 2, and the reason is mechanical.

gRPC runs over HTTP/2, and the Xray documentation is explicit about what that buys: "gRPC (HTTP/2) has built-in multiplexing. It is not recommended to enable mux.cool when using gRPC and HTTP/2." 5

Multiplexing means many streams share one TCP connection, and therefore one TLS handshake. The burst detector is watching for three or more handshakes to the same host inside fifty milliseconds. A browser over plain TCP fans out six connections and produces exactly that shape. The same browser over gRPC produces one handshake with six HTTP/2 streams inside it. There is no burst left to detect.

So if you moved to gRPC and your problem went away, this is why, and you should not let anyone talk you back out of it.

What it does not do is answer a probe. The same page warns that "gRPC services are at risk of active probing", and recommends a reverse proxy in front splitting traffic by path prefix. Bare gRPC listening on 443 still replies to the scanner, and mechanism 1 is the one that puts the address on the reputation list. Multiplexing does nothing about that.

It is also worth knowing where this is going. The gRPC transport is deprecated: the documentation now says "It is recommended to switch to XHTTP." 5 That is a migration note, not a reason to tear out something that is working. XHTTP, introduced in December 2024, multiplexes the same way through XMUX and adds what gRPC lacks — header padding, and a split between upstream and downstream so the downstream rides independent GET requests, which also sidesteps the gRPC limits some CDNs impose. Against WebSocket it avoids the conspicuous http/1.1 ALPN. 6

Plan the move. Do not rush it.

Stack them; they are not alternatives

The mistake underneath most of these arguments is treating this as a single choice — REALITY or gRPC, this transport or that one. The three mechanisms are independent, so the defences are too, and they compose:

A server running REALITY behind nginx over a multiplexed transport is answering all three. A server running any one of them is answering one.

Put a real nginx in front, and point the fallbacks at it. This is the single highest-value change, and it is the report's own first recommendation: run a genuine nginx with a proper error-page map and aim Xray's fallbacks at it, so anything that is not a valid handshake receives real HTTP from real web server software. 7 That kills the HTTP/0.0 status line, restores the Server: header, and makes the replies vary by request the way a website's do. Serve an actual site on it. A default nginx welcome page is better than a static 307, and a real site is better than both.

Use a real certificate. Let's Encrypt with auto-renewal. A six-day self-signed certificate is a tell on its own, and it costs nothing to remove.

Mind the SNI. Borrowing from Microsoft, Apple or Google draws attention; high-traffic domestic hosts are reported to be far more stable as the steal-from target. The blocking is selective rather than wildcard, and a fresh subdomain on a clean address often gets through. 8

Mind the fingerprint, but not only the fingerprint. Switching uTLS from Chrome to Firefox has been reported to restore connectivity on carriers where Chrome is held. 8 But the score also weighs the subnet and the AS, so a perfect fingerprint on a badly-scored range is still a bad connection.

Use a multiplexed transport, and let it multiplex. gRPC or XHTTP, with mux.cool left off — the documentation is explicit that enabling it on top of HTTP/2 is not recommended. If you are running gRPC behind nginx, that is grpc_pass with a path prefix, which gets you the probe defence and the burst defence from one deployment.

Do not let anything else on the box talk. The scanner sweeps all 65535 ports. Every service that answers is another chance to score an anomaly. Move SSH off 22 to a high port and firewall it to known addresses.

Keep a second location. Not a spare address on the same range to rotate to — somewhere genuinely else. When the failure is regional, what helps is a different path, not a different number on the same path.

And expect it to keep moving

Roskomnadzor blocked VLESS in late 2025 using TSPU, and most providers answered by pushing new configurations within days. 1 That is the rhythm this has settled into, and the budget behind it is growing: TSPU capacity is planned to grow two and a half times by 2030, to 954 terabits per second, at around $186 million — enough, on the Ministry's own reckoning, to analyse all Runet traffic with room to spare.

None of the advice above is permanent. Two things generalise.

You are not being caught for what you tunnel. You are being caught for looking like a machine that exists to tunnel — in what it answers, in how it connects, and in how much it sends. Everything that makes the server look like an ordinary web server that happens to carry other traffic buys you time.

And no single setting is the answer. The detection is layered, so the defence has to be. If someone tells you one transport solves this, ask them which of the three it solves.

Sources

1. Russia's internet censorship in 2026: VPN crackdowns, mobile shutdowns, Telegram blocks and the state messenger Max, Zona Media, 7 April 2026
2. [Russia] Censor has a new method of blocking, net4people/bbs, opened 27 June 2025
3. Russia blocks 2026, XTLS/Xray-core, 2026
4. TCP + Reality gets blocked, XTLS/Xray-core, 23 November 2025
5. gRPC transport, Project X documentation
6. XHTTP, XTLS/Xray-core, December 2024
7. How Bye Bye VPN Works in Russia, MHSanaei/3x-ui, 6 May 2026
8. Bypassing Russian GFW, XTLS/Xray-core