Practical Routing Rule Splitting: Precisely Separate Direct and Proxied Traffic with geosite and geoip

Break routing decisions into three separate layers

In v2rayN, routing rules are ultimately executed by the Xray core. As each connection enters the core, the routing module reads attributes such as the destination domain, destination IP, port, network type, and inbound tag, then checks the rules from top to bottom. The first matching rule determines which outbound handles the connection. Common outbounds include proxy, direct, and block; this article focuses on precisely separating proxy and direct traffic.

For everyday network use in mainland China, an easy-to-maintain rule set can be divided into three logical layers. The first handles local networks and private IP addresses, preventing connections to routers, storage devices, or local services from being sent through the proxy chain. The second handles destinations clearly associated with mainland China, sending them directly. The third does not enumerate domain categories; it sends all remaining traffic to the proxy outbound.

1. Private address layer: Match geoip:private and use the direct outbound.
2. Mainland China destination layer: Match geosite:cn and geoip:cn separately, using the direct outbound.
3. Default handling layer: Match all remaining TCP and UDP connections and use the proxy outbound.

Here, “layer” describes the policy structure; it does not mean that each layer can contain only one rule object. Domain and IP conditions are best split into separate rules because different fields in the same rule generally use an AND relationship, while multiple values within one field use an OR relationship. Placing domain and ip together without distinction can make the effective matching scope narrower than expected.

What geosite and geoip are each designed to match

geosite matches domain categories

geosite data organizes domains by characteristics and categories. geosite:cn matches domains classified as belonging to mainland China. When an application provides the original domain name, a domain rule can be evaluated before the destination connection is established, without first relying on the destination IP range.

Domain categories work well for sites that use content delivery networks, dynamic addresses, or multi-address routing. A site's resolved addresses may vary by carrier, region, and time, while its domain classification is usually more stable. Sending these domains directly can reduce rule drift caused by changing addresses.

Keep in mind that geosite:cn refers to a domain classification in the data file; it does not mean that the current resolution result is necessarily located in mainland China. A site may use nodes across multiple regions, and a company may change its hosting location. geosite is therefore best for expressing domain policy, not for replacing real-time network measurements.

geoip matches destination addresses

geoip data categorizes IP ranges by purpose or region. geoip:private covers non-public destinations such as local networks and is commonly used for direct access to local subnets, home router management addresses, LAN printers, and internal storage devices. It should come before ordinary regional rules because private addresses are not suitable destinations to send through a remote proxy.

geoip:cn matches destinations in mainland China IP ranges. When an application connects directly to an IP, or when a domain misses existing geosite rules and is resolved afterward, the IP rule provides a second layer of matching. It does not replace geosite:cn; the two cover separate paths: identifying destinations by domain and identifying them by address.

domainStrategy determines when a domain is resolved to an IP

Writing only geosite and geoip rules is not enough. Whether a domain request proceeds to IP matching depends on domainStrategy in the routing configuration. This setting controls resolution behavior during routing; it is not simply a “DNS switch.” Understanding it explains many cases where domain rules work but IP rules never take over.

AsIs: Preserve the original destination form

AsIs tells the routing stage to prioritize the original destination carried by the connection. When the destination is a domain, routing mainly uses domain-based rules; the routing module does not resolve the domain solely to try geoip rules. When the destination is already an IP, geoip rules can still match normally.

This mode performs fewer resolutions and keeps the path straightforward, but it does not cover cases where a domain is missing from geosite and should then be checked by its resolved address. For example, if a mainland China domain does not match geosite:cn, it may fall directly into the final proxy rule even when it resolves to a geoip:cn range.

IPIfNonMatch: Resolve only after domain rules miss

IPIfNonMatch is well suited to the three-stage split described here. The core first tries the rules using domain information; if no domain rule matches, it resolves the destination domain and uses the resulting IP to try address-based rules. This lets geosite:cn provide category-based matching first, while geoip:private and geoip:cn provide fallback checks.

This strategy balances accuracy with additional resolution. It does not require IP matching immediately for every domain connection, but it still provides a second matching path when domain classification is insufficient. For the common desktop policy of “mainland China domains direct, mainland China addresses direct, everything else proxied,” it is usually more predictable than AsIs.

IPOnDemand: Resolve early when IP conditions apply

IPOnDemand resolves domains more proactively when routing needs IP information. If the configuration contains IP rules that can participate in matching, resolution may happen earlier. This suits configurations that genuinely require fine-grained control by destination address, but it also means that the DNS path, cache state, and resolution results have a more direct effect on routing.

If the goal is simply direct access for common mainland China destinations and proxy access for everything else, there is no need to choose a more aggressive resolution strategy just to “cover every case.” Start with IPIfNonMatch, then adjust it based on specific unmatched destinations in the logs; troubleshooting is usually easier this way.

A ready-to-use three-stage routing template

The snippet below shows only the routing section. It assumes the complete configuration already contains a direct outbound tagged direct and a proxy outbound tagged proxy. If the current configuration uses different tags, replace outboundTag in the template with the actual values. Tags must match exactly, including capitalization.

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

From a policy perspective, this is still a three-layer design. The first rule covers private addresses; the second and third together form the mainland China destination layer, split to avoid requiring different fields to match simultaneously; the fourth is the proxy fallback layer.

When the destination is a LAN IP, the first rule matches immediately. When it is a domain in the geosite:cn category, the second rule matches. The third rule handles a mainland China IP entered directly, or an address resolved in mainland China during the IPIfNonMatch stage after no domain category matched. All other ordinary TCP and UDP traffic reaches the final proxy outbound.

