Geo-splitting traffic: why routing

A naive VPN drives all traffic through the node — and the client loses banks, marketplaces, catches "VPN detected," and leaves. A proper service routes: the blocked stuff through the node, the Russian stuff directly. I'll break down why, why anti-fraud sits on foreign domains, and why rule order matters more than the list. No configs.

This material is about engineering your own infrastructure and is educational in nature. Complying with the laws of your own jurisdiction is on you.

Why "everything through the node" is bad

The simplest VPN wraps all traffic into the tunnel. It works, but for a Russian client it's a direct path to churn. Since 2025–2026, Russian services, at the regulator's demand, cut access via VPN: marketplaces, cinemas, payment systems, banks, government services, carriers. If all of a client's traffic goes through a foreign node — they lose access to these, see "foreign login," catch captchas, and leave.

The solution is split routing: dividing traffic by destination.

RU sites/services  ──▶  direct   (from the client's home IP, fast and not blocked)
Everything else    ──▶  proxy    (through the node — what's blocked in Russia)

As a bonus, Russian sites load faster (no detour abroad), and the load on the nodes drops. But the main thing is that the client gets an "invisible" VPN: the blocked stuff opens, while Russian services and IP checks behave as if the VPN were off.

What routing through the Xray core gives

The key idea: the split lives in the Xray core on the client, and this gives what a "dumb" full tunnel fundamentally can't.

• YouTube on a separate route. It can be sent to a Russian exit separately from the rest. With a Russian IP ads barely run — and at the same time the video doesn't drag a detour abroad. (For the mechanics of "why a Russian IP removes ads but not the throttling" — a separate discussion in the section on Google.)
• Bypassing "VPN detected" at banks and social networks. You send them to direct → they see the client's real home IP → they work normally, without banners and captchas.
• A real IP everywhere a bypass isn't needed. The core touches only the blocked stuff; everything else goes directly with the real address. So anti-fraud and geolocation see a real client, not "a person from another country."
• Faster and cheaper. RU traffic doesn't take a detour, only what's actually blocked goes to the paid nodes.

How to read rules: top to bottom, first match

This is the foundation of everything; without it routing turns into a lottery. Rules are executed in order, and the first match wins. As soon as a packet matches a rule — it goes by it, and the remaining rules aren't consulted.

From this it follows that order matters more than the list. The same set of rules, reordered, produces different behavior. The classic base looks like this:

1. IPs from Russia and private → direct. Catches Russian services by IP, even if the domain isn't on the list.
2. Russian domains → direct. A built-in list of thousands of RU domains plus an explicit list of critical ones (banks, government services, marketplaces, carriers).
3. Ads/trackers → block (a nice bonus for the client, optional).
4. Everything else → proxy. This is where what's blocked in Russia lands.

Change the order — change the logic. Put proxy above the Russian rules and all the traffic goes into the tunnel, and the whole point is lost.

The non-obvious: anti-fraud sits on foreign domains

The most valuable and most counterintuitive point. It seems logical: a Russian service — a Russian domain — send it to direct by .ru. But Russian services detect VPNs not by their own domain, but through anti-fraud engines that live on foreign domains. Magnit, large banks, retail chains, almost all mobile apps check "is this a VPN?" through third-party analytics and attribution domains — and those aren't .ru.

And here's the trap: if you drive such a foreign anti-fraud domain through a Russian node, then by the destination geo it goes abroad → the engine sees a data-center IP → "VPN detected." Even if you seemingly sent the service itself directly.

The takeaway many miss: into direct you put not only .ru domains, but also the foreign domains of Russian services (their anti-fraud, analytics, mobile app attribution). Only an exit from the client's home residential IP convinces these engines there's no VPN. A home IP is better for anti-fraud than any data-center one.

Three more things that break the naive scheme

From real-world experience, so you don't step on them:

• geosite/geoip can crash the client. Rules are executed on the client with its geo-database files, and for some users they're stripped down — the core crashes ("no YOUTUBE section"). Keeping geo files on the nodes is useless: the rules are on the client. More reliable is geo-dat-free — explicit regexps, domains, and CIDRs instead of references to geo databases.
• The order of special cases. Services throttled in Russia (TikTok, say) must be placed above the Russian rules, or they'll go to direct and won't open. And IP-check sites, on the contrary, are driven to a Russian exit, so the client sees a Russian IP and isn't scared off by "my VPN is exposed."
• QUIC on 443 gets muffled. Otherwise video "sticks" in the tunnel — stuck QUIC over a high-latency channel gives the symptom "the download goes, but the video doesn't."

The bottom line

Split routing isn't "a setting for show," it's the difference between a VPN people leave and a VPN the client doesn't notice in daily life. The blocked stuff opens through the node, the Russian stuff lives with a home IP, anti-fraud stays quiet, checks see the real address. The complexity hides in two places: rule order and understanding that Russian services are exposed through foreign domains.

Next — in the practice: a ready split-routing config, a list of critical domains, the geo-dat-free approach, and delivering the rules to the client via the subscription template. Step by step in "Routing rules: setup."