V2Ray Routing Rules in Practice: Split Traffic Between Direct Connections in Mainland China and Proxies Abroad

Routing determines which outbound a connection ultimately uses. Nodes establish proxy connections; routing rules decide which requests use the proxy, connect directly, or get blocked immediately. These are separate layers: switching a VMess or VLESS node does not automatically fix split-routing rules, and updating a subscription usually does not overwrite custom local routing.

Understand the V2Ray routing rules matching model first

V2Ray and Xray routing rules are checked in the order defined by the configuration array. Once a connection matches the first complete rule, its outbound is decided and later rules are ignored. Put narrow, clearly targeted rules first and broad fallbacks last. Ad blocking usually comes before direct China traffic, followed by the final proxy fallback.

domain, ip, port, network, and protocol are matching conditions; outboundTag specifies the destination after a match. Configurations generated by v2rayN commonly use proxy, direct, and block as outbound tags, but always verify the labels in the configuration exported by the current client instead of guessing from their names.

Port numbers vary by client settings. The 10808 and 10809 values above only illustrate that the local entry port and the remote destination port are different concepts. In routing, port: 443 matches the destination's port 443, not v2rayN's local listening port. Confusing the two can cause browser traffic to bypass the intended rules entirely.

• Domain requests: Prefer domain rules, such as domain:example.com, full:example.com, or geosite:cn.
• IP requests: Direct IP access can be matched with geoip:cn, geoip:private, or CIDR ranges.
• Domain-to-IP resolution: Whether domains are resolved for IP-rule matching depends on domainStrategy.
• Final destination: If no rule matches, the connection uses the default outbound defined outside the routing configuration; the result depends on how the client generates its configuration.

Build a Fallback-Friendly Routing Setup in v2rayN

The steps below reference the Chinese interface in v2rayN 7.15.x. Menu layouts may change between minor releases, but the essential path remains Parameters, Routing, and the active routing mode. Before editing, note the current mode and confirm that at least one node passes a basic connectivity test; otherwise node failures and routing errors can look like the same timeout in the logs.

1. Check the Core

   Open “Settings” → “Parameters” → “Core type” and confirm the core used for the current protocol. VLESS nodes are usually handled by the Xray core; load older VMess configurations according to the fields actually provided by the subscription.

2. Record the Ports

   Go to “Settings” → “Parameters” → “Basic settings” to check the local SOCKS and HTTP listening ports. Also note whether LAN access is enabled, so testing tools do not connect to the wrong port.

3. Copy the Rules

   Open “Settings” → “Routing settings” and copy the current working rule set before editing. Do not overwrite the only working setup; keeping the original lets you roll back within a minute.

4. Set the Order

   Place ad blocking, private-address direct access, direct access for China domains, direct access for China IPs, and the final proxy rule in that order. Confirm that every item references an existing outbound tag.

5. Apply and Restart

   Save, select the new routing profile, restart the core, and re-enable the system proxy. Saving edits without switching the active profile does not change the configuration currently in use.

The system proxy only affects programs that follow the system proxy settings. A program that connects directly, uses another fixed proxy port, or keeps an old connection may not change its traffic immediately when v2rayN routing is edited. Close and reopen the target program, and confirm that the system proxy points to the current v2rayN listening port.

Combining Direct China Traffic, Overseas Proxies, and Ad Blocking

An easy-to-maintain rule set should handle the most certain traffic first. Classified ads go to the block outbound; LAN, loopback addresses, and China resources go direct; remaining TCP and UDP traffic goes through the proxy. There is no need to list every overseas domain—new sites naturally fall through to the final proxy.

The corresponding core configuration can use the structure below. This snippet shows only the routing object; a complete configuration still needs the existing inbound, outbound, DNS, and node parameters. If v2rayN's routing editor uses form fields, enter the rules one by one in the same order instead of pasting the whole object into a single domain field.

{
  "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"
      }
    ]
  }
}

domainStrategy: IPIfNonMatch means that when a domain does not match a domain rule, its IP may be resolved and checked against IP rules. It does not mean “check IP first, then domain,” nor does it resolve every domain unconditionally in advance. This mode suits typical split routing that uses both geosite:cn and geoip:cn.

1. Open a router administration address or LAN service and confirm that geoip:private uses a direct connection.
2. Visit a commonly used China-based site and check whether the log shows the expected domain and direct as the final outbound.
3. Visit a destination that requires a proxy and confirm that a broad custom domain rule has not sent it direct prematurely.
4. Open a test page known to make categorized ad requests and observe which domains are blocked; do not rely on a blank page alone.

How to Order domain, ip, GeoSite, and GeoIP Rules

