At a glance

A website taking the wrong route doesn’t necessarily mean your node is down. This guide is for users who can connect but want to fine-tune direct access to mainland China and local network devices. First, understand the difference between domain and IP databases; then update the files your client actually uses; finally, check rule order with a readable JSON example. The key is to align your rules and data files with the running core—not to keep refreshing your subscription.

What the two dat files match

geosite.dat stores domain groups organized by tags, while geoip.dat stores IP ranges organized by tags. These are data files used for routing lookups—not node subscriptions. They don’t provide server addresses, account details, or transport settings. Updating the databases won’t add nodes or create routing rules for you.

Itemgeosite.datgeoip.dat
MatchesDomain in the requestDestination IP address
Common expressiongeosite:cngeoip:cn、geoip:private
Rule fielddomainip
Common misconceptioncn is a collection tag, not a match for only the .cn suffixAn IP’s registered location doesn’t tell you where a website is based

The contents of geosite:cn depend on the data provider. Whether a domain or its subdomains are included depends on the collection—you can’t tell from the domain suffix alone. Two files named geosite.dat may also come from different sources and contain different tags.

geoip:private is commonly used to send non-public destinations, such as local network devices, directly. Common private IPv4 ranges are listed below as examples; they don’t represent the full contents of this tag.

10.0.0.0/8
Private IPv4 ranges
172.16.0.0/12
Covers 172.16 through 172.31
192.168.0.0/16
Common range for home networks

Bottom line: first check whether the request contains a domain or an IP

When accessing your router at 192.168.1.1, check the IP rules first. If a website takes the wrong route, check the domain rules. Updating the domain database won’t fix an incorrectly written rule for a local IP address.

v2rayN: Update Geo data and verify it’s loaded

On desktop, first check which core and resource format the current configuration uses. The steps below apply to configurations using the Xray or V2Fly core and dat files. If your configuration uses another resource format, updating dat files won’t affect its rules. Menu names can vary by client version, so follow the labels in your current interface. Don’t bulk-replace files with matching names in the installation folder.

  1. Keep your current rules

    In the main window, go to “Settings” → “Routing settings” and note the active routing profile and rule order. If you use a custom configuration, save a copy of the original JSON file so you can compare it later.

  2. Run the resource update

    In versions that include this option, open “Check for updates” → “Update Geo files.” Wait for the update to finish. “Update subscription” is not a substitute for this step.

  3. Check the update log

    Check the download results in the main window log and confirm the status of both geoip and geosite. If only one file updated successfully, resolve the other failure before assuming routing is back to normal.

  4. Restart the current service

    When the update finishes, restart the core service, or quit and reopen the client. Start a new web connection and check the routing log. Existing long-lived connections aren’t a reliable way to verify rule updates.

Update failures generally fall into two categories: a timeout while requesting the resource means the update path needs troubleshooting; an error on startup after the download means you should check the file format and collection tags. If the client offers an option to update resources through a proxy, try it when you already have a working connection. After switching data sources, make sure the tags referenced by your custom rules are still available.

v2rayNG: Update from the resource files screen

On Android, v2rayNG uses the Xray core. In versions with resource management, open the top-left menu, tap “Resource files,” review the listed resources, and use the update option on that screen to download the latest files. Depending on the version, the control may be a text button or an update icon. Check each filename before updating so you don’t update geoip and miss geosite.

  1. Check the active routing setup

    Open “Routing settings” from the top-left menu and note the selected mode and any custom rules. If you use a fully custom JSON configuration, also check whether it references any additional data files.

  2. Open Resource files

    Return to the menu and open “Resource files.” Check the entries for geoip.dat and geosite.dat. If an older version doesn’t have this screen, copying files into the system Downloads folder doesn’t mean they’ve been imported.

  3. Update and check the results

    Run the update from the screen and wait for a result for each resource. If one fails, note the error message. Network timeouts, unavailable resource URLs, and files that can’t be loaded require different fixes.

  4. Reconnect and test

    Stop the connection and start it again, then open “Log” to review startup and access entries. Verify with a new browser request rather than relying on whether the main connection button appears enabled.

