V2Ray Routing Rules in Practice: Split Mainland and Overseas Traffic with geosite and geoip

Quick overview

This guide is for users who can already connect to a node and are ready to refine their routing policy. The final configuration processes traffic in this order: block ads, connect to the LAN directly, connect to mainland domains directly, connect to mainland IPs directly, then proxy everything else. Each step is verified through core logs, the configured proxy port, and DNS results.

Define the routing goals and matching flow first

Routing insight

Routing does not establish proxy connections such as VLESS or VMess. It only chooses an outbound after a request reaches the core. The node address, port, transport layer, and authentication parameters still belong to the proxy outbound configuration; routing rules only reference existing outbound tags. Mixing these two layers is one of the most common reasons a node connects while the rules appear ineffective.

Routing insight

This example uses three outbound tags: proxy for the current proxy node, direct for the freedom direct outbound, and block for the blackhole blocking outbound. Tags are case-sensitive, and outboundTag in a rule must exactly match the outbound's tag.

Application sends requestLocal entry receives requestDomain rule matchingIP rule matchingSelect outbound

Routing insight

V2Ray and Xray check routing rules in array order. Once a request matches the first applicable rule, matching stops. Rules are therefore not prioritized by quantity: earlier rules always win. Place ad domains before mainland domains; otherwise, a domain belonging to both sets may be sent directly before the ad rule is reached.

Ad blocking

Match source: geosite:category-ads-all
Outbound tag: block
Recommended position: Rule 1

Block first, then classify by region, so ad domains are not sent directly by an earlier mainland rule.

Direct LAN access

Match source: geoip:private
Outbound tag: direct
Typical addresses: 192.168.0.0/16

Preserve local access to routers, file servers, and other devices on the private network.

Direct access to mainland resources

Domain set: geosite:cn
IP set: geoip:cn
Outbound tag: direct

Use separate domain and IP rules so logs clearly show which matching stage handled the request.

Proxy remaining traffic

Matched network: tcp,udp
Outbound tag: proxy
Recommended position: Last rule

The fallback rule must be last. If placed earlier, it can consume all subsequent TCP and UDP rules.

What geosite and geoip match

Routing insight

geosite is a collection of domains. When a request retains its domain information, the core can determine whether it belongs to geosite:cn or geosite:category-ads-all. Entries may be full domains, subdomain rules, or keyword rules; the actual scope depends on the version of the data files bundled with the client.

Routing insight

geoip is a collection of IP ranges. The core can use geoip:cn when an application connects directly to an IP, when domain matching fails and the target is resolved, or when the traffic entry point exposes only the destination IP. It cannot infer ownership from a website name; it only checks whether the destination falls within a range listed in the data file.

Matching method	Input	Example	Best suited for
geosite	Domain	`geosite:cn`	Domain collections maintained by site category or region
geoip	IPv4 or IPv6 address	`geoip:cn`	Direct IP requests and addresses returned by DNS resolution
domain	Explicit domain rule	`domain:example.com`	A small number of sites that need fixed overrides
ip	Explicit network range	`192.168.0.0/16`	LANs, private services, or networks you manage

Takeaway: preserve domain matching first, then use IP matching as a fallback

Using only geoip:cn makes domain requests depend on DNS resolution, adding another decision point and potentially making results dependent on where resolution occurs. Match clear domains with geosite:cn first, then let geoip:cn catch remaining mainland addresses for routing that is easier to explain and troubleshoot.

Complete routing configuration and rule order

Routing insight

The JSON below shows a minimal combination of routing and three outbounds for structural reference in advanced configurations. In practice, retain the inbound, DNS, logging, and proxy-server parameters from the existing configuration; do not overwrite the entire client configuration with this excerpt.

Routing insight

Set domainStrategy to IPIfNonMatch: the core checks domain rules first; if the domain does not match, it resolves the target and tries the IP rules. This enables geosite matching while allowing geoip to provide a second layer of detection.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "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"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": []
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

Routing insight

The empty vnext in this example only indicates that proxy-node parameters should come from an existing subscription configuration; it is not a usable node. In v2rayN, importing a subscription generates a complete proxy outbound. When maintaining routing manually, reference the proxy tag generated by the client rather than copying an empty array after removing the server information.

Start with rules that explicitly block or override traffic, such as ad domains and custom domains.
Then add geoip:private so private addresses such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 remain direct.
Next, add geosite:cn followed by geoip:cn to handle mainland domains and mainland addresses separately.
Finally, send network: tcp,udp to proxy as the fallback for unmatched requests.

Implementing the configuration in v2rayN

Routing insight

Using the v2rayN 7.10.x interface as an example, first open Settings → Parameter Settings and check the local listening ports and log level. Common configurations use SOCKS port 10808 and HTTP port 10809, but ports may differ after an upgrade or migration; verification commands must use the values shown in the current interface.

