V2Ray Split Tunneling Rules: Direct Mainland China Traffic, Proxy Overseas Traffic

1. System proxy vs. traffic routing

The system proxy determines whether an application sends connections to v2rayN’s local proxy. Routing determines whether the core sends a connection directly, through a proxy, or blocks it. These are separate layers. Enabling the system proxy does not guarantee that every application will use it: terminals, applications with their own network stacks, and browsers with proxy exclusions may bypass it.

This guide uses a browser routed through the system proxy as its test setup and leaves TUN unchanged. VMess and VLESS are proxy connection protocols; they do not determine whether a mainland China domain connects directly. A subscription provides node details, but does not replace the local routing profile currently selected.

10808 is an example port used in the commands below, not a guaranteed default for every installation. Check the local listening port and proxy type under Settings → Parameter settings. Use the HTTP proxy test commands below only if that port actually accepts HTTP proxy requests.

2. Create a separate routing profile in v2rayN

Back up your current routing profile before creating a separate one for testing. v2rayN’s interface varies by version and desktop UI type, so the menu names below reflect common Chinese labels. Don’t paste routing JSON into the subscription URL field or overwrite a temporary file generated by the running client.

1. Open Settings → Routing settings, note the currently enabled profile, and use the built-in export option to save a copy. If your version has no export option, copy the existing rules somewhere safe first.
2. Create or duplicate a profile in Routing settings and name it “Direct Mainland China Traffic Test.” Add, edit, and reorder rules in the rule list; leave the original profile unchanged.
3. Check that geoip.dat and geosite.dat are available. If the log reports a load failure or a missing tag, fix the rule files before testing routing.
4. After saving, select the new profile in the main window and confirm that the core restarts or reloads its configuration successfully. Editing a profile without selecting it won’t change the active connection.
5. If something goes wrong, switch back to the original profile and create a fresh test connection. Don’t change the node, DNS, and traffic capture method all in the same troubleshooting pass.

3. How domain, ip, and outboundTag matching works

Rules are checked in list order, and the first match determines the outbound. Multiple candidates within the same field are usually treated as OR conditions; different fields in one rule are AND conditions. For example, when both domain and port are specified, both the domain and port must match. Don’t put a domain and an IP in the same rule expecting either one to match.

In this type of rule, a plain domain string without a prefix may match as a substring, potentially matching more than intended. To target a site precisely, use full: or domain:. Also, geosite:cn and geoip:cn are separate data categories, not interchangeable conditions.

4. Rule examples: direct, proxy, and block

The order is: block a specified domain, connect directly to private addresses, proxy a specified domain, connect directly to mainland China domains, connect directly to mainland China IPs, then proxy all remaining TCP/UDP traffic. ads.example.com and remote.example.com are syntax examples only; they do not represent a real ad list or a working test service.

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

This is a routing snippet; it does not include inbounds, DNS, or outbound definitions. The complete configuration must already define outbounds with the tags direct, proxy, and block. In V2Ray/Xray, direct connections usually use a freedom outbound, while blocking usually uses a blackhole outbound. The proxy tag must point to the selected node’s actual outbound. Don’t create an incomplete node object just to fill in the example.

• Put specific rules first: Domain-specific exceptions must come before broad category rules. Otherwise, a request may match the mainland China domain set first, and the later proxy exception will never run.
• Put the catch-all last: network: tcp,udp covers a broad range of traffic. At the top of the list, it can shadow later rules for the same traffic.
• Unmatched traffic does not automatically connect directly: V2Ray/Xray typically sends unmatched traffic through the first outbound. An explicit fallback avoids relying on the implicit outbound order.
• Start with a narrow block rule: Test one specific domain before considering a category list. Blocking login, verification, or static asset domains can leave a page blank.

5. How domainStrategy and DNS affect routing

For domain rules to work, the core needs the target domain. If an application supplies only an IP address, geosite cannot infer the site name. Sniffing may recover domain information for some connections, but not all protocols or connections expose a recognizable domain. Don’t treat it as guaranteed.

The previous section keeps an explicit proxy fallback. With IPIfNonMatch, a domain that has not been resolved and does not match the mainland China domain set may go straight to the final proxy rule, without a later geoip:cn check. The mainland China IP rule in this example mainly covers targets given to the core as IP addresses. If your setup needs IP-based location checks for unclassified domains, redesign the fallback and resolution strategy; changing one toggle is not enough.

6. Verify routing with fresh connections and logs

A page loading only proves that one connection path works; it does not prove that traffic used the intended outbound. Reused connections may also keep using the old route after a change. After saving and applying a profile, close old test connections and send a fresh request. If needed, temporarily set the log level to info, then restore its previous value.

1. Confirm in the v2rayN log panel that the core started successfully. First rule out missing rule files, invalid JSON, and outbound tags that do not exist.
2. Make sure the browser is using the local proxy, and temporarily disable extensions that override system proxy settings. Don’t use a cached browser page or another traffic capture method to judge the rules.
3. Test a mainland China domain, an unclassified domain, and an accessible LAN address separately. Record each target, test time, and expected outbound, then look up the routing result in the logs for the same time.
4. If the standard logs in your version don’t show rule details, enable more detailed logging briefly. Avoid keeping logs that contain full request destinations for long; remove sensitive information before sharing them.

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

In Windows PowerShell, if curl maps to a different command, use curl.exe. These commands only send fresh requests through the specified proxy. An HTTP status code, timeout, or response header alone cannot confirm which outbound was selected. Some services don’t accept HEAD requests, so that alone does not indicate a routing problem.

• No request appears in the logs: Check the proxy port, proxy type, and application proxy settings before changing the routing rules.
• Connection logged, wrong outbound: Check the active profile, rule order, whether the target is a domain or IP, and whether a broad rule matched first.
• Correct outbound, connection fails: Check the node, target service, DNS results, and UDP support. Don’t add direct-connection rules to mask the underlying issue.

7. Common questions about custom routing

Reliable routing doesn’t come from piling on rules. Keep exceptions explicit and limited, and let the mainland China categories and final fallback do their respective jobs. Change one thing at a time and record reproducible test targets. When mainland China traffic won’t connect directly or a specified service won’t use the proxy, trace the issue through four layers: the entry point, target type, rule order, and outbound.