Android’s app-specific private storage is separate from the regular Downloads folder. After downloading a file manually, use the client’s supported import or resource management process to make it available to the core. Another easy-to-miss factor is per-app proxying: if your browser is excluded from VPN routing, changing core routing rules won’t change that browser’s route.

Routing JSON: fields, outbound tags, and rule order

The routing snippet below is a reference for Xray/V2Fly-style configurations, not a complete configuration you can run on its own. It assumes you already have outbounds named direct and proxy: the former points to a direct connection, and the latter to an existing node. These tags are references only; writing direct does not create a direct outbound.

{
  "routing": {
    "domainStrategy": "AsIs",
    "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"
      }
    ]
  }
}

Rules are checked in order, and the first match determines the outbound. The last rule catches ordinary TCP and UDP traffic, so it must come after the more specific rules. If it’s placed first, later rules for direct access to mainland China won’t get a chance to handle those connections.

Field or expressionMeaningWhat to check
domainMatch against a domaingeosite:cn belongs here
ipMatch against the destination IPgeoip:private belongs here
outboundTagReferences the tag of an existing outboundSpelling and capitalization must match
AsIsDon’t resolve domains just for routing matchesIf a domain doesn’t match, the IP collection won’t be checked automatically

This example uses AsIs to make the behavior clear: if routing receives a domain and it isn’t in geosite:cn, the core won’t resolve it just to check whether it matches geoip:cn. The request then falls through to the proxy rule. The IP conditions here can be checked directly only when the request already contains an IP address.

Within a single rule, different conditions such as domain, ip, and port usually all need to match. Multiple entries in an array for the same field are alternative values. To express “the domain is in mainland China or the IP is in mainland China,” split them into two rules as in the example rather than putting both fields in one object.

Automatic updates or manual replacement: choose how you want to maintain resources

For everyday use, a stable data source and clear update results matter more than switching tags each time. Manual management makes more sense when the built-in resources are missing a collection you need or when you’re tracking a change introduced by a particular update.

Update through the client

Recommended

Run the update from the client’s Geo update or Resource files screen, which manages the resource location for you. Restart the service afterward and check the log to confirm the files loaded successfully.

Best for: everyday setups using common collections and avoiding path mistakes

Replace resources manually

First confirm the resource directory used by the core, then keep a copy of the old files before replacing them. Make sure the new files contain the tags your rules reference; matching filenames alone aren’t enough.

Best for: custom data sources or setups that require pinned resources or easy rollback and comparison

Bottom line: change one layer at a time

Update only the resources first, then restart and verify before changing the rules. If you switch nodes, change DNS, replace the databases, and reorder routing all at once, you won’t know which change fixed the problem.

Still taking the wrong route after an update? Troubleshoot the logs step by step

Test three types of destinations: a local network service you can access, a website that should connect directly, and a website that should use the proxy. Record each target, its expected route, and what the log shows. You don’t need a complicated speed-test table—first make sure each connection uses the right outbound.

Why does it still say the cn collection is missing after an update?

First confirm that you updated the file the core actually reads, then check whether the data source provides the cn tag. Stop the core, restore the previously working resource, and restart. If that fixes the problem, check the new data source’s collection documentation instead of repeatedly clicking Update.

Websites in mainland China still use the proxy. Should I move geoip:cn to the top?

First check whether the request contains a domain or an IP address. With AsIs, moving the IP rule higher won’t automatically turn an unresolved domain into an IP. Check geosite:cn and any earlier rules first, then decide whether to change the domain resolution strategy.

Why can’t I access devices at home when I have a private rule?

Start by testing the device’s actual local IP address. If connecting by hostname fails, check local name resolution separately. If the IP also fails, check whether the client bypasses the local network, whether the VPN is routing that traffic, and whether the service is listening on an accessible address.

Why is a rule harder to match when domain and ip are in the same object?

Different fields don’t act like a simple “or.” Split the mainland China domain and IP conditions into two rule objects, put them in the intended order, and restart the core. If the client’s routing editor generates the configuration automatically, check the final rules—not just what’s in the input fields.

Keep a working copy of your configuration and a record of where its resources came from. The next time routing behaves unexpectedly, compare the rule order and resource changes first, then check the connection path. This helps you tell whether the collection changed, the configuration references are wrong, or traffic never reached the core.