V2Ray Routing Rules: geosite and geoip Split Tunneling Guide

1. What geosite and geoip Match

Routing rules don’t change a node’s protocol. They select an outbound for each connection entering the core. VMess, VLESS, and other protocols determine how a proxy connection is established; routing rules decide whether a destination uses the proxy, a direct connection, or another configured outbound. Having a working node in your subscription doesn’t mean you already have a suitable routing policy.

geosite:cn refers to the cn category in the domain data file, while geoip:cn refers to the set of IP addresses in China in the IP data file. The first checks whether a domain appears in a list; the second checks whether a destination IP falls within a listed address range. Neither detects a website’s language, and neither guarantees that every service in mainland China, cross-border site, or CDN address will behave as you expect.

When specifying domains, use full: or domain: for clarity. A plain string may match as a substring and catch unrelated sites with similar names. By contrast, domain:example.com matches the domain and its subdomains, but not notexample.com. The example.com references in this guide illustrate syntax only; they are not connectivity test services.

2. Rule Order: Put Custom Exceptions Before Lists

Standard field rules are checked in array order. The first match determines the outbound; the router won’t automatically choose the rule that seems more specific. When a rule contains both domain and port, both fields generally need to match. Multiple entries in the same domain array are alternatives—any one can match. To match “this domain or this IP,” use two separate rules.

1. Start with essential exceptions: For example, put business domains that must use the proxy first, so a later direct-connection list doesn’t catch them beforehand.
2. Next, add domain lists: Send recognized domains in mainland China directly, avoiding extra DNS lookups for routing where possible.
3. Then check addresses: Send private addresses and IPs in mainland China through the direct outbound to cover destinations accessed by IP.
4. Handle unmatched connections last: This example uses the first outbound as the default rather than adding an unconditional catch-all rule.

Another common misconception is that “direct in mainland China, proxy elsewhere” accurately identifies where every company is based. In practice, this policy combines list matching with a default outbound: connections outside the mainland China lists use the proxy by default, but that doesn’t prove they’re located abroad. Handle cross-region deployments, corporate intranet domains, and services that require a fixed egress with explicit exceptions.

3. Choosing a domainStrategy Value

routing.domainStrategy controls how DNS resolution results are used for routing matches. It doesn’t directly choose which DNS service a browser uses, and it differs from the domain resolution policy of the direct outbound. When troubleshooting, first confirm which configuration object you’re editing; identical field names don’t guarantee identical behavior.

This example uses IPIfNonMatch. A domain matching geosite:cn is routed directly. If an unknown domain has no match on the first pass, its resolved IP may match geoip:cn. Results can differ if DNS lookup fails, the returned address isn’t in the target list, or an earlier rule has already matched.

Take extra care with rule order when using IPOnDemand: if an earlier IP rule matches based on the resolved address, later domain exceptions won’t be checked. Putting custom domain exceptions first is usually easier to maintain than continually adding address ranges afterward.

4. Routing Example: Direct in Mainland China, Proxy by Default Elsewhere

The snippet below shows only the top-level routing object; it isn’t a complete client configuration and can’t run on its own. The full configuration’s outbounds must define a proxy outbound tagged proxy and a direct outbound tagged direct, with proxy as the first outbound. The existing client configuration supplies the node address, authentication details, and inbound settings.

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

• Rule 1: Send exact-domain and domain-suffix exceptions through the proxy first. Remove or edit these examples to suit your needs.
• Rule 2: Send connections matching the mainland China domain list directly.
• Rule 3: Send destinations in private address ranges or the mainland China IP list directly.
• Default outbound: Connections that don’t match any rule use the first outbound. Check the outbound order in the final generated configuration.

With this traditional data format, the core also needs access to the corresponding geosite.dat and geoip.dat files. Missing files, incorrect paths, or nonexistent categories can cause errors while loading the configuration. Reload the core after updating the rule data. Before switching data sources, check that the categories you use are still available.

5. Apply and Verify the Rules in v2rayN

In standard node mode, v2rayN typically generates the core configuration, so edits to a temporary JSON file may be overwritten the next time it starts. Manage rules through Routing settings where possible; use the appropriate custom-configuration entry when you need a fully customized config. Button locations may vary between desktop versions. The steps below refer to an interface with a Settings → Routing settings entry.

1. Back up the current rules

   Open Settings → Routing settings, save a copy of the existing rules, and note which routing profile is selected. Don’t delete the original profile yet—you’ll need it to roll back if testing fails.

2. Organize the rule order

   Edit a test profile in Routing settings and add, in order, domain exceptions, mainland China domain rules, and IP rules. Enter each value in its corresponding field in the rule editor; don’t paste the entire top-level JSON into a single domain field.

3. Check the resolution strategy

   Set the profile’s domain strategy to IPIfNonMatch and verify each rule’s outbound. If the interface doesn’t expose this field, inspect the generated configuration; don’t infer its value from the profile name.

4. Select the profile and reload

   Save, select the routing profile you just edited, and then reload the core. Saving in the editor doesn’t necessarily activate the profile. Check the loaded configuration and logs to confirm what’s in use.

5. Test each outbound

   Test destinations that should use a direct connection, the proxy, and your local network. Check the destination and outbound tag in the logs. Close existing connections before testing; long-lived connections won’t automatically switch outbounds when rules change.

Before verifying, make sure traffic is actually reaching the core. If an app doesn’t use the system proxy, even a complete routing setup can’t handle its traffic. The numbers below are example test settings, not defaults for every installation. Check the listening port in your client before running the command.

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com/

Here, socks5h passes the destination domain to the proxy for resolution, which helps test domain rules. If the domain is resolved locally first, the core may see only an IP address, so the results aren’t directly comparable. The domain in this command matches the first rule in the example. Check for the proxy outbound tag rather than using whether the page loads as proof that routing worked.

6. System Proxy and TUN: Verify Based on How Traffic Is Captured

The same routing rules can behave differently depending on how traffic is captured. The node hasn’t changed; the destination information available to the core has. With a system proxy, an app may pass the domain directly. With TUN, a connection usually arrives as IP packets, and whether the domain can be recovered depends on settings such as DNS interception and sniffing.

Desktop v2rayN, Android v2rayNG, and v2flyNG can use similar routing goals, but their menus, tags, and import formats aren’t necessarily identical. v2rayNG focuses on the Xray core, while v2flyNG uses the V2Fly core. When migrating rules, check which fields and data formats the current core supports. Node subscriptions may not include client-side routing settings.

7. Common Misconfigurations: Narrow Down the Cause with Logs

Change one variable at a time: confirm traffic capture, check that the configuration loads, verify which rule matches, then investigate DNS and the actual connection. Temporarily increasing log detail can help, but remove subscription URLs, authentication details, and other sensitive information before sharing logs. For more configuration fields, see the Configuration Reference. For connection-level issues, work through the Troubleshooting Guide.