v2rayN Routing Rules in Practice: geosite/geoip Setup and Bypassing China Routing

1. Understand traffic entry, routing rules, and outbounds

System proxy, TUN, and routing rules are separate controls. The system proxy tells apps that honor the setting to send requests to the local proxy. TUN captures traffic covered by the system routing table. The core's routing rules then decide which outbound handles each request. If a request never reaches the core, changing the geosite list won't help.

In this guide, proxy is the proxy outbound tag, direct is the direct outbound tag, and block is the block outbound tag. These are just names in the configuration, not protocols that exist automatically. The generated configuration must contain matching outbounds[].tag values; otherwise, it may fail to load or report an outbound lookup error.

2. Where to use geosite and geoip

Use geosite:cn in a rule's domain array to match the cn category in the domain database. Use geoip:cn in the ip array to match cn IP ranges in the IP database. Neither performs an online lookup, and neither guarantees that every mainland China service will be routed correctly.

In Xray domain rules, a bare example.com is treated as a keyword match; it does not mean “this domain and its subdomains.” For a service-specific exception, use domain: or full: explicitly to avoid matching unrelated domains that happen to contain the same string.

3. Rules are evaluated top to bottom; put specific exceptions first

Xray checks routing rules in order, and the first matching rule determines the outbound. It doesn't rank rules by specificity and choose the best match. A broad rule near the top can prevent more specific rules below it from ever running.

1. Service exceptions: Put exact domains that must always use the proxy or connect directly before general category rules.
2. Optional blocking: Route ad-domain categories to block only after confirming they won't disrupt your services. If something gets blocked by mistake, remove this rule first and test again.
3. Direct LAN traffic: Match private domains and IP addresses to avoid sending requests to routers, printers, and other local services through a remote server.
4. Direct mainland China traffic: Match domains with geosite first, then use geoip for IP destinations.
5. All other traffic: Send it to the verified default proxy outbound, or choose an appropriate fallback strategy.

Different fields in a single rule generally have to match together. For example, setting both domain and ip does not mean “the domain is in mainland China or the IP is in mainland China.” To route on either condition, create two rules: one for domains and one for IPs, both pointing to the same direct outbound.

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

This exact-domain exception demonstrates the syntax; it doesn't mean the example domain needs a proxy. Replace it with the service domain you need to handle, and put the rule before any general rule that might match it. If the service also uses separate login, static asset, or API domains, check each one against the logs instead of handling only the hostname in the browser's address bar.

4. Xray routing snippet to bypass China routing

This shows only the routing object, not a complete client configuration that can run on its own. It assumes that proxy, direct, and block outbounds already exist, and that proxy is the first outbound. No catch-all rule is included, so IPIfNonMatch can still perform its fallback lookup.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

IPIfNonMatch means that if the first pass finds no rule for a domain destination, Xray resolves the domain and tries matching again with the resulting IP. Connections made directly to an IP can already match IP rules. If a domain matches a geosite rule, Xray won't perform another lookup just to check later geoip rules.

This setup doesn't guarantee that every mainland China domain will always connect directly. Domain categories may be incomplete, and CDN routing can affect resolved IPs. For services where reliability matters, add explicit domain rules first and use geoip as a fallback. Ad blocking is optional; you can leave out the first rule initially, verify that basic routing works, and enable it later.

5. Save, enable, and verify the rules in v2rayN

First, confirm that the current node uses Xray. The routing field in this guide isn't a drop-in configuration format for other cores. Menu and window names can vary slightly between v2rayN desktop versions. In the Chinese interface, go to “Settings” → “Routing Settings.” In the rules window, distinguish the list of routing profiles from the rules within a profile.

1. Keep a fallback: In “Settings” → “Routing Settings,” note which profile is currently enabled. If you can duplicate it, make a copy before editing. Don't overwrite your only working ruleset.
2. Create or edit a profile: Add domain and IP rules in the order shown above, and select direct, proxy, or block for each outbound. Follow the format indicated by the specific input field in the GUI. Don't paste the entire routing object into a “Domain” field.
3. Set the domain strategy: Select IPIfNonMatch as the domain resolution strategy for the routing profile. Save, return to the main window, and switch to the profile you edited. Saving a profile without enabling it won't change runtime behavior.
4. Check the inbound: Go to “Settings” → “Parameter Settings” and check the local listening port. The examples below use 10808; use the value shown in your client. To test the system proxy, select “Set system proxy” from the system proxy menu on the main window.
5. Check the runtime results: Apply the settings and restart the core. Check the logs for resource loading, rule parsing, or outbound tag errors. Use the client's configuration viewer or runtime configuration file to verify the generated routing and outbounds.

Don't rely on editing a temporary configuration generated by the client; it may be recreated when you switch nodes, update a subscription, or restart. Save rules in Routing Settings. If you use a custom configuration, manage the inbound, DNS, outbounds, and routing together in that configuration.

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com
curl --proxy socks5://127.0.0.1:10808 --head https://example.com

These commands help compare “send the domain to the proxy for resolution” with “resolve it locally first”; they're not a speed test. socks5h sends the destination domain to the proxy server, while socks5 usually resolves it locally and sends the resulting IP to the proxy. Make sure the port accepts SOCKS connections and that curl is available in your terminal. Don't use -k to skip certificate checks and mask connection problems.

The details shown in logs depend on the core and log level; they may not identify the exact rule number. Use the destination and outbound tag in connection records to diagnose the route. If needed, raise the log level briefly, reproduce the issue once, and then restore it. Record only the destination type and outbound in test results; don't share subscription URLs, node credentials, or complete private browsing histories.

6. DNS, traffic sniffing, and TUN routing limits

domainStrategy controls whether the destination domain is resolved for routing decisions; it doesn't configure DNS by itself. Client DNS settings, system DNS, browser secure DNS, and whether an app sends a raw IP all affect the destination information the core actually receives. Adding geosite alone doesn't mean every connection will include a matchable domain.

• Requests with only an IP: geosite can't match a bare IP. Use geoip, or configure traffic sniffing if needed so the core can try to identify a domain from protocol data.
• Traffic sniffing: Domain recovery isn't supported for every protocol. If you want detected domains to affect routing without changing the connection destination, consider Xray's routeOnly setting and verify the configuration generated by the client.
• DNS timeouts: The fallback check with IPIfNonMatch may wait for DNS resolution. If the first page load is slow, check DNS lookup time separately from the node handshake.
• TUN capture: TUN captures a wider range of traffic, but it won't fix rule order or fill in categories missing from the geosite database.
• LAN exceptions: The system proxy bypass list, TUN route exclusions, and core direct rules are separate layers. A request may be bypassed before it reaches the core, so its absence from the logs can be expected.

Change one routing component at a time: first verify routing with an explicit proxy command, then test the system proxy, and finally test TUN if needed. This makes it easier to identify what fixed the problem instead of changing DNS, rules, and traffic capture all at once. For more setup steps, see the TUN setup guide.

7. Four common routing problems

A stable routing setup isn't about the number of rules; you should be able to explain which outbound handled each test request. Keep a working profile, record each change and its test target, and if something breaks, roll back the last change before checking the inbound, destination information, rule order, and outbound. For basic setup, see the routing setup guide. For connection errors, use troubleshooting to investigate step by step.