Routing Rules in Practice: Split Tunneling for mainland China Sites and Match Order

Two Dimensions of Split Tunneling: Domain and IP

A routing rule is basically a condition plus an outbound. Conditions come in four main kinds — domain, IP, port, and network type — while outbounds come in three: proxy, direct, and block. The usual split tunneling setup writes one set of rules for each of the two condition types: domains matching geosite:cn go direct, IPs matching geoip:cn go direct, and everything else goes to the proxy.

The decision happens inside the core, and the order is fixed. The destination is matched in whatever form it arrives in: if the application hands the core a domain, domain rules are compared first. Only when no domain rule matches does the core consult the domain strategy to decide whether to resolve an IP, and then compare that IP against the IP rules.

This order explains a very common symptom: a config with geoip:cn but no geosite:cn barely does anything when the domain strategy is AsIs — the core never resolves the domain, so there is no IP to compare, and every request falls through to the default outbound at the bottom of the list.

The reverse has its own limits: if the application resolves DNS itself and hands the core an IP address, domain rules have nothing to act on either. Accurate split tunneling starts with getting domains into the core as domains.

Match Order: Top to Bottom, First Hit Wins

The rule list is an ordered array, not a set. The core compares from the first entry down, stops at the first match, and ignores everything after it. Order is the logic: block rules before direct rules, direct rules before the catch-all.

In v2rayN, Settings → Routing Settings is where this array lives, and the Proxy, Direct, and Block entries in the outbound dropdown map to the proxy, direct, and block outbound tags in the core config. Each row describes a single condition combination; you change the order by moving rows up and down.

An order that covers most situations looks like this. The last row is not a rule — it is the default outbound the core uses when nothing matches.

Getting the order wrong has concrete costs. Put IP rules ahead of domain rules and, under the IPOnDemand strategy, every connection resolves the domain first — adding first-packet latency and risking a misjudgment when a CDN resolves to an IP outside mainland China. Put block rules last and ad domains get swallowed by an earlier direct or proxy rule, so the block rule is never reached.

Four Ways to Write Domain Rules

Domain conditions accept four prefixes, from broadest to narrowest. Using the wrong prefix is the most common cause of inaccurate split tunneling.

Beyond prefixes, you can reference geosite collections directly: geosite:cn covers common mainland China domains, geosite:geolocation-cn is a broader tier, geosite:private holds LAN domains, and geosite:category-ads-all is the ad and analytics domain collection. Collection data ships bundled with the rule files, so newly registered domains lag behind — a frequent reason rules are in place yet traffic still leaks.

A single rule can carry several conditions separated by commas; matching any one of them counts as a match.

"domain": [
  "domain:qq.com",
  "full:www.example.cn",
  "keyword:doubleclick",
  "regexp:.*\\.google\\.com$",
  "geosite:cn"
]

One caveat: keyword: and regexp: are Xray core extensions and do not work under the v2ray core. v2rayN lets you switch cores under Settings → Parameter Settings, v2rayNG always uses the Xray core, and v2flyNG uses the v2fly core; before moving rules between cores, confirm whether these two syntaxes are supported.

IP Rules and Where geoip:cn Actually Applies

geoip:cn judges where an IP is registered, not where a domain belongs. A mainland China domain that resolves to an overseas CDN IP is treated as non-China, while an overseas domain that resolves to an IP in mainland China is treated as China. IP rules therefore work well as a fallback, not as your primary criterion.

LAN addresses need an explicit direct rule. geoip:private covers ranges such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 127.0.0.0/8; with only geoip:cn in place, requests to your router admin page, NAS, or network printer get pushed through the proxy — the node works, but local services will not open.

One more easily missed detail: the second pass under IPIfNonMatch restarts from the first rule with the IP attached. An IP rule sitting near the top of the list can hijack, on that second pass, a request that a domain rule should have caught. If the outbound tag in your logs does not match expectations, first work out which pass produced the match.

A Ready-to-Edit Rule Skeleton and How to Apply It

Putting the earlier conclusions together gives a complete ordered skeleton: block ad and analytics domains, send LAN traffic direct, send mainland China domains direct, send mainland China IPs direct, and route everything else through the proxy. You can copy it straight into v2rayN's routing settings or import it as a custom rule set.

"routing": {
  "domainStrategy": "IPIfNonMatch",
  "rules": [
    { "type": "field", "domain": ["geosite:category-ads-all"], "outboundTag": "block" },
    { "type": "field", "domain": ["geosite:private"], "outboundTag": "direct" },
    { "type": "field", "ip": ["geoip:private"], "outboundTag": "direct" },
    { "type": "field", "domain": ["geosite:cn"], "outboundTag": "direct" },
    { "type": "field", "ip": ["geoip:cn"], "outboundTag": "direct" }
  ]
}

Here is how to apply it in v2rayN.

1. Open the v2rayN main window and go to Settings → Routing Settings; in 7.x, the same list lives under Settings → Parameter Settings → the Routing tab.
2. Add the rules one by one, in order: enter geosite:category-ads-all, geosite:private, geoip:private, geosite:cn, and geoip:cn in the condition field, set each outbound to Block or Direct, and note the purpose in the remarks column.
3. Set Domain Strategy to IPIfNonMatch. Unless you need IP-level precision, avoid IPOnDemand — it forces an extra resolution on every connection.
4. Save, then restart the core so the new configuration is written to config.json and takes effect.
5. Using SOCKS port 10808 (HTTP port 10809), visit one mainland China site and one overseas site, then check the Logs tab to confirm the two requests carry the direct and proxy outbound tags respectively.

Do not judge verification by whether a page loads. A mainland China site opens through the proxy just as well; the outbound tag in the logs is what tells you: direct means it went direct, proxy means it went through the node. If a mainland China site shows proxy, the rules did not match — check the domain strategy first, then rule order, then DNS.

Common Problems and the Order to Troubleshoot Them

The four problems below cover most split tunneling failures. Always troubleshoot in this order: domain strategy first, rule order second, DNS last.

After editing rules, do not stop at a single test. Try two or three mainland China sites and two or three overseas sites, then scan the outbound tags in the logs to confirm direct and proxy both appear where you expect — only then are the rules settled.