Use domain rules to express site ownership and explicit domains. full:api.example.com matches only the complete hostname, domain:example.com matches the apex domain and its subdomains, and regexp: is for cases that genuinely require regular expressions. Regex rules cost more and carry a higher risk of false matches, so prefer exact domains or suffixes whenever they are sufficient.

geosite:cn is a domain-based data set organized by category, while geoip:cn is a data set organized by IP ranges. They are not two spellings for the same data. A site hosted abroad may still be categorized as China and be sent direct by GeoSite; if a domain is absent from the set but resolves to a China IP, IPIfNonMatch lets GeoIP rules take over.

Custom exceptions must come before set-based rules. If a China-category domain fails over a direct connection on the current network, add an exact domain proxy rule and place it before geosite:cn. Conversely, if an overseas service should only be accessed directly from the local network, put its precise direct rule before the proxy fallback.

{
  "type": "field",
  "domain": [
    "full:api.example.com",
    "domain:static.example.net"
  ],
  "outboundTag": "proxy"
}

When to Use Three Split-Routing Approaches

There is no universally optimal routing plan outside its environment. Everyday desktop use typically benefits from category data plus a fallback; precise rules suit strict control of individual business domains; temporary global proxying helps diagnose whether the issue is in the routing layer. Restore an understandable rule set afterward instead of using global mode to hide misrouting long term.

When v2rayNG uses the Xray core, the basic logic for domain, GeoSite, GeoIP, and rule order is the same, but Android is also affected by per-app proxying, LAN bypass settings, and system network changes. With the v2fly core, v2flyNG should follow the configuration fields actually supported by that core. Do not copy a complete desktop-generated configuration into the mobile interface field by field.

• The same subscription only supplies nodes; it does not mean different clients will generate identical routing configurations.
• VMess and VLESS describe how a node connects; they do not determine whether a destination domain uses a direct connection or a proxy.
• Routing generally remains active after switching nodes, but recheck references if outbound tags have been customized.
• After per-app proxying is enabled, unselected apps may never enter the core and therefore leave no corresponding routing logs.

Troubleshooting Rule Conflicts and Misrouting

Start by asking whether the request entered the core, then identify which rule matched, and finally verify that the corresponding outbound can connect. Repeatedly switching nodes only tests part of the proxy outbound; it cannot reveal a wrong system proxy port, incorrect rule order, outdated Geo data, or inconsistent DNS resolution.

Open the log window from the v2rayN main interface and temporarily raise the log level enough to observe routing results, then visit only one target domain. Opening several pages at once creates many background requests, mixing ad, image, and API domains and making it difficult to identify the connection being tested.

If the target connection is completely absent from the logs, first check whether the program follows the system proxy and whether it reused a long-lived connection created before the change. Close all browser windows and reopen them; for command-line tools, explicitly specify v2rayN's HTTP or SOCKS port. If the connection enters the core but times out directly, check the matched outbound tag and node status.

1. Use a fixed test target: Choose one complete domain instead of relying solely on changing third-party resources on a homepage.
2. Clear the DNS cache: When rules depend on IP matching, stale resolution records may send before-and-after tests to different ranges.
3. Check the first match: Starting at the top, find the first condition that can cover the target; do not check only the rule you expect to match.
4. Test the outbound separately: Temporarily send the target's full domain to a specified outbound and confirm that the proxy or direct connection itself works.
5. Restore rules incrementally: Start with the smallest rule set and add category entries one at a time, changing only one condition per test.

A Routing Baseline You Can Maintain

A stable rule set does not need a long stack of duplicate domains. Keep five layers—ad blocking, private-address direct access, direct China domains, direct China IPs, and the final proxy—then add a few exact exceptions only for sites with verified issues. This is usually easier to maintain than importing overlapping lists from unknown sources.

GeoSite and GeoIP data should be updated regularly, but after an update, check whether important business domains have changed categories. Category data enables bulk decisions; it is not an absolute conclusion for the current network environment. For consistently misclassified destinations, create a local exception with a full: rule and record the reason and date in a comment or rule name.

• Name rules by purpose, such as “Ad blocking,” “Direct LAN,” “Direct China domains,” and “Final proxy.”
• Put exact exceptions before set-based rules, and keep only one broad network fallback at the end.
• After every change, test four target types separately: LAN, China domains, overseas domains, and direct IP addresses.
• After updating v2rayN, v2rayNG, or v2flyNG, verify that the active core, routing profile, and local ports have retained their previous values.
• If a subscription update changes a node protocol from VMess to VLESS, verify node connectivity before judging the routing result.

The final standard is not whether a page “seems to open,” but whether the target, matched rule, and outbound tag in the logs correspond. With a clear rule order, narrowly scoped exceptions, and a fixed fallback position, direct China traffic and overseas proxy behavior can be reproduced and verified, while deviations after client upgrades or subscription changes can be located quickly.