This guide is for users who have imported nodes and want to check their routing rules. First, understand the difference between domain categories and IP databases. Then update the data files used by your client and verify the results with a minimal routing example and logs. Check file downloads, category loading, and traffic routing separately to avoid repeated updates that do not fix misrouted traffic.
What Each Database Matches
geosite.dat stores domain entries organized by labels; geoip.dat stores IP address ranges organized by labels. These are binary data files read by the core—not JSON to paste into a routing editor, and they do not contain subscription links, node passwords, or transport settings.
For example, geosite:cn looks up the cn category in the domain database, while geoip:cn looks up the cn ranges in the IP database. These are separate lists: a domain's category does not mean every address it resolves to is in the same region. This distinction is especially common with sites using overseas CDNs.
| Resource | Matches | Typical reference | Limitations |
|---|---|---|---|
geosite.dat | The domain in the request or identified by the core | geosite:cn | Depends on category coverage; it is not a live DNS lookup |
geoip.dat | Destination IP address | geoip:cn | Classifies IP address ranges; it does not identify the service operator |
geoip.dat | Private or reserved address ranges defined by the data source | geoip:private | The exact ranges depend on the labels in the data source |
Requests made directly to an IP address cannot match a domain category. Whether a domain request can also be matched against an IP range depends on the routing domain strategy and DNS resolution. So updating geosite does not mean every app will route by domain; check what destination information the client actually receives.
Choosing a Data Source and Update Method
Common data sources include community-maintained domain lists and IP range projects, compiled into DAT files by a build process. Domain entries can use different forms, including full domains, suffix matches, keywords, and regular expressions; IP databases group CIDR ranges by label. Xray and V2Ray ecosystem files follow specific format conventions, but files with the same name from different sources do not necessarily contain the same labels.
The client app, core, rule data, and routing rules are four separate layers. Updating v2rayN does not necessarily update the Geo files currently in use, and updating Geo files does not reorder custom rules. Before switching data sources, note the labels your rules reference, such as cn, private, and service categories, and confirm the new source includes them.
Update Through the Client
RecommendedThe client downloads files from its configured resource URLs and saves them to a location it manages. This helps avoid placing new files in an outdated directory, and the update log makes it easier to identify failures.
Best for: routine maintenance, keeping the default data source, and initial troubleshooting.
Import or Replace Files Manually
First confirm where the active core reads its resources, then use files from a trusted source. On Android, use the import feature provided by the client rather than guessing the app's private directory.
Best for: offline updates, unreachable built-in downloads, or pinning a specific data version.
Switch to a Custom Source
Check the download URL, file format, and category list together. Do not replace a file just because it is larger: extra categories may not help, while missing a referenced category may prevent the core from starting.
Best for: users who depend on a specific service category and can maintain their rule references.
Bottom line: Keep the source consistent, then update the data
Back up your current resources and routing configuration. Update and verify the data from the same source first. Switch sources only if a required label is missing; do not change the source, DNS, and rule order all at once while troubleshooting.
Update and Reload Geo Data in v2rayN
On desktop, first confirm that the active connection uses Xray or V2Ray DAT routing rules. The examples here do not apply to other rule-set formats. Menus vary between v2rayN versions; the update option is commonly under “Check for updates,” listed as “Geo files” or “Update Geo files.” If your version puts it on a resource management page, follow the current menu labels and logs. “Update subscriptions” does not update rule data.
-
Record Current Settings
Open “Settings” → “Routing settings” and note the active routing profile, rule order, and categories in use. Back up any custom configuration separately. In some versions, saving a profile is not enough—you must also select it in the main window to activate it.
-
Update Rule Data
In the main window, open “Check for updates” → “Geo files” and run the update. Check the results for both
geoip.datandgeosite.dat; do not close the log just because the first item succeeded. -
Check the Download Results
If the connection fails, first check the resource URL and whether the update needs to go through your current proxy. If the response cannot be parsed, make sure you entered a direct file URL rather than a web page URL; a filename alone does not mean the response contains DAT data.
-
Restart the Active Service
After writing the data files, restart the active connection so the core reloads them. Switching tabs in the main window does not reload resources, and existing long-lived connections do not show how new rules will behave.
-
Check the Startup Log
Make sure there are no errors opening resources, missing categories, or building routes. Then send a new test request. If the client automatically restores an older configuration, confirm that the profile actually running is the one you just saved.
Where to Update Geo Resources in v2rayNG
On Android, v2rayNG uses the Xray core and usually manages Geo data within the app. Versions with a dedicated resource manager let you open “Geo resource files” from the side menu to update or import files. Older versions may have “Update Geo files” in the top-right menu on the main screen. If the menus differ, look for Geo resource options rather than checking subscription groups.
- Before updating: In the side menu, open “Routing settings” and note the current rules. Make sure global proxy or global direct mode is not temporarily enabled, or your routing tests will not produce the expected results.
- While updating: Check the status of both resources separately. If the resource page lets you change download URLs, use a URL that returns the raw file—not a project information page.
- After updating: Stop and restart the connection service at the bottom of the app so the new core process loads the data. Returning to the app does not restart the connection.
- Manual import: Use the import action available on the resource page and verify the file type. If your version has no import option, do not try to replace resources by guessing the app's private directory.
If updates must go through a proxy, make sure an existing connection can reach the resource server. If the proxy cannot start because resources failed to load, use a download source accessible on your current network or import files offline. Do not confuse a download path that depends on the proxy with routing rules that depend on the data, and retry both blindly.
How to Reference geosite and geoip
In Xray routing JSON, put geosite: references in the domain array and geoip: references in the ip array. Category names are not arbitrary descriptions; they must exist in the current data file. In geoip:cn, cn is a commonly used country-code label. private is a special label defined by the dataset, not a country code.
{
"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"
}
]
}
}This is a routing-rule example, not a complete configuration that can run on its own. It assumes the full configuration already defines direct and proxy outbounds. To block traffic, define and reference block separately. These labels are just names and must match actual entries in outbounds; copying them will not create outbounds automatically. In a graphical rule editor, enter only the relevant match fields rather than pasting the entire JSON.
- Rule order: Rules are evaluated in order, and the first matching rule determines the outbound. A broad catch-all rule near the top can prevent more specific categories below it from ever matching.
- Domain strategy:
IPIfNonMatchattempts DNS resolution and IP matching when no domain rule matches. It does not mean every request is resolved first, and it is not a DNS server address setting. - Suffix and exact-domain matches:
domain:example.comandfull:example.comare direct domain matching rules, not database categories. The first matches the domain and its subdomains; the second matches only that exact domain. - Category differences:
geosite:category-ads-allworks only if the current data source includes that label. Do not assume that a service category supported by one source is also available in another.
To specify a different file, Xray supports external resource references such as ext:custom-site.dat:cn. The file must be in a location the core can access and must contain the requested category. For typical use, stick with the default filenames; external file references are not needed just to update the data.
Verify Updates and Troubleshoot Problems
Verify in this order: resources loaded → rules matched → traffic reached the expected outbound. Checking whether a website opens is not enough: both proxy and direct connections may work, and cached pages can hide routing changes. Record results before and after the update, keeping the node, DNS, and test destinations unchanged.
| Symptom | Check first | What to do |
|---|---|---|
| Core fails to start | Resource path, file contents, category names | Check filenames and labels in the startup log; restore the previous resources and fix items one at a time |
| Update succeeds, but behavior is unchanged | Active configuration, service restart, existing long-lived connections | Restart the connection service and use a new request to check the actual outbound |
| Domain rule does not match | Whether the destination domain is visible, category coverage, earlier rules | Temporarily add an exact-domain rule to distinguish missing data from missing request details |
| IP rule does not match | Actual destination IP, domain strategy, DNS result | Check the destination IP in the logs and whether the domain needs to be resolved before matching |
| A local network service is proxied | Private IP rules, rule order, local domain names | Check the specific destination first, then add an explicit direct rule |
In a test environment you control, request the service at 192.168.1.10:8080 to check direct access to a local network address. This address and port are examples only; replace them with a real service on your network. Then choose one site that is definitely included in a category in the current domain database and another that should use the proxy. Check the destination and outbound labels in the access logs for each. If access logging is disabled, temporarily enable an appropriate log level, then turn it off after testing to avoid keeping unnecessary access records.
Bottom line: Isolate the problem with one rule
Temporarily add a top-priority exact-domain rule for a misrouted domain. If the outbound changes, investigate category coverage and rule priority. If it does not, first confirm that traffic is reaching this client, the correct configuration is running, and the core has access to the domain name.
Once routing is stable, remove the temporary test rule and record the data source, update date, and available categories. Geo data benefits from periodic maintenance, but it does not need updating every time a connection fails. Authentication errors, unreachable servers, and mismatched transport settings usually call for checking the node or protocol settings, not changing geographic categories.