A node connecting successfully only confirms that proxy egress is basically working. If mainland China sites take an indirect route, LAN addresses go through the proxy, or a domain consistently avoids the intended route, the routing layer needs further investigation. GeoIP and GeoSite are two commonly used data sets at this layer. They do not replace VMess or VLESS settings and do not update subscriptions; instead, they provide Xray and V2Fly cores with searchable IP and domain collections.
This guide is for users whose subscriptions are imported and nodes connect normally, but who encounter unmatched rules, mainland China traffic sent through the proxy, or data-file errors at startup in v2rayN or v2rayNG. The key steps are to verify file locations and timestamps, update both databases, check rule prefixes and order, then validate each result through logs and live connections.
What GeoIP and GeoSite Handle
geoip.dat stores IP range collections organized by country, region, or purpose. A rule such as geoip:cn compares the destination IP with the relevant collection, while geoip:private is typically used for LAN, loopback, and other private addresses. It is useful when the destination IP is already known and can also supplement domain-based rules.
geosite.dat stores domain collections. Tags such as geosite:cn and geosite:category-ads-all are not ordinary domains; they tell the core to read groups of domain entries from the data file. The core can match full domains, subdomains, or regex entries, allowing domain-based routing before a connection reaches the target server.
The two data types are not interchangeable. A domain request may first match GeoSite. If an application connects directly to an IP address, GeoSite has no domain to compare and the decision must rely on GeoIP, the port, or other conditions. With TUN enabled, also consider sniffing and DNS settings: when sniffing recovers a domain, domain rules may participate again; without a recovered domain, the connection falls through to IP rules or the final rule.
Update Geo Files in v2rayN
The steps below use the Chinese interface of v2rayN 7.15.0. The update entry may be under the main menu or tray menu in different minor versions, but it usually includes “Check for updates” and “Geo files”. Keep the current connection stable before updating. If the data source is reachable only through a proxy, first verify that the system proxy or TUN is working.
-
Confirm the Core Type
Open “Settings” → “Parameters” → “Core Type” and confirm whether the active configuration uses the Xray core or the V2Fly core. Seeing VLESS or VMess in a subscription name does not confirm which core is running.
-
Open the Update Menu
Return to the main window and choose “Check for updates” → “Geo files”. If the current version shows “Update Geo files”, select that option and do not accidentally choose “Update subscription”.
-
Wait for the Files to Be Written
Watch the message area and confirm that both geoip.dat and geosite.dat have finished downloading and writing. In one test, the two files totaled about 11.9 MB and completed in roughly 5–30 seconds on a stable connection.
-
Restart the Running Core
Use “Restart service”, or stop and start the current configuration. Closing the settings window alone does not make the running core reload the data files.
-
Check the Startup Log
Open the “Log” window and make sure there are no messages such as load geosite, load geoip, or failed to start. Then test the outbound result for the target domain.
The portable version of v2rayN requires special attention to write permissions. If the program is stored in a system-protected directory, the interface may report a completed download even though the old files were not replaced. Exit the client and check the modification times of both files in the program directory; they should be close to the update time, not the time the installation archive was extracted.
After updating, avoid changing DNS, routing, and node settings at the same time. Keep the existing rules, restart only the core, and test again so you can determine whether the change came from the data files. If all three settings change together, it becomes difficult to identify the cause of misrouting.
Conclusion: Confirm That the Files Were Reloaded
“Download successful” only means that file transfer finished. The modification times must change, the core must restart successfully, and the startup log must contain no loading errors. Only when all three are true should the new data be considered active.
Update Geo Files in v2rayNG
The steps below use the Chinese interface of v2rayNG 1.10.31. Android menu layouts vary slightly with screen width, so the relevant entry may be in the top-right menu. Keep a working configuration selected during the process so the update URL can be reached through the proxy if necessary.
-
Check the File URLs
Open the top-right menu and go to “Settings” → “Geo files settings”. Confirm that the GeoIP and GeoSite download URLs point to their respective dat files, and make sure both fields do not contain the same file URL.
-
Run the Data Update
Return to the main screen, open the top-right menu, and choose “Update Geo files”. Wait until the page confirms that both files have been processed; do not force-stop the client during the update.
-
Restart the Connection Service
Disconnect the current connection, wait about 2 seconds, and reconnect. This allows the Xray core to reinitialize its routing module and read the new files.
-
Open the Runtime Log
From the main screen, open “Log” and search for keywords such as
geoip,geosite, androutingto confirm that no file-read errors occurred during startup. -
Retest the Target Connection
First test a mainland China domain that should clearly connect directly, then test a domain that should use the proxy. Record the egress address and connection time for each; do not judge rule matching solely by whether a page opens.
If the current version has no separate Geo update menu, first confirm the client version and active core. Do not treat “Update subscription” as a database update. Subscription updates handle the server configuration list, while Geo updates handle routing collections; their storage locations and load timing are different. v2flyNG uses the same Geo data concept, but its data files must match the V2Fly core and rule tags in use.
Check Rule Syntax and Match Order
A current database can still appear completely ineffective when the rules are written incorrectly. Common causes include a missing prefix, putting a domain tag in an IP condition, using a tag that does not exist in the data file, or placing a broader rule first. Routing is generally evaluated in order: once a connection matches the first applicable rule, later rules do not override it.
{
"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 example first allows private IPs directly, then sends mainland China domains direct, then mainland China IPs direct, and finally sends remaining TCP and UDP connections to the proxy outbound. The direct and proxy values must match the outbound tags in the existing configuration. If the client-generated tags are freedom, block, or something else, use the complete active configuration as the authority.
geosite:cnbelongs in the domain condition, not the IP condition.geoip:cnandgeoip:privatebelong in the IP condition.domain:example.commatches the domain and its usual subdomain scope; configure exact matching using the rule syntax supported by the core.- A custom data tag must actually exist in the dat file being used; do not guess tags from the filename.
- Order block, direct, and proxy rules from the narrowest applicable scope to the broadest, and put the catch-all rule last.
domainStrategy also affects the result. AsIs primarily matches the original domain information; IPIfNonMatch resolves the IP after no domain rule matches and then tries IP rules; IPOnDemand may trigger resolution earlier. Changing this option affects the DNS path, so it should not be treated as a simple “better traffic splitting” switch.
Conclusion: Check the First Matching Rule
When the result differs from expectations, first check above the target rule for a broader domain, IP, port, or all-network rule. Moving the target rule to the end of the list usually does not increase its priority.
Troubleshoot Startup Errors and Database Problems
When a file is missing, corrupted, or lacks a referenced tag, the core usually leaves more specific information in the startup log than a generic “connection failed” message. Preserve the complete error chain during troubleshooting, especially the filename, tag, and underlying read error; do not keep only the last line.
Error:failed to load geosite: geosite.dat: no such file or directory
Cause and fix:The core cannot find geosite.dat in its working directory, or the client points to the wrong path—run the Geo files update again, confirm that the file is written to the active core directory, and restart the service.
Error:failed to load GeoIP: geoip.dat: no such file or directory
Cause and fix:The GeoIP file is missing, was moved, or was not updated completely—exit the client, verify that geoip.dat exists and is larger than 0 bytes, then download it again.
Error:failed to decode geosite.dat: invalid wire-format data
Cause and fix:The download is not a valid data file, commonly because the transfer was interrupted or the URL returned a web page—delete the corrupted file, fetch it again through the client’s update menu, and restart the core.
Error:failed to load geosite: list not found
Cause and fix:The tag referenced by the rule is not present in the current geosite.dat—check the spelling and data source, then temporarily remove the rule to confirm whether the core starts normally.
If the client cannot start after an update, back up the routing configuration and temporarily disable all custom rules that reference Geo tags. If the core starts, the node protocol and basic outbound settings are probably fine, narrowing the issue to the data files or rule tags. If it still fails, continue by checking port conflicts, configuration syntax, and the core path.
Also check whether duplicate files exist. The client directory, core subdirectory, and custom resource directory may each contain a file with the same name, and the one actually being read may not be the one just updated. The most direct approach is to find the resource path shown in the startup log, then compare the file’s timestamp and size at that path.
Rule Matches but Traffic Is Still Misrouted
A clean log does not guarantee the routing result is correct. Geo data is maintained as collections, and domain ownership or server IPs can change. Large sites also use geographically distributed DNS and content delivery, so the same domain may resolve to different addresses on different networks. Distinguish between “the rule did not match” and “the outbound selected after the match was unexpected.”
| Symptom | Check First | How to Verify |
|---|---|---|
| Mainland China domain goes through the proxy | GeoSite tag and rule order | Add the target domain to a direct rule and place it before the broad proxy rule |
| No match when connecting directly to an IP | GeoIP condition and destination IP ownership | Record the destination IP, then check whether it matches geoip:cn or the private-address collection |
| TUN results differ from the system proxy | Sniffing, DNS, and domainStrategy | Keep the node unchanged and record the target domain and IP in the logs for both modes |
| Only some rules stopped working after the update | Whether the custom tag exists | Disable extended tags one by one, keeping geosite:cn and geoip:cn as the baseline test |
| LAN devices cannot be reached | Position of geoip:private | Move the private-IP direct rule before the proxy catch-all rule, then reconnect |
Build a minimal test configuration: keep one working node, one direct rule for private addresses, one direct rule for mainland China domains, one direct rule for mainland China IPs, and one proxy catch-all. Once this set works, restore ad domains, custom domains, process rules, or port rules in batches. Test after each batch; this makes conflicts easier to locate than loading dozens of rules at once.
Record at least three results during validation: the IP resolved for the target domain, the outbound tag selected by the core, and the final egress address. Page load speed is affected by caching, server load, and network jitter, so it cannot prove routing correctness on its own. If the local SOCKS listening port is 10808, also confirm that the test tool is actually using that port rather than bypassing the client through a direct system connection.
Conclusion: Use a Minimal Rule Set to Separate Data Issues from Order Issues
If geosite:cn and geoip:cn work correctly and misrouting begins only after extended rules are restored, the problem is usually the scope or order of a newly added rule, not the two databases themselves.
Complete Post-Update Checklist
A reliable update should cover four layers: files, core, rules, and connections. Seeing “completed” in the menu is not enough to prove that routing is using the new data. Finish the checks below before restoring auto-start, scheduled subscription updates, and other routine settings.
- Confirm that geoip.dat and geosite.dat both exist, are larger than 0 bytes, and have modification times close to this update.
- Confirm that the expected core is running. In v2rayN, check it under “Settings” → “Parameters” → “Core Type”.
- Disconnect and reconnect to ensure the old core process has exited and the new process has reread the resource files.
- Check the startup log for loading errors such as file not found, decode, or list not found.
- Check that GeoSite tags are in domain conditions, GeoIP tags are in IP conditions, and outbound tags match the existing configuration.
- Place private-address and exact-domain rules before the broad proxy catch-all to prevent an earlier match.
- Test domain connections and direct IP connections separately, and record the outbound actually selected instead of checking only whether the page opens.
- Confirm that application traffic in system-proxy or TUN mode really enters the client and that the test tool is not bypassing the local proxy port.
Geo data does not need to be downloaded again after every subscription update. Subscription changes mainly affect the node list, while Geo file changes mainly affect routing collections. Update on a practical schedule, or manually when new domains cannot be classified, old IP ownership has clearly changed, or an extended tag is missing. Replacing files frequently without restarting the core can instead leave the disk version and running version out of sync.
If a domain is consistently classified incorrectly by a collection, the safest temporary fix is to add a narrower custom domain rule and place it before the relevant collection rule. This corrects current connections without deleting the entire GeoSite or GeoIP rule set. After a later data update, retest the domain to see whether the exception is still needed.