V2Ray Routing Rules: Split Traffic with geosite and geoip

1. Check that traffic reaches the core

Routing rules only apply to connections that reach the core. v2rayN is a desktop client; v2rayNG is an Android client that uses the Xray core, while v2flyNG uses the V2Fly core. The graphical interface manages the configuration, but the active core performs the actual matching. VMess and VLESS are proxy protocols; switching protocols will not fix incorrectly ordered rules.

System proxy settings usually affect only apps that respect them. If an app connects directly, the corresponding connection will not appear in the core's logs. Android VPN mode may also be configured to bypass selected apps. Before adding geosite categories, make sure the target app's connection is reaching the intended inbound.

Port 10808 is used for this example only; it is not the default for every version. Check the active inbound configuration in your client for the listening address, port, and whether SOCKS is enabled. The port is the local entry point, while 443 is usually used by the remote website—don't confuse the two. DNS can also use encrypted transport, so not every DNS request uses UDP port 53.

2. What domain, IP, and data-set rules match

domain and ip are routing rule fields. geosite: and geoip: reference data sets used by those fields. The former does not look up a domain's country in real time, and the latter does not determine where a website's business is based. Matching uses data files bundled with or installed for the client or core, so results depend on the data source and its update date.

When you need a precise domain boundary, use full: or domain:. A plain string without a prefix is usually matched as a substring, which can also catch unrelated domains with similar names. Category names must exist in the data files actually installed; copying a category name from elsewhere does not guarantee that your local data files include it.

3. Rules are evaluated in order, not by specificity

Common field-based rules are checked from top to bottom, and the first matching rule determines the outbound. The core won't automatically let a more specific rule below override a broader one above. Put manual exceptions before category rules, and category rules before the fallback behavior.

1. Put explicit exceptions first: For example, a test domain that must use the proxy, even if it also belongs to a direct-connection category.
2. Next, add local and category rules: For example, private addresses, domains in mainland China, and address ranges in mainland China.
3. Set the default outbound last: When no rule matches, use the fallback path defined by your configuration.

Within a rule, multiple entries in the domain array mean “match any.” But different condition fields in the same rule usually must all match. For example, combining domain and port means the specified domain and port must both match—not either one. If domain and address categories are separate reasons to connect directly, use two rules.

4. A routing snippet for direct connections in mainland China and proxy routing elsewhere

The snippet below shows only the routing object. It assumes your existing configuration has a direct outbound tagged direct and a proxy outbound tagged proxy, with proxy as the first entry in the outbounds array to serve as the default for unmatched traffic. Tags are references: a UI label that says “direct” does not guarantee the internal tag is actually named direct.

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

example.com is a reserved example domain used to demonstrate exception priority, not a recommended service to route. The configuration sends the specified domain through the proxy, connects directly to recognized private destination addresses, connects directly when a domain or address matches a mainland China category, and sends remaining requests through the first proxy outbound. This is one routing policy, not a universal answer for every network.

• Data files: You need usable geosite and geoip data files that include the relevant categories. If a file fails to load, resolve the startup error first.
• Local access: geoip:private is a special address category in the data set. Before allowing direct connections to it, make sure local network access meets your isolation requirements.
• Fallback behavior: If the first outbound in the client-generated configuration isn't proxy, change the default outbound in the client. Don't paste this snippet and assume all remaining connections will use the proxy.
• Import format: A routing editor may accept only a rules array, while a complete custom configuration also needs sections such as inbounds and outbounds. Check the required import format first.

5. How domainStrategy interacts with DNS

AsIs does not resolve domains for routing. If the inbound supplies a domain, IP rules generally cannot match it on their own. IPIfNonMatch tries to resolve the domain after it fails to match a rule, then uses the resulting IP for matching. IPOnDemand may trigger a lookup as soon as rule evaluation encounters a condition that requires an IP. The timing differs, which can affect whether earlier IP rules get a chance to match.

In the snippet above, only requests that fail to match a domain rule can use the resolved IP to match geoip:cn. If you add a catch-all domain proxy rule at the end of the rules list, it will match during domain evaluation, so IPIfNonMatch won't fall back to IP matching because the request has already matched. To preserve that fallback path, use the default outbound instead of adding a catch-all rule.

The routing resolution strategy and the way the final outbound resolves a destination are separate settings. Even with AsIs for routing, a direct outbound may still need to resolve the domain. DNS responses can point to CDN addresses in different regions or return IPv4 only or both IPv4 and IPv6, changing the address category match. Record the domain, resolved address, and outbound tag separately instead of checking only whether the page loads.

6. Troubleshoot rule conflicts with a consistent test

In v2rayN, open Settings → Routing settings and check which rule set is active. The menu names may vary between versions, so follow the current interface. In v2rayNG and v2flyNG, check each client's own routing settings and active configuration; don't assume another client's option names apply. When copying configurations between cores, also check that the fields and data-file formats are compatible.

1. Record the baseline: Note the active core, routing mode, rule order, and local listening port. First confirm that the proxy node itself can connect.
2. Check the inbound: On desktop, run the command below to send traffic explicitly through the local SOCKS endpoint and let the proxy resolve the domain. Replace the port with the one in your configuration.
3. Check the outbound: Find the test domain, destination IP, and outbound tag in the client's connection or access logs. Log formats vary by core version.
4. Isolate the rules: Temporarily put a full-match rule for the test domain first, directing it to direct and then to proxy. If the outbound changes accordingly, the routing path and tags are probably working.
5. Restore the categories: Remove the temporary rule. Test one domain serving mainland China, one other domain, and one local address to confirm category matching and fallback behavior.

curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

The 10-second value here is the connection timeout; 20 seconds is the overall command timeout, not a performance test result. --socks5-hostname takes a different path from resolving the domain locally and submitting an IP, so it's useful for testing domain rules. A successful HTTP request confirms only that this path works; it doesn't prove that UDP, every app, or TUN routing is configured correctly.

7. Common questions about geosite and geoip routing

Reliable traffic splitting isn't about having more rules; each rule needs a clearly defined scope and a result you can explain from the logs. Start with a small set of exceptions, categories, and a default outbound, then fix real misrouting one case at a time. This is easier to review than importing a large set of overlapping rules all at once. For more on how clients and cores work together, see the protocol reference and concept glossary.