V2Ray Routing Rules: geosite and geoip Split Tunneling Examples

At a glance

Start by distinguishing domain lists, IP address lists, and outbound tags. Then order rules as follows: specific exceptions, mainland China domains, mainland China and private IPs, and proxy for everything else. This guide is for users who have imported a node and want to adjust split tunneling in v2rayN. The examples use traditional V2Ray/Xray routing fields and explain how DNS, rule databases, and client-generated configuration fit together.

Understand geosite, geoip, and proxy outbounds

Routing determines which outbound handles a connection; it does not determine which proxy protocol to use. VMess and VLESS are proxy outbound protocols, while geosite:cn and geoip:cn are matching criteria. You can change the node protocol in your subscription without changing the routing rules, as long as the outbound tags remain the same.

Rule syntax	Matches	What it does not tell you
`geosite:cn`	Domains included in the current rule database's cn category	Not every Chinese-language site, and not all IP addresses in mainland China
`geoip:cn`	IP ranges categorized as CN in the current rule database	Does not establish where the site operator is based or the connection quality
`geoip:private`	Private and special-use addresses defined by the rule database	Not a replacement for all local network routes managed by the operating system
`outboundTag`	The tag string of an existing outbound	Writing proxy does not create a proxy node

Traditional configurations read domain and IP sets from geosite.dat and geoip.dat. Here, “cn” is a data category, not a geographic determination made by the core at runtime. Results depend on the rule database source, release date, and category maintenance. If a newly enabled domain is missing from the set, add an exact-match exception first, then consider updating the data.

Order rules for direct connections in China and a proxy fallback

Routing rules are generally checked from top to bottom in array order. The first rule that fully matches selects the outbound; the core does not keep searching for a “more specific” rule. When a rule includes different fields such as domain, IP, and port, those conditions generally all have to match. Multiple entries in the same domain list, however, are alternatives: matching any one is enough.

Recommended setup: direct in mainland China, proxy everything else

Domain rules

First, add exact-match exceptions that must always use a proxy or connect directly.
Next, use geosite:cn to match the mainland China domain set.
Once a connection matches a domain rule, subsequent IP rules are not checked.

IP rules and fallback

Use geoip:private for private addresses.
Use geoip:cn for IP addresses in mainland China.
Finally, send remaining TCP and UDP connections to the proxy outbound.

Put exact-match exceptions before broad sets. Keep the proxy fallback last, and make sure it works with your domain resolution strategy.

For example, if a domain is in the cn set but should use a proxy, put its proxy rule before geosite:cn. Adding a proxy rule at the bottom will not help because an earlier direct rule has already ended the match. Conversely, putting “proxy all TCP and UDP” first prevents the mainland China rules below it from being reached.

full:example.com: matches this exact domain only, not its subdomains.
domain:example.com: matches the domain and its subdomains, but not notexample.com.
regexp:: for regular expressions. For ordinary site exceptions, prefer one of the first two options to avoid an overly broad match.

Review the JSON configuration and domainStrategy

The following is a routing snippet, not a complete configuration with nodes, inbounds, and DNS. It assumes you already have a working proxy outbound tagged proxy and a direct outbound tagged direct that uses the freedom protocol. The example domain example.com is included only to demonstrate an exact-match exception; remove the first rule if you do not need it.

