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.
| Item | geosite.dat | geoip.dat |
|---|---|---|
| Matches | Domain in the request | Destination IP address |
| Common expression | geosite:cn | geoip:cn、geoip:private |
| Rule field | domain | ip |
| Common misconception | cn is a collection tag, not a match for only the .cn suffix | An 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.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
- Update subscription: Refreshes node details and subscription content; it usually does not update the core’s Geo data.
- Update resources: Replaces collection data but does not automatically enable a routing mode.
- Change routing: Determines which rules are checked; it won’t repair missing or corrupted resource files.
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 expression | Meaning | What to check |
|---|---|---|
domain | Match against a domain | geosite:cn belongs here |
ip | Match against the destination IP | geoip:private belongs here |
outboundTag | References the tag of an existing outbound | Spelling and capitalization must match |
AsIs | Don’t resolve domains just for routing matches | If 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
RecommendedRun 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.
- At startup: Look for errors such as missing resource files, collections that can’t be loaded, or unknown outbound tags. If startup fails, don’t troubleshoot which rule a web request matched yet.
- When accessing a destination: If your log level includes access entries, check the destination and outbound tag. If there’s no entry, first check the system proxy, VPN routing, or per-app settings.
- When checking the match: If the log shows the proxy outbound, check whether the domain is in the collection and whether an earlier, broader rule matched first.
- When checking the connection: If the connection matched the direct outbound but the destination still won’t open, investigate local DNS, the destination service, and the direct network path. Not every failure is caused by the database.
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.