If the complete configuration also contains rules to block specific domains, force a particular service through the proxy, or send a process through a specific outbound, place those more specific rules before the fallback. Whether they belong before the mainland China direct rules depends on priority. For example, if a domain classified under geosite:cn must use the proxy, its dedicated proxy rule must come before geosite:cn.

Verify these four areas when applying the setup in v2rayN

1. Confirm the outbound tags used by the rules

The direct and proxy tags in the template are common examples. The active configuration may be generated by v2rayN based on the selected server, routing mode, and core settings. Before editing a custom configuration or advanced routing, inspect the current outbound tags and make sure the referenced targets actually exist. Referring to a nonexistent tag prevents forwarding from working as intended; the core log will usually report the relevant error.

2. Confirm that the current core can read geosite and geoip data

geosite:cn and geoip:cn depend on data files. The core executes the rules, while the category contents come from the accompanying data. If the log says that a category cannot be loaded, a file is missing, or an entry is unknown, first fix the compatibility and availability of the core and data files instead of repeatedly changing rule order.

After updating the data, restart the relevant core process so the new process reads the resources again. Closing the settings window does not necessarily reload the running core. Before testing, stop and restart the connection in v2rayN, then inspect the newly generated logs.

3. Confirm that system traffic actually enters v2rayN

Routing rules can process only connections that have entered the core. With the system proxy, applications must honor the system proxy settings. With TUN mode, check that TUN is running, routes have been created, and DNS is being intercepted as expected. If an application bypasses the current entry point entirely, changing geosite or geoip rules will not change its network path.

When troubleshooting, do not infer the routing result from how quickly a webpage loads. A more reliable approach is to check whether a connection log appears for the destination, which outbound tag matched, and whether the destination appears as a domain or an IP. If there is no corresponding record, check the traffic entry point first instead of adding more routing conditions.

4. Confirm that subscription updates will not overwrite custom routing

A subscription provides server nodes and related connection parameters; routing rules are local client policy. After a subscription update, the node list may change, but whether custom routing remains depends on where the rules are stored and how the current configuration is managed. Keep long-term rules in v2rayN's routing settings or in a clearly managed custom configuration, rather than editing a temporary runtime file generated for a single run.

Typical symptoms of incorrect rule order

The proxy fallback rule comes first

If a proxy rule for network: tcp,udp appears at the top of the list, most ordinary connections will match it immediately, leaving geoip:private, geosite:cn, and geoip:cn with no chance to run. The usual result is that both mainland China sites and LAN destinations go through the proxy. The fix is not to add more exclusions; move the broad fallback to the end.

A specific exception appears after geosite:cn

Suppose a business domain in a mainland China category must use the proxy for testing, but its dedicated rule appears after geosite:cn. The connection will be handled by the mainland China direct rule first. Move the specific domain rule before the category rule. The earlier a rule appears in the list, the better suited it is for narrow, clearly defined exceptions.

geosite:cn is present, but geoip:cn is missing

This configuration handles many domain-based connections, but it does not cover direct connections to mainland China IPs or use resolution results to supplement domains missing from the data. If logs often show destinations directly as IPs, adding a separate geoip:cn rule is more effective than continually expanding the domain list.

geoip:cn is present, but geosite:cn is missing

Relying only on address matching puts more work on resolution and makes routing more sensitive to CDN nodes and address selection. A mainland China business domain may resolve to an address outside the expected category and consequently enter the proxy. When the domain policy is clear, use geosite:cn to express the intent first, then use geoip:cn as a supplement.

Treating multiple conditions as if any one match were enough

If a rule includes domain, ip, port, and network, the connection generally needs to satisfy all of those fields. When a rule does not match, check each field rather than verifying only that one domain appears in the list. To make maintenance easier, split different matching dimensions into multiple rules with a single purpose.

Use logs for verification, not intuition

After completing a routing setup, test at least four types of destinations: a LAN address, a domain in the mainland China category, a mainland China IP accessed directly, and an ordinary external domain expected to use the proxy. Test one destination at a time and record its form, resolution result, and final outbound tag.

1. Access a router or LAN service and confirm that the connection uses direct.
2. Access a stable mainland China domain and confirm that the direct path for geosite:cn is working.
3. Connect to a clearly identified mainland China IP and confirm that geoip:cn matches independently.
4. Access a destination outside the categories above and confirm that it falls back to proxy.

If the core log level is too low to show enough routing details, increase the logging verbosity during troubleshooting and restore the usual setting afterward. Focus on the destination address, domain resolution, rule errors, and outbound tag. During testing, avoid interference from browser cache, existing persistent connections, or background requests; close the target page and establish a new connection so the result is easier to identify.

When extending the basic template, keep specific rules before broad ones

The three-stage template is a useful starting point, not a reason to stack unverified categories indefinitely. When extending it, state the business intent first, then choose whether to match by domain, IP, port, or inbound tag. If a fixed domain must use the proxy, add a specific proxy rule for that domain; if an internal subnet must be direct, add a direct rule for its IP range; if a class of UDP traffic needs a special outbound, add separate network and port conditions.

For every added rule, answer three questions: what destination does it cover, which rule must it precede, and where should traffic go if it does not match? If you cannot answer, the rule's scope or priority is still unclear. Compared with a large rule set, a short set with clear ordering, single-purpose fields, and log-based verification is easier to maintain over time.

For this use case, the guiding principle can be reduced to one sentence: protect private networks first, identify clear mainland China domains and addresses next, and send everything else to the proxy. geosite:cn handles domain-level policy, geoip:private and geoip:cn supplement address-level matching, and IPIfNonMatch connects the two decision paths. As long as outbound tags are accurate, data files are readable, and traffic actually enters the core, this structure provides an explainable, troubleshootable separation between direct and proxied traffic.