{
  "routing": {
    "domainStrategy": "IPOnDemand",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

This example deliberately uses IPOnDemand: if a domain does not match either of the first two rules, the core attempts to resolve it when it reaches an IP rule, then matches the result against mainland China or private address ranges. A connection that matches the cn domain set selects direct immediately, so there is no need to resolve it for later routing rules. Requests made directly to an IP address go straight to address matching.

This configuration

Resolution strategy: IPOnDemand
Mainland China domains: geosite:cn → direct
Mainland China and private IPs: geoip:cn / private → direct
Final fallback: tcp,udp → proxy

Resolve domains as needed when an IP condition is evaluated. This suits the explicit fallback structure in this guide, but resolution failures or inaccurate results can still affect matching.

Alternative setup

Resolution strategy: IPIfNonMatch
When resolution occurs: After the domain fails to match any rule
Broad fallback: Avoid matching every connection too early
When no rule matches: Usually sent to the first outbound in the configuration

Check the outbound order as well. Simply changing the strategy name in this guide does not guarantee the same behavior.

AsIs does not resolve domains to IP addresses for routing. It suits setups based mainly on domain rules, but domain-only requests will not automatically match geoip:cn. Routing's domainStrategy controls rule matching; the same setting on a direct outbound affects destination address handling. They serve different purposes and are not interchangeable.

Save the rules in v2rayN and verify they work

The steps below use the Chinese-language v2rayN desktop interface, which includes “Settings” and “Routing settings.” Dialog layouts and rule editor labels may vary between versions. First confirm which routing profile is active, then edit its rules. This example uses V2Ray/Xray JSON structure; do not paste it into a single-line domain field that does not accept JSON.

Keep a copy of the original configuration

Open “Settings” → “Routing settings,” note the active routing entry, and save a copy of its original contents. If you can add a routing entry, create a separate test profile rather than overwriting rules that already work.
Check the outbounds

Confirm that the current node connects, then check the direct and proxy outbound identifiers used by the client rules. The proxy and direct tags in this example must match the tags in the generated configuration; do not substitute the node's display name.
Add the rules in order

In “Settings” → “Routing settings,” edit the target routing entry and add the domain, IP, network, and outbound fields in the order shown. Set the domain resolution strategy to IPOnDemand. Do not combine all conditions into one rule.
Apply the changes and reconnect

Save and enable the routing entry, then restart the core or apply the configuration as prompted. Make sure no override mode is forcing all traffic through the proxy or directly. Start a new connection to test; existing long-lived connections may not switch routes immediately.
Check the logs

Open the client logs and visit a mainland China domain, another domain, and a local network address. If access logs are available, check the destination address and selected outbound tag. If the rule database fails to load or an outbound cannot be found, fix the configuration before testing further.

Clients often regenerate the core configuration from their interface settings. Direct edits to a temporary generated file may be overwritten the next time you switch nodes or restart. Store long-term rules in the routing settings supported by the client. Maintain the entire JSON configuration yourself only if you are explicitly using a complete custom configuration.

On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Similar rule fields do not mean their interfaces, built-in rule databases, or custom configuration import methods are identical. Before migrating rules, check the capabilities of the current core and client. Do not import a subscription URL as a routing rule.

Check routing with ports, logs, and DNS

To verify routing, check whether a connection reaches the core and which outbound it selects—not just how quickly a page loads. A DNS cache hit, a reused connection, or cached content from a remote server can make speeds vary significantly without proving that routing is correct. The three values below are test inputs, not results measured by this site or defaults for every client.

10808

Assumed local SOCKS port for the commands below

443

HTTPS test destination port

192.168.1.1

Use for private network testing only when the gateway matches

First, open “Settings” → “Parameter settings” and check the local listening port and SOCKS support. If SOCKS is listening at 127.0.0.1:10808, run the command below in a terminal; on Windows, you can explicitly call curl.exe. socks5h sends the destination domain to the proxy for resolution, which is useful for checking domain rules. socks5 usually resolves the domain locally, so the core may receive an IP address instead.

curl --proxy socks5h://127.0.0.1:10808 --head --max-time 15 https://www.baidu.com/
curl --proxy socks5h://127.0.0.1:10808 --head --max-time 15 https://example.com/

The first command checks the path for a mainland China domain. Whether it connects directly depends on the current geosite data and logs.
With the first example rule still in place, the exact-domain exception should route the second command through proxy.
A request timeout does not necessarily mean that no rule matched. Also check whether the proxy node, destination service, and DNS are working.
After each change, send a new request to avoid reusing an existing browser connection.

If an app passes only an IP address to the core, domain rules may have no domain to match. Sniffing can provide domain information for some protocols and connections, but it cannot identify all traffic and may change matching results. When troubleshooting, record the actual form of the destination first, then decide whether to adjust sniffing. Avoid changing DNS, sniffing, and routing at the same time, or it will be difficult to isolate the cause.

Fix proxy routing for mainland China sites and rules that do not work

Added geosite:cn, but mainland China sites still use the proxy?

First, open “Settings” → “Routing settings” and confirm that the routing entry is enabled. Then check whether an earlier rule proxies all traffic. If the logs show that the domain is missing from the set, temporarily add a domain: exception before the fallback. If the request arrives as an IP address, investigate geoip and DNS instead of adding more domain rules.

What should I do if geosite or geoip fails to load?

Check the error for the rule database name, category name, and path it references. Use the client's data update feature to restore the relevant file, then restart the core. Do not rename a rule file in another format to .dat. For custom data sources, confirm that they include the required categories, such as cn and private.

Switched to IPIfNonMatch, but mainland China IP rules no longer match?

Check whether a catch-all rule such as network: tcp,udp is still at the end. If a domain matches it first, the core will not resolve the domain under the “resolve if no rule matches” condition. Restore the IPOnDemand structure from this guide, or redesign the rules without an early fallback and check the first outbound.

Local network access is failing. Is adding private enough?

First, confirm the actual address—for example, whether the gateway really is 192.168.1.1. If the request reaches the core, check whether the private address is routed to direct. If TUN exclusions, operating system routes, or a firewall block it, core routing alone cannot fix the problem. A direct route only selects the local network path; it does not guarantee that the destination is reachable.

Why didn't split tunneling change after updating the subscription?

A standard node subscription mainly updates connection settings; it does not necessarily update the routing database or local routing configuration. Check subscription updates, geo data updates, and the active routing entry separately. Change one item at a time, then check the logs with the same test domains to identify what caused the change.

Keep a short list of exceptions and record each domain, intended outbound, and reason for adding it. Fix overly broad rules and their order before adding more categories. Direct connections in mainland China with a proxy fallback for everything else is an easy-to-understand default, not the only option for every network. Verify the final setup against your needs, resolution results, and core logs.