V2Ray Routing Rules: Split Traffic with geosite and geoip

geosite vs. geoip: Different Match Targets

Routing does not determine where traffic goes based on a webpage's language or your device's location. When V2Ray core receives a request, it reads available information such as the destination domain, destination IP, and port, then checks for a match in routing.rules from top to bottom. When a rule matches, traffic is sent to the outboundTag specified by that rule. The tag must correspond to a tag that actually exists in outbounds.

geosite:cn is a category entry, not a guess based on a domain suffix. A .com domain may be on the list, while a site using an overseas CDN may have a domain category that differs from its IP's location. When domain information is available, routing by domain is usually easier to maintain than routing only by the resolved address.

v2rayN Routing Setup: Back Up Before Editing

v2rayN manages configuration and connections; the selected core actually applies the rules. Configurations in the Project V, V2Fly, and Xray ecosystems share some fields, but also have core-specific extensions. This guide uses only common field rules and does not transplant extensions from one core to another.

1. Note your current configuration

   On the main screen, note the current server, routing mode, and system proxy status. Open Settings → Parameter Settings and note the core in use and local listening ports. The interface may vary between versions, so follow what you see. Do not switch to a core that does not support your current server's protocol just to use this example.

2. Back up your routing rules

   Go to Settings → Routing Settings and back up the existing rules before creating or editing a routing profile for testing. Make sure this profile is selected on the main screen, rather than Global Proxy or Global Direct mode.

3. Check the outbound tags

   Check the configuration actually loaded by the core and verify the tag values for the proxy and direct outbounds. This guide uses proxy and direct as example tags. If your tags differ, update the rules' outboundTag values to match.

4. Apply the rules and check the logs

   Save the rules and have the client reload the core configuration, then check the startup results in the logs. If you see an unknown outbound, a data file loading failure, or a JSON parsing error, restore your backup before making further changes.

The client usually regenerates its runtime configuration. Direct edits to the temporary config.json may be overwritten when you switch servers or restart. For everyday use, save rules through Routing Settings. If you manage the configuration manually, maintain the snippet below in your own configuration source.

Routing Example: Direct in Mainland China, Proxy Everywhere Else

This is a standalone routing snippet, not a complete client configuration. Before using it, make sure you have a working proxy outbound and a direct outbound with protocol set to freedom; their tags should be proxy and direct, respectively. Also confirm that the core can read geosite and geoip data files containing the relevant categories.

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

• Rule 1 handles private addresses: Local network destinations such as 192.168.1.1 and 10.0.0.1 should not go through a remote proxy just to reach a router or internal service.
• Rule 2 handles mainland China domains: Matches for geosite:cn go direct immediately, without waiting for later IP conditions.
• Rule 3 handles mainland China IPs: This applies to destinations that are already IP addresses, as well as mainland China addresses obtained through resolution when the routing strategy allows it.
• Rule 4 is an explicit fallback: Send all remaining TCP and UDP requests to proxy, rather than relying on the default outbound order.

When no rule matches, the core typically uses the first outbound in outbounds. So you can send everything else through a proxy either with an explicit rule or by making the proxy the default outbound. These approaches affect IPIfNonMatch differently, so do not copy the rules without checking the outbound order.

domainStrategy: When to Resolve Domains for Routing

routing.domainStrategy determines whether routing tries to resolve a domain to an IP address for matching. It is not a system DNS setting, nor is it the same as the domain handling strategy on a direct outbound. Changing this field does not automatically take over DNS requests, encrypt them, or select an upstream resolver.

A domain can resolve to multiple IPv4 and IPv6 addresses, and changes to the DNS upstream can also change its CDN endpoint. A match for geoip:cn once does not guarantee that future connections will match. For a stable egress route, add a dedicated rule for the specific domain instead of permanently pinning a CDN IP that happened to appear.

Rule Order: First Match Wins

Rules are checked from top to bottom, and the matching rule determines the outbound. The core does not compare rules to see which is more specific. Put specific exceptions before broad categories and any catch-all rule last. This is the basic order for maintainable rules.

{
  "type": "field",
  "domain": ["domain:example.com"],
  "outboundTag": "proxy"
}

For example, if a domain is classified for direct routing by the domain database but your use case requires it to go through a proxy, put a dedicated rule for it above geosite:cn. example.com is a sample domain for demonstrating the syntax; replace it with your actual destination. To match only the exact domain and not its subdomains, use full:.

• Multiple values in one field usually mean “OR”: If the domain array contains two domains, matching either one satisfies that field.
• Different conditions in one rule usually mean “AND”: If you specify both domain and port, the destination must match both the domain and the port. Do not put domain and ip in the same rule expecting either one to match.
• Account for the actual protocol in port rules: A rule that matches only TCP does not cover UDP. Browsers often use UDP 443 for HTTP/3, so matching TCP 443 alone does not account for all web traffic.
• Rules only apply to connections that reach the core: A local address excluded by the system proxy bypass list may be accessed directly by the app. In that case, it is normal for the core logs to show no record.

Test and Troubleshoot: Check the Destination, Rule, and Outbound

A webpage loading only proves that this request completed; it does not prove that it used the intended egress. First confirm that the core started successfully, then make a consistent test request and check the destination and outbound tag in the access logs. Log formats vary between cores, and some show the inbound-to-outbound mapping. If the log level is too low, temporarily increase it for testing, then restore it afterward.

curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://www.baidu.com/
curl --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -I https://example.com/

10809 is an example HTTP proxy port, not a claim about the current v2rayN default. Replace it with the active HTTP or mixed listening port shown under Settings → Parameter Settings. The commands explicitly specify a local proxy to rule out whether the terminal follows system proxy settings. These requests mainly test the TCP path, not browser behavior over UDP.

Keep three records: the core in use, the routing rules, and the outbound tag for each test request. Before sharing logs publicly, remove subscription URLs, server credentials, and private browsing records. The goal of validating routing is to confirm that specific requests consistently use the intended outbound—not to judge every rule by a single speed test.