v2rayN Routing Rules: geosite and geoip Setup Guide

1. Before you start: traffic must reach the core for rules to match

v2rayN manages configuration; the Xray core handles connections that reach its proxy inbound. When a browser uses the system proxy, its requests are sent to the local proxy port. Applications that bypass the system proxy and connect directly are generally unaffected by Xray routing changes. Desktop TUN mode is a separate way to capture traffic; check the current platform and client features for availability and permission requirements.

This guide uses Xray JSON fields. v2rayN can manage different cores, but rule formats are not interchangeable between cores. On Android, v2rayNG uses Xray, while v2flyNG uses V2Fly. Even when the concepts are similar, don't assume the desktop menus, generated configuration, or data file versions apply.

1. Confirm the active core

   Open Settings → Parameter Settings and check the core selected for the current protocol; some versions label this option “Core Type.” Then check the startup log for the core name to confirm that Xray is actually running. Don't infer the core from the node protocol alone.

2. Back up your routing profile

   Go to Settings → Routing Settings and note the selected profile and rule order. Back up the current profile before editing. If your version offers an export option, export it first to avoid overwriting custom rules that are still in use.

3. Check the proxy entry point

   In Settings → Parameter Settings, check the local listening port, then confirm the browser or system proxy uses the same address and port. Don't enter the remote node port as the local proxy port.

4. Apply changes and check the logs

   After saving, select the target profile in the routing option on the main screen, then apply it or restart the core as prompted by your version. Menu locations can change between releases; use the generated configuration and startup log to confirm the result.

2. What geosite, geoip, and outboundTag do

geosite is a collection of domains, while geoip is a collection of IP ranges. Neither is an online lookup service; both are data read by the core. geosite:cn refers to the cn domain collection in the current data file, not every domain ending in a particular suffix. geoip:cn matches mainland China IP ranges in the current data.

outboundTag points to an existing outbound; it doesn't create one. In this guide, direct refers to the direct outbound, and proxy to the configured proxy outbound. These are not reserved Xray names. If the generated configuration uses different tags, update the rules to match. A rule that specifies proxy won't provide a working proxy route unless an outbound with that tag exists.

• Within a rule's domain array, multiple domain conditions are an “any match” test.
• Within a rule's ip array, multiple IP conditions are also an “any match” test.
• When a rule sets multiple fields such as domain, ip, and port, all specified conditions must match; they are not alternatives.
• Rules are checked in order. Once a rule matches, later rules won't select a different outbound for that connection.

3. Basic setup: direct LAN and mainland China traffic, proxy everything else

A common order is “LAN exceptions → custom exceptions → mainland China domains → mainland China IPs → proxy fallback.” The basic example below has no custom exceptions. It's a partial object containing routing; it omits inbounds, outbounds, and node authentication parameters, so it can't run as a complete client configuration on its own.

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

The first rule sends known private destination addresses direct, useful for routers, LAN file servers, and other internal devices. The second prioritizes domain data. The third handles connections made directly to an IP, as well as domain connections that need to be evaluated by their resolved address. The final rule explicitly captures the remaining TCP and UDP traffic, rather than relying on the default behavior of the first outbound in the complete configuration.

For everyday routing that primarily uses domains, use geosite:cn as the main criterion and geoip:cn to cover IP destinations. If your internal services use custom company domains, add their specific suffixes to a direct rule. Don't assume a private IP rule will always trigger resolution for every internal domain.

4. Domain resolution strategy: choosing between AsIs and IPOnDemand

routing.domainStrategy determines when routing needs an IP address. It is not the DNS server list in the DNS module, nor is it the similarly named setting on a direct outbound. Getting the expected address also depends on DNS configuration, network conditions, and whether the request retains its domain. Changing this one strategy field won't fix DNS pollution, DNS routing, and traffic capture for every application at once.

If you switch to IPOnDemand and want specific domains to always use the proxy, place those domain rules before broad IP rules. Otherwise, a domain may resolve to an address that matches a direct rule and be routed direct first. Check rule priority and DNS results together.

5. Custom rules: domain exceptions, port conditions, and local collections

