v2rayNG Split Tunneling Guide: Direct Local Traffic, Proxy International Sites

First, check which traffic reaches the router

v2rayNG uses the Xray core to handle proxy connections. The selected node determines which server the proxy connects to; routing rules determine whether a request uses that proxy. Node protocols such as VMess and VLESS do not automatically mean “direct in China, proxy elsewhere.” A successful subscription update also does not mean your routing policy is configured as intended.

This guide assumes Android VPN mode. App traffic first enters v2rayNG, then the core routes it directly, through the proxy, or blocks it. With per-app proxy enabled, excluded apps may bypass this processing chain. App network settings and other VPN services can also affect test results.

Choose a preset and keep a working baseline

Open the main screen’s sidebar and go to the routing options under Settings. Find “Predefined rules.” In some versions, “Routing settings” has its own sidebar entry, or the option is called “Routing mode.” Menu groups may vary; look for “Predefined rules” and the options below. The node selection menu is not the routing menu.

1. Record your current settings

   Save screenshots or copies of the current “Predefined rules,” “Domain strategy,” and custom rules. Note whether per-app proxy is enabled. Keep a rollback point, and don’t change the node, DNS, and routing settings at the same time.

2. Choose a preset

   Go to Settings → routing options → “Predefined rules,” then select “Bypass LAN and mainland China.” If “Routing settings” appears in the sidebar, look for the same option there.

3. Check the domain strategy

   Find “Domain strategy” and note its current value. For a first-time setup, keep the default. Consider IPIfNonMatch only if you specifically need IP rules to provide additional matches.

4. Restart and test

   Save your changes, stop the connection, then start it again to load the new configuration. Test a LAN admin page, a site in mainland China, and an international site in turn. Note whether each is reachable before adding exceptions.

Direct LAN access: IP ranges beat hostnames

Routers, printers, and NAS devices commonly use private IP addresses. If requests to these devices go through a remote proxy server, that server usually can’t reach your home network. Private-address rules in a preset help avoid this, but check that they cover your actual IP range instead of adding just one address such as 192.168.1.1.

Configurations with compatible data files can use geoip:private to match private and other local-use address ranges. The actual coverage depends on the data in use. Check IPv6 LAN traffic separately, including Unique Local Addresses such as fc00::/7. Three IPv4 ranges won’t cover all local traffic.

• Test by IP first: If this is your actual gateway address, open http://192.168.1.1. Don’t assume this example address is the default for every router.
• Then test by device name: If the IP works but the device name doesn’t, check LAN DNS or local name discovery first. Direct routing won’t fix name resolution automatically.
• Separate discovery from connectivity: Casting and printer discovery may rely on mechanisms such as multicast. A working webpage alone doesn’t prove device discovery is working.
• Check for network isolation: Guest Wi-Fi and wireless client isolation can also block communication between devices. Changing proxy rules won’t override your router’s isolation settings.

Domain exceptions: put specific rules before broad classifications

Xray checks routing rules in order; the first matching rule determines where a request goes. So if a domain must use the proxy, add its rule before a broad mainland China direct rule. The interface may put proxy, direct, and block rules in separate fields. Their visual position may not reflect the final rule order, so check the exported configuration or logs.

The following is an Xray rule snippet, not a complete node configuration you can import. example.com is a placeholder domain for illustrating the syntax; replace it with the target site. proxy, direct, and block must match outbound tags that actually exist in your configuration.

{
  "rules": [
    {
      "type": "field",
      "ip": ["geoip:private"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "domain": ["full:ads.example.com"],
      "outboundTag": "block"
    },
    {
      "type": "field",
      "domain": ["full:api.example.com"],
      "outboundTag": "proxy"
    },
    {
      "type": "field",
      "domain": ["geosite:cn"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "ip": ["geoip:cn"],
      "outboundTag": "direct"
    }
  ]
}

DNS and classifications: why an apparently international site connects directly

“International site” is not a property the core can identify on its own. A domain may be included in a classification list, or it may resolve to a China-based IP through a CDN. The login page, images, and API for one service may also use different domains. So routing a site’s main domain through the proxy doesn’t mean every request from that site uses the same route.

• AsIs: Routing rules match the destination information already available; the core does not actively resolve domains for IP rules. This does not mean DNS is never queried during the connection.
• IPIfNonMatch: If a domain doesn’t match a rule, the core attempts to resolve it and match the resulting IP. This can add IP-based matches, but it may also route a domain directly if it resolves to a China-based CDN.
• IPOnDemand: The core can resolve a domain when a rule requires IP information. Rule order affects when this happens, so don’t switch strategies without keeping records for comparison.

If a particular service must use the proxy, add a precise domain exception rather than proxying a wider geographic range. If your browser uses its own encrypted DNS, the domain information available to the core may change. Sniffing can reveal domains for some connections, but it depends on the protocol and encryption method, so it is not a guaranteed way to identify every domain.

Ad domains: start with narrow blocking rules

Place ad-blocking rules before allow rules, but start with a specific domain you’ve confirmed is used for ads. Some rule data includes the geosite:category-ads-all category. Before using it, check that the current data file contains that category; if it’s missing, the configuration may fail to load, not just block fewer ads.

• Start by blocking one confirmed ad host with full:. Restart the connection, then check that pages, sign-ins, and playback still work.
• Don’t block an entire domain used by an image CDN, payment API, or verification service; the same domain may serve resources the site needs.
• If something gets blocked by mistake, remove the rule you added most recently. If you need an allowlist exception, put a precise allow rule before the broad block rule it overrides.
• When ads and page content share a domain, domain-based routing can’t distinguish them by URL path. Don’t treat domain blocking as a complete page-filtering solution.

If ads disappear but a page keeps spinning, note the failed domains in the logs and restore them one at a time. Importing a large batch of rules and checking only the homepage makes it hard to find rules that break sign-in, verification, or video playback.

Verify routing: logs, egress, and rollback

After saving the rules, stop and restart v2rayNG, then close existing connections in the test app. Long-lived connections may keep using their original route, and browser caching can make a page appear to work without generating a new request. The following are verification steps, not claims about test results.

Open “Logs” in the main screen’s sidebar to inspect new connections. If the current log level doesn’t show routing details, temporarily raise it to Info, reproduce the issue, and check the destination and actual outbound tag. Restore the original level afterward. If the logs don’t show enough detail, don’t infer which rule matched from “connection successful” alone. Before sharing logs, remove server addresses, subscription links, and personal browsing history.

1. Keep variables constant: Use the same node, Wi-Fi network, and test app. Change only one rule at a time.
2. Check the egress: For an IP lookup site, explicitly route it directly first and record the result, then switch it to the proxy and compare. A single lookup shows only the route taken by that one request.
3. Compare with global proxy: If a site fails in routing mode but works with global proxy, investigate its rules and DNS. If it fails in both modes, check the node and server connectivity.
4. Recheck after updates: Test frequently used sites again after updating geo data or your subscription. Classification changes can affect routing, and updating a subscription typically does not update the rule database.
5. Roll back promptly: If the app won’t start or many sites stop working, restore the original preset and custom rules, then add changes one at a time. Avoid layering multiple unknown changes.

Your final configuration should make three things clear: which apps enter the VPN, which destinations are explicitly routed directly or through the proxy, and which outbound handles unmatched traffic. Start with a stable preset that covers most requests, then correct misclassifications with a few precise exceptions. This is easier to maintain than piling on broad rules.