Hello everyone, in this article I will explain how many people manage to bypass whitelists, and what the root of the problem is. If you are a 'newbie' and don't want to bother with all the setup, at the end of the article I've listed services that are mentioned in discussions.
Direct connect VLESS + Reality to Europe (Amsterdam, Germany, Finland) is being shaped for almost everyone. TSPU has mastered a new tactic: they don't terminate the session via RST, but simply 'freeze' it. As soon as the data volume in a single TCP session exceeds 15-20 KB, packets stop arriving. The connection hangs until the client times out.
The only working way to get a normal output is a chain
How the scheme works in a nutshell
We set up a 'relay' a cheap VPS inside Russia (Yandex, VK, EDGE).
The client connects to the Russian node. TSPU is lenient towards traffic within the country, so the session doesn't freeze.
The Russian node, via vnext, forwards traffic to the foreign node.
The foreign node then accesses the open internet.
To TSPU, this looks like a normal data exchange between two servers, which is filtered much less strictly than a user's direct connection to a foreign hosting service.
Tutorial on setting up a chain
You will need two servers: an 'Exit' node (Europe) and a 'Bridge' node (Russia). Both must have Xray-core (at least 25.12.8, to avoid detection by Aparecium).
1. Setting up the foreign node
Set up a standard VLESS inbound. To make the 'relay' less conspicuous and consume less memory, use the xhttp transport in packet-up mode.
Important: Make sure the core is updated to the latest version. Old versions of Reality are detected through TLS 1.3 NewSessionTicket analysis. New versions can mimic this type of message.
2. Setting up the Russian node (Bridge)
In the Xray config on the Russian server, you need to accept traffic from the client and send it to the chain through the outbounds block.
Example outbound for node communication
{ "outbounds": [ { "tag": "chain-to-europe", "protocol": "vless", "settings": { "vnext": [ { "address": "ip-вашей-евро-ноды", "port": 443, "users": [{ "id": "uuid-вашего-юзера-на-евро-ноде", "flow": "xtls-rprx-vision", "encryption": "none" }] } ] }, "streamSettings": { "network": "xhttp", "security": "reality", "realitySettings": { "fingerprint": "chrome", "serverName": "vkvideo.ru", "publicKey": "ваш-pbk-с-евро-ноды", "shortId": "ваш-sid" }, "xhttpSettings": { "mode": "packet-up", "path": "/api/v1/update" } } }, { "protocol": "freedom", "tag": "DIRECT" } ] }
3. Traffic Splitting (Routing)
On the Russian node, we configure routing so that Russian websites (VK, Gosuslugi, Yandex) go directly, and blocked ones go through the bridge, also to avoid consuming traffic.
"routing": { "domainStrategy": "IPIfNonMatch", "rules": [ { "type": "field", "outboundTag": "DIRECT", "domain": [ "geosite:category-ru", "regexp:\\.ru$", "geosite:yandex", "full:cp.cloudflare.com" // Фикс "вечного таймаута" на клиентах ] }, { "type": "field", "inboundTag": ["inbound-от-клиента"], "outboundTag": "chain-to-europe" } ] }
Solving common problems
How to avoid crashing iOS?
On an iPhone, the memory limit for the VPN process is only 50 MiB. If you put large Geo-files in the config, the client will crash on startup.
Use packet-up instead of stream-up. If that doesn't help, switch to lightweight versions of Geo-files.
If WhatsApp or Instagram disconnects
It often happens: Instagram works fine, but WhatsApp is stuck on 'connecting'.
Workaround 1: Add IPv6 to the exit node.
Workaround 2: Try removing the vision stream from the config for these services.
Optimization for high load
If you have a crowd on your cascade, tweak /etc/sysctl.conf:
net.core.somaxconn=9000000 net.ipv4.tcp_max_syn_backlog=9000000 net.ipv4.tcp_syncookies=0 # Только если уверены в защите от DDoS
Which hosting provider in Russia to choose?
If your 'relay' itself is not on the whitelist (WL), the magic won't work.
Yandex.Cloud: The most reliable option. You need to look for good IP ranges.
VK Cloud: Traffic is free, but it's almost impossible to get 'whitelisted' IPs.
EDGE: A good alternative with a CDN.
How to check: Deploy any web server on port 443. If the site opens on a mobile phone (MTS/Megafon) without a VPN, the IP is 'whitelisted'.
If you don't want to bother
Setting up a chain manually is an interesting option, but not everyone is willing to bother and spend time on it. In discussions, people have highlighted services that have already implemented chains and 'whitelisted' IPs:
hynet.space: It is noted as the most universal solution, works stably on most major providers, and delivers good speed.
Amnezia: It works quite well, but in chats, people often complain about its closed nature; it doesn't play well with other services on the same VPS and often gives errors when trying to configure something more complex than the standard config.
Voxiproxy: Optimized for mobile traffic, but according to reviews, their potential is mainly realized on smartphones.
MamontVPN: Currently, they are almost entirely focused on fixing specific iOS issues, but they are also mentioned as an option.
SayVPN: Complex chains via vnext for specific tasks.
DuckVPN: It shows results on a number of providers, but in chats, there are often messages about serious accessibility problems through Megafon and MTS.
To sum up
TSPU has finally switched to an economy mode: they no longer need to block protocols completely, it's enough to just 'freeze' sessions right after the first data packets.
Today, a chain is essentially the only working way to get through whitelists and volume-based filtering.
But there are pitfalls here: finding clean IPs in the clouds has turned into an endless lottery.
Many are gradually migrating from old static panels to Remnawave. At least there, you can manage complex chains and routes in a user-friendly way, without rewriting configs by hand a hundred times.