Bypassing Russian GFW

[TreeGrassOR]

Hello to everyone, so now I'm making VPN using Xray core and Vless + Reality protocol. I love the core and the protocol, but i don't think that will be enough, if my VPN gets some attention. I was thinking about implementing something like parcing packets, or just encrypt packet header, over Vless to confuse GFW and so it can't analyse my traffic and get anything, i'm talking like, they can't get the IP of my VPS server, and can't use any AI's to create some pattern's of my traffic. I know that to "hide" the IP of my VPS, I need to create my own site on my VPS and redirect traffic to my site's domain, and I already did it, but again, if some people near the government or smth like that will find out about my VPN, it just a matter of time to block my servers. Also talking about parcing, I really can't find something that can be pretty straightforward to implement in Xray core. Was thinking also about dynamic IP of my servers, but this idea is not ideal. Also using anything except TCP doesn't work for me. SplitHTTP doesn't match my requirnments, Quic is only accessible in older versions of 3ui-panel, and also it is too slow XD, I don't know why, but if we are talking about loading websites it is hella quick, but if downloading something, the speed is 5 times slower than when using regular TCP. Configuring it is not an option because I can't find anything usefull, only basic info. Also tried mKCP and it really didn't work, not only configuring it made it worse, the downloading speeds were worse than using quic. And websites after configuring were working poorly too. So that's pretty much all, it will be excellent if someone can help me find a parcing script which works with Xray, or maybe some sites where I can get a better knowledge of how I can create it myself. Any other ideas how to make a vpn connection more resistant to GFW will be excellent too. In advance thank you guys for reading this and spending your time on this disscussion!

[xstyl3s]

What we saw: a working VLESS+REALITY node suddenly died on several LTE carriers,
while the exact same node kept working fine on home broadband. First guess was an
IP block or the SNI (ads.x5.ru) getting flagged — both turned out wrong:

• The SNI host stayed reachable: plain TLS to it from the same mobile network was fine.
• Switching the client uTLS fingerprint from chrome to firefox (or qq) restored
  the connection immediately — same IP, same SNI, same port.

So on those LTE segments a ClientHello with a chrome fingerprint gets dropped at the
handshake, while firefox/qq pass. Looks like fingerprint-level classification rather
than SNI- or IP-based blocking. Worth a fingerprint swap before you rotate IP or SNI.

Two related things that held up well on RU mobile:

• REALITY dest/serverNames pointed at a major foreign brand (microsoft/apple/google
  certs) gets blocked; domestic high-traffic hosts (eh.vk.com, ads.x5.ru, max.ru)
  are much more stable as the steal-from target.
• TSPU SNI blocking is selective, not wildcard — a fresh subdomain on a clean IP often
  punches through where the old one is already flagged.

YMMV by region/carrier, but the fingerprint swap is the cheapest first thing to test.

[xstyl3s]

A data point from running production REALITY nodes for RU mobile (LTE) users over the past months, in case it helps others chasing the same symptom.

TSPU on mobile appears to filter REALITY by the TLS fingerprint, not just by SNI/IP.

What we saw: a working VLESS+REALITY node suddenly died on several LTE carriers, while the exact same node kept working fine on home broadband. First guess was an IP block or the SNI getting flagged — both turned out wrong:

• The SNI host stayed reachable: plain TLS to it from the same mobile network was fine.
• Switching the client uTLS fingerprint from chrome to firefox (or qq) restored the connection immediately — same IP, same SNI, same port.

So on those LTE segments a ClientHello with a chrome fingerprint gets dropped at the handshake, while firefox/qq pass. Looks like fingerprint-level classification rather than SNI- or IP-based blocking. Worth a fingerprint swap before you rotate IP or SNI.

Two related things that held up well on RU mobile:

• REALITY dest/serverNames pointed at a major foreign brand (microsoft/apple/google certs) tends to get blocked; domestic high-traffic hosts are far more stable as the steal-from target.
• TSPU SNI blocking is selective, not wildcard — a fresh subdomain on a clean IP often punches through where the old one is already flagged.

YMMV by region/carrier, but the fingerprint swap is the cheapest first thing to test.

[agentram]

I ran into the same problem while operating a small Xray setup for real users in Russia.

My experience was similar: switching the uTLS fingerprint from chrome to firefox can help on some networks, but fingerprint and spiderX alone are not a durable solution. They harden the client profile, but they do not hide the server IP or make REALITY undetectable.

I ended up adding transport profiles to my ovpn project instead of relying on one REALITY configuration. The current setup supports:

• VLESS/TCP/REALITY as the compatibility baseline;
• Firefox as the default fingerprint for newly generated REALITY links;
• a stable per-user spiderX, applied only to REALITY;
• an opt-in VLESS/TCP/TLS self-SNI profile on port 443 with a real certificate;
• fallback of invalid or ordinary HTTPS requests to an internal static website.

With the self-SNI profile, Xray still owns port 443. Valid VLESS clients enter the tunnel, while an ordinary HTTPS probe receives a normal website instead of a VPN-specific response. Ansible handles certificate issuance and renewal, firewall rules and the fallback site.

I do not claim that this makes the server unblockable. The goal is more practical: remove obvious probe behavior and avoid making one transport the only point of failure.

Project:
https://github.com/agentram/ovpn

Transport details:
https://github.com/agentram/ovpn/blob/main/docs/transports.md

Optional camouflage:
https://github.com/agentram/ovpn?tab=readme-ov-file#optional-camouflage

[agentram]

I have added an experimental XHTTP + VLESS Encryption profile to my open-source OVPN project:

agentram/ovpn#37

The profile currently uses XHTTP auto with mlkem768x25519plus.native and client-side 0rtt. It is still marked experimental, but I have tested it on real connections from both Russian and Chinese networks. In those tests it was useful as an additional profile next to TLS/self-SNI and plain XHTTP, rather than a replacement for every transport.

The code, deployment templates, tests, and documentation are public. I would appreciate feedback on client compatibility, reconnect behavior, memory use, and longer soak tests.