Routing insight

Routing is usually under Settings → Routing Settings. After creating a rule set, add ad domains, private IPs, mainland domains, mainland IPs, and the final proxy rule in that order, then make the set active. Button locations may change between 7.x releases, but the way to verify rule names, order, and outbound tags remains the same.

Routing insight

A subscription update may regenerate nodes, but it usually will not correct custom routing for you. After updating, confirm that the active rule set has not reverted to the default and that the selected node still maps to a usable proxy outbound. Restart the core after making changes; saving rules without reloading the core will not alter the active routing state.

Select an available node in the server list and run a real connection latency test.
Enable the system proxy and confirm that browser traffic reaches v2rayN's local listening port.
Open Settings → Parameter Settings and record the actual HTTP, SOCKS, and LAN-listening switch values.
Open Settings → Routing Settings and verify the active rule set and the order of its five rules.
Save the changes, restart the core, and check the logs for successful geosite and geoip data loading.

Verify that mainland and overseas traffic splitting actually works

Routing insight

A webpage loading only proves that the connection works; it does not prove that traffic used the expected outbound. During testing, observe the request target, the matched rule in the core logs, and the final outbound tag together. Temporarily set the log level to info for the check, then restore the original setting to avoid accumulating excessive logs.

Routing insight

For the first browser test, visit a site clearly included in the mainland domain set, a site that requires the proxy, and your router's management address. The expected results are direct for the mainland site, proxy for the other site, and a direct connection through geoip:private for the router address.

Routing insight

For the second test, bypass browser extensions and caches by sending a request directly through v2rayN's HTTP proxy port. If the current HTTP port is 10809, run the command below in a Windows, macOS, or Linux terminal. Replace the test URL with an HTTP service whose access logs you can inspect.

curl --proxy http://127.0.0.1:10809 https://your-test-endpoint.example/
curl --proxy http://127.0.0.1:10809 -I https://your-test-endpoint.example/
nslookup your-test-endpoint.example

Routing insight

Do not compare only the returned IP address. Some sites use distributed nodes, so the same domain may resolve to different addresses depending on the resolver's location. More reliable evidence comes from the v2rayN core log showing the destination domain, destination port, and the corresponding direct, proxy, or block outbound.

Why is a mainland site still going through the proxy?

Routing insight

First confirm that geosite:cn appears before the final proxy rule, then check whether the destination domain is still present in the logs. If the entry point exposes only the destination IP, verify domainStrategy and confirm that geoip:cn has loaded.

What if a LAN address suddenly stops opening?

Routing insight

Check that geoip:private points to direct and appears before the network: tcp,udp fallback rule. When accessing 192.168.1.1, the logs should not show proxy.

What if ad blocking removes page components?

Routing insight

Temporarily disable category-ads-all and test again. If it is a false positive, add an earlier direct rule for the required domain; do not move the entire ad rule below the mainland direct rule.

What if the rules are saved but the logs do not change?

Routing insight

Confirm that the rule set you edited is enabled, then restart the core. If v2rayN also has a predefined routing profile enabled, check whether the active profile is overriding the custom rules.

What if UDP requests are not being split according to the rules?

Routing insight

Confirm that the fallback rule's network includes both tcp,udp, and check whether the selected proxy node's transport configuration supports the target UDP traffic. A routing match does not guarantee that the outbound can carry the request.

Common deviations and maintenance practices

Routing insight

Routing results change as domain ownership, service deployments, and rule data are updated. A mainland service may use an overseas address, while an overseas brand may deploy nodes in mainland China. geosite and geoip therefore provide classifications from the rule-data layer, not real-time judgments about business ownership. For known targets such as work systems and services you manage, explicit domain rules are usually more stable than regional collections.

Routing insight

Keep custom override rules few and precise. To force a direct connection, place the specific domain rule before ad and regional rules and point it to direct; to force proxying, likewise place it before regional direct rules and point it to proxy. Document the purpose of every override so the list does not become an unexplained collection of exceptions months later.

After upgrading the core or client, check again that geosite and geoip data load successfully.
After updating a subscription, confirm that the active node and custom routing profile have not changed.
When adding a rule, test a single domain first, then expand it to an entire category or network range.
When access problems occur, inspect the rules from the first one onward instead of focusing only on the final fallback.
Keep a known-working older configuration so you can compare changes to rule order and outbound tags.

Takeaway: check order first, tags second, and data last when troubleshooting routing

Most issues can be isolated in three steps: determine whether an earlier rule intercepted the request, verify that the matched outboundTag exists, and confirm that the geosite and geoip collections loaded successfully. Only after all three pass should you investigate DNS and the node's transport layer.