V2Ray Routing Rules: geosite, geoip, Direct and Proxy Routing

Routing: First Confirm Traffic Reaches the Core

v2rayN is a desktop GUI client, while v2rayNG is an Android client that uses the Xray core. The interface manages servers and settings; the core evaluates routing rules. Protocols such as VMess and VLESS determine how a proxy connection is established, not whether a particular site should connect directly or through a proxy.

The system proxy affects only apps that honor that setting. TUN or Android's VPN-based capture can handle more traffic, but app exclusions, routing settings, and system permissions still apply. If the browser never hands its connection to the client, changing ten geosite rules won't affect its route.

• System proxy: First confirm the browser is using the local proxy address, then check whether the target domain appears in the logs.
• TUN: First check that the virtual network adapter is running and that the target app isn't excluded. Then investigate core routing.
• Android: Confirm v2rayNG is connected, the target app is included in traffic capture, and app routing settings haven't excluded it.

geosite and geoip: One Matches Domains, the Other IPs

geosite.dat contains domain collections organized by tag, while geoip.dat contains IP range collections organized by tag. References such as geosite:cn and geoip:cn point to these collections; they aren't network lookup commands and don't mean the client automatically downloads the latest lists.

For explicit domain rules, full:example.com matches only that exact domain, while domain:example.com matches it and its subdomains. A plain string without a prefix is generally matched as a substring, which can include unrelated domains. Use full: or domain: for precise exceptions.

If rule resources are missing, logs may report that geosite or geoip couldn't be loaded, or that a tag wasn't found. Update resources through the current client's resource update feature, then confirm the running core is reading from the updated location. Don't just copy files into an arbitrary download folder, and don't assume geosite:some-tag is supported by every dataset.

Rule Order: The First Match Wins; Check the Default Route Separately

Standard routing rules are checked from top to bottom in array order. The first match selects the outbound, and later rules don't override it. Within one rule, different condition fields generally all need to match; multiple domain entries in the same domain array are alternatives, so any one match is enough.

1. Specific site exceptions: Put sites that must use a proxy before broad direct-connection rules.
2. LAN and private addresses: Route requests to routers and local services directly. The actual coverage depends on the private address ranges in use.
3. Common domain collections: For example, route geosite:cn directly.
4. IP geolocation rules: For example, route geoip:cn directly, and consider the domain strategy to understand when the rule applies.
5. When no rule matches: In a native configuration, the first outbound is used. A client may also generate additional fallback rules.

Don't put a catch-all rule that proxies all TCP and UDP traffic first. It will match ordinary connections before the direct rules can run. A less obvious issue: with IPIfNonMatch, a broad fallback rule that already matches can also prevent the “resolve the domain after no match” step.

domainStrategy: Controls Domain Resolution During Routing

This section covers routing.domainStrategy. It controls how domains are handled during route matching. It isn't the identically named setting inside a direct outbound, and it can't by itself determine which outbound handles DNS requests.

Suppose a domain doesn't appear in any domain collection, but resolves to an address in geoip:cn. If no earlier rule matches, IPIfNonMatch can resolve the domain and then match the direct rule. AsIs won't proactively perform that conversion for the domain.

DNS results affect IP rules. Resolvers may return different CDN addresses, and IPv4 and IPv6 addresses may have different geolocation results. If a site sometimes connects directly and sometimes through a proxy, check the actual destination address, DNS settings, and matched rule together rather than assuming geosite is broken.

• If an app provides only an IP address, the core may not know the original domain, so domain rules might not match.
• Traffic sniffing may reveal the domain for some connections, depending on the protocol, encryption, and current settings.
• To pin a site to a particular outbound, first confirm the core can see its domain, then add a specific domain exception.

Native Configuration Example: Domains First, IP Rules as a Fallback

The snippet below shows only the routing section. Use it as a reference when inspecting generated configuration or editing a native config. It assumes the configuration already has proxy and direct outbounds, with proxy as the first outbound. example.com and example.org are documentation examples; they don't imply that either domain needs a particular route.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["full:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

This snippet doesn't include server credentials, inbound listeners, DNS, or complete outbound definitions, so it can't replace an entire client configuration. A GUI's “import routing rules” feature may use its own data format; JSON isn't necessarily something you can paste directly into it.

• domain:example.com is a high-priority proxy exception. It routes by domain even if the resolved address belongs to a direct-connection range.
• full:example.org connects only the exact domain directly; it doesn't automatically include subdomains.
• Only if a domain request has no match on the first pass will IPIfNonMatch try resolving it and matching again.
• Without an additional fallback rule, unmatched connections use the first outbound, so check the outbound order.

v2rayN and v2rayNG: Apply Rules in the GUI

Menu names can vary by version, sometimes adding labels such as “Settings” or “Custom.” The steps below describe common entry points and workflows in the Chinese-language interface. If the labels differ, look for the equivalent feature. Don't assume a routing file exported from the desktop client is a universal format for Android.

v2rayN: Copy a Profile, Then Adjust Rule Priority

1. Open “Settings” → “Routing Settings.” Keep your current working profile, then copy it or create a test profile.
2. In the rule editor, choose a domain or IP condition and enter items such as domain:example.com, geosite:cn, or geoip:cn. Select the proxy or direct option available in the interface for the outbound.
3. Move specific domain exceptions above broad collections. If the interface has a domain strategy option, check how it affects routing.
4. Save the profile, then enable it in the routing selector on the main screen. Saving without selecting the profile usually won't change the active connection.
5. Reconnect for testing, then use the logs or generated configuration view to check rule order, the default outbound, and the actual tag.

v2rayNG: Separate Core Routing from App Routing

1. Open the side menu and go to “Settings” → “Routing Settings.” Check the current routing mode, domain strategy, and the sections for proxy, direct, and block rules.
2. Add domain entries in the relevant custom rule field. Support for full geosite references, rule ordering, and JSON editing depends on the current version's interface.
3. If the target app isn't included in VPN traffic capture, adjust the app routing settings first. That's a separate setting from geosite domain routing.
4. After saving, disconnect and reconnect, then start a new connection. Existing long-lived connections may continue using their original outbound.

If you need precise per-rule ordering but the current version only offers text fields grouped by category, check the order of the rules it generates. Separate “proxy domains” and “direct domains” fields don't reveal which one takes priority when rules conflict.

Verify Routing: Check the Outbound in Logs, Not Just Whether a Page Loads

A page loading only confirms that the connection succeeded; it doesn't prove the expected outbound was used. Choose three test targets: a LAN address, an explicit domain exception, and an ordinary domain that matches no collection. Change one thing at a time, start a new connection, and record the target and outbound.

The 10808 above is an example, not a guarantee of the port currently used by your client. Check the actual listening port first. If curl is available on your system, run the request below in a desktop terminal to send the target domain to the core through the SOCKS entry point, reducing differences caused by early name resolution in the app.

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

Unlike test methods that pass only a resolved IP, socks5h passes the domain to the proxy for resolution. The goal isn't to compare speed, but to make the target in the logs match the rule input. If the logs lack detail, you can temporarily increase the log level. Restore it afterward, and remove subscription URLs, server credentials, and personal browsing records before sharing logs.

FAQ: Rules Saved, but Traffic Still Isn't Routed as Expected