Start with a small number of specific domains. The two rules below mean “proxy this host” and “send this example domain and its subdomains direct.” These example domains are for syntax only; replace them with the domains you actually want to manage. Don't include https://, paths, or query parameters from a URL in a domain condition.

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

Place both rules before any broader rule that could match them, with the more specific api.example.com first. If the order is reversed, the subdomain matches the rule for the entire domain and the later exact proxy rule never takes effect. For internal addresses, decide whether network security boundaries or domain exceptions take priority; don't apply one ordering blindly.

A port condition refers to the destination port. For example, combining "port": "443" with a domain condition means “that domain and destination port 443,” not every connection to that domain. A proxy rule for port 53 alone won't cover all DNS traffic over other transports, and it doesn't replace DNS module configuration.

Two ways to maintain custom collections

• A few domains: Maintain them directly in the domain array, using full: or domain: to specify the intended scope. This avoids extra collection files and makes changes easy to review.
• Many domains: Prepare a collection file in the format required by the core. For example, ext:custom.dat:office reads the office collection from a custom data file. This is not just a regular text filename with a tag, nor an arbitrary remote rules URL.
• Updating data: Check the resource directory used by the active core, file access permissions, and the exact collection name. Rewriting a rule name won't create a tag that's missing from the current geosite data.

6. Global proxy: keep LAN access or send everything through the node

Define what “global proxy” means for your setup. A v2rayN routing profile controls traffic that has already reached the core; it doesn't automatically capture every system process. Applications outside the system proxy may still connect directly, and UDP availability depends on the inbound method, node protocol, and server capabilities.

If you're temporarily troubleshooting a site, you don't need to remove every routing rule right away. Add an exact-domain proxy rule before any rule that would match it, then check the site's main domain and API domains. A page may also request login, static asset, and download domains, so changing only the hostname in the address bar may not cover the full request chain.

Changing the node protocol won't replace routing troubleshooting. VMess and VLESS describe proxy connection methods; outboundTag determines which configured outbound receives the current connection. If the proxy node itself works, check rule conditions and order first rather than repeatedly changing protocol fields.

7. Verification: check traffic capture, rule matches, and egress in order

An egress IP only shows the route taken by one test request; it doesn't prove that every application uses the same rules. Keep the test target consistent and start a new connection after each configuration change. Existing browser connections may continue using their previous outbound, so close the relevant pages, end old connections, or restart the test application if needed.

1. Check that traffic is being captured

   Open a target page and check the client log for the corresponding connection. If there's no entry, check the system proxy, local listening port, and the application's own proxy settings before changing geosite rules.

2. Check LAN access

   Test the actual IP of your router or file server, such as 192.168.1.1 if that address exists on your network. Use your local network settings as the source of truth, then test the corresponding internal domain separately.

3. Check domain exceptions

   Start a new request to the exact domain you added, then check the destination and outbound tag in the log. Log details vary by core configuration. If the log doesn't show the full rule ID, a successful connection line alone doesn't prove which rule matched.

4. Check the fallback route

   Choose a public destination that isn't covered by a custom exception and check whether it uses the proxy outbound. Raise the log level only temporarily for troubleshooting, then restore it. Remove subscription URLs and node credentials before sharing logs.

Common symptoms and what to check

• A domain goes direct as expected, but a connection by IP uses the proxy: Check whether the IP is actually in the target collection and whether the geoip file loaded successfully. Domain classification and server IP location are separate checks.
• A new rule still uses the old route: Check that the profile is selected, the core has applied the configuration, and no broader rule appears earlier. Then close the old connection and test again.
• Startup reports a missing collection: Check the data file, collection name, and resource directory. First verify the routing path with an explicit full: rule, then troubleshoot collection loading.
• The log shows a proxy match, but the page still fails: Check node connectivity, DNS results, and server access restrictions. A successful match confirms only that an outbound was selected; it doesn't prove the connection completed.

A reliable routing setup should make the purpose of every rule clear: which addresses must go direct, which domains explicitly use the proxy, which conditions depend on resolution, and what handles everything else. Establish a baseline with a few verifiable rules before expanding collections; it's easier to maintain than importing many overlapping rules at once.