GeoSite categorizes domains, while GeoIP categorizes IP ranges. These files provide data used by routing rules; they are not node subscriptions. This guide is for users who can already connect but need to refresh routing data or troubleshoot traffic taking the wrong route. Follow the sequence: identify the core and data source, update the files, restart the service, then check which rules match. This is more targeted than repeatedly updating your subscription.
What each .dat file does
Think of routing as a traffic assignment table: which requests connect directly, which go through a proxy, and which are blocked. geosite.dat and geoip.dat provide the categories that table uses. Updating these files may change the categories, but it does not automatically rewrite rule order or outbound selection in the client.
| File | Contents | Example rule reference | Requirements |
|---|---|---|---|
geosite.dat | Domain entries organized by tag; matching types may include domains, full domains, and regular expressions | geosite:cn | The core receives the destination domain, and the data source provides the corresponding tag |
geoip.dat | IPv4 and IPv6 address ranges organized by tag | geoip:cn | The destination is an IP address, or the routing strategy allows resolving the domain before matching by IP |
geosite:cn means “use the collection named cn in the current GeoSite file.” It does not mean “match every domain ending in .cn.” The collection may include domains with other suffixes; its scope is determined by the data maintainers. Likewise, geoip:cn is an IP range category. It does not guarantee where a website's service is hosted, nor is it a substitute for latency testing.
A node subscription configures which server to connect to and which protocol and parameters to use. Geo files determine which category a domain or IP belongs to. Node protocols such as VMess and VLESS are a separate layer, so updating a subscription does not update the routing database.
Before updating: check the core, source, and backup files
First, confirm which data format your setup uses. This guide covers the traditional .dat routing data used by Xray and V2Fly. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. On desktop, check which core your v2rayN configuration actually uses. If your setup uses another rules format, changing a file extension alone will not make this method work.
- Note your active routing setup. In v2rayN's routing settings, record the current profile, rule order, and default outbound. On Android, note the active routing mode too. Don't change the routing template while updating the data.
- Keep the existing data. On desktop, stop the core and back up both .dat files from their active location. On Android, use the in-app update option where possible; don't try to force changes into the app's private directory with a file manager.
- Verify the data source. If you use a custom Geo update URL, make sure the response is a binary data file—not a download information page, login page, or error page. A filename ending in
.datdoesn't guarantee that the contents are valid. - Check tag compatibility. Tags can differ between data sources. Every collection referenced by your rules, such as
cn,private, or another tag, must exist in the selected files.
v2rayN: Update Geo files and reload them
Menu layouts vary across v2rayN versions, desktop editions, and the classic interface. A common path is Main window → Check for updates → Update Geo files. Some versions list GeoIP and GeoSite as separate update options. The steps below use this common path. If the menu labels differ, look for the Geo data update option; updating your subscription is not a substitute.
-
Record your current setup
Note the current node, active routing profile, and core type. If you plan to replace files manually, exit the program and back up the originals first. Try the client's built-in update feature before replacing files yourself.
-
Update the data
Open Check for updates → Update Geo files. If GeoIP and GeoSite are listed separately, update both in turn and confirm each result. Don't assume the update is complete just because one succeeded.
-
If the download fails
First, check that your regular network connection and current proxy are working. If your version offers an option to update through the proxy, retry after confirming the proxy connection works. Don't keep retrying through a proxy that isn't working.
-
Restart the core
Restart the core after the update. If you can't find the relevant button, exit v2rayN from the system tray menu and relaunch it. Closing only the window may leave the core running in the background.
-
Check the startup result
Open the logs and check for data file read errors, missing tags, or rule loading failures. Keep the same routing profile and then test access to a website.
If you need to update files manually, don't assume the core uses the files with matching names in the program directory. The installation method, core directory, and resource directory settings can all affect the active file location. Check the client configuration and resource paths in the startup logs. Stop the core, replace the files in the correct location, then restart and check the logs. Keep the filenames exactly as geoip.dat and geosite.dat. If file extensions are hidden, take care not to create duplicate extensions.
Bottom line: use the built-in updater first, then check the file paths
If the built-in updater reports success but behavior hasn't changed, check the active routing profile and whether the core reloaded the data. Replace files manually only after confirming that the core is reading from the wrong path. Copying the same files into multiple directories makes future troubleshooting harder.
v2rayNG: Update Geo resources in the app
The Geo update option in v2rayNG moves between versions. It's commonly found in the overflow menu at the top right of the main screen, with a label such as Update Geo files or Update Geo resources. Some versions place it in the overflow menu on the Routing settings screen. Check the main screen first, then Routing settings, and use the Geo update option shown in your version.
-
Check your connection
Keep your current working node. If the data source isn't directly accessible on your current network, connect through the proxy first. Whether the update request uses the proxy still depends on the app settings and which traffic the proxy actually handles.
-
Open the update option
Look for the Geo update option in the overflow menu at the top right of the main screen. If it's not there, go to Routing settings → overflow menu at the top right. Don't use the update button for a subscription group instead.
-
Wait for the update to finish
Start the update and check the app's status message. If the two files are updated separately, confirm each one. If an update fails, check your network and available storage first. Avoid tapping repeatedly and starting multiple update jobs.
-
Stop, then reconnect
When the update finishes, tap the connection button on the main screen to stop the service, then connect again so the core reloads the resources. Afterward, check Routing settings to confirm the expected rules are still active.
If you can't find a Geo update option in your installed version, note the version shown in the app's version information and check which options it provides. If needed, choose an appropriate package from the client download page. Don't copy desktop file paths to Android or clear app storage just to replace the data; doing so may also remove nodes, subscriptions, and custom rules.
How to use geosite:cn and geoip:cn
The following is a routing snippet in the Xray and V2Fly style, not a complete, standalone configuration. It matches the cn domain collection first, then private and cn IP ranges. direct must match an outbound tag that exists in your full configuration. If your direct outbound uses a different name, change it here too.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"geoip:private",
"geoip:cn"
],
"outboundTag": "direct"
}
]
}
}Rules are checked from top to bottom; the first match determines the outbound. The domain rule above doesn't need to resolve the domain to an IP address first. Whether the later IP rule can match domain requests depends on domainStrategy. This field belongs to the routing object; don't confuse it with DNS settings or a field with the same name under an outbound.
| Strategy | How domain requests are handled | What to check |
|---|---|---|
AsIs | The routing stage doesn't resolve domains for IP rules; destinations that are already IP addresses can still match IP rules | An IP rule alone doesn't guarantee that domain requests will match |
IPIfNonMatch | If a domain doesn't match a rule, try resolving it to an IP address and continue matching | An earlier catch-all rule may prevent this resolution step |
IPOnDemand | Try resolving the domain when IP information is needed during matching | Rule order and DNS results can both affect the final outbound |
The example doesn't specify a final fallback outbound. In your full configuration, use the default outbound and other rules to define what happens to unmatched requests. In particular, don't put a proxy rule that matches all TCP and UDP connections before these rules and then expect the cn rules to take effect.
Bottom line: first check whether the rules can match at all
If a website keeps using the wrong outbound, first check for a broad rule above it, then confirm the domain reaches the core, and finally inspect the collection contents. Updating the .dat files is a direct fix only if the collection itself is actually out of date.
How to verify an update and roll back if something goes wrong
Verification should cover both core startup and connection behavior. A page loading in your browser only proves that a working route exists; it doesn't prove that traffic used the intended outbound. Page, connection, and DNS caches can also hide changes. Start a new connection before testing instead of simply refreshing the same page.
- First, check that the data loads. After restarting the core, check the logs to confirm that the files were read and the rules initialized successfully. If a file is missing, check the resource path. If a tag doesn't exist, check whether the data source provides the tag your rule references.
- Next, check the destination. Choose a domain you know belongs to the target collection and record the hostname of the actual request. A webpage may connect to multiple domains, so the route used by the main page doesn't tell you how all its resources were routed.
- Then, check the outbound. If the client logs routing decisions or outbound tags, use the request time to find the relevant entry. If necessary, temporarily increase log detail, then restore the previous level when troubleshooting is done to avoid keeping unnecessary access details.
- Finally, test a rollback. If the core won't start after an update, stop the service and restore the original files. On Android, prefer the app's supported method for restoring a known-good data source. Reconnect after restoring, and avoid changing DNS and routing at the same time.
Why hasn't routing changed after updating my subscription?
Subscriptions mainly update node connection settings. Update the Geo files separately, and confirm that the active routing profile actually references those collections. Updating the .dat files won't change manually written domain rules.
What should I do if a geosite tag is missing?
First, note the full tag—the collection name after the colon in the rule—and check whether the current data source provides it. Change the rule to a tag supported by that source, or restore the matching data source. Repeatedly downloading the same file won't add a missing collection.
Geo files updated, but traffic to websites in mainland China still uses the proxy. Why?
Check the active routing profile, earlier catch-all rules, and whether the destination domain is visible to the core. If the core receives only an IP address for the connection, GeoSite domain rules may not apply. Check the connection method and sniffing settings rather than assuming the cn collection is broken.
Do I need to update these files every day?
There's no need to update frequently just to change the file date. Maintain the files periodically, and update them when categories have clearly changed or data is missing. Keep a known-good version each time. Confirming core startup and outbound behavior after an update matters more than chasing the newest date.
When troubleshooting Geo data, change one thing at a time: update the data and verify it first; if rules need changing, adjust them separately. Changing the node, DNS, routing template, and data source all at once makes it hard to identify the cause, even if the connection comes back. For the order of operations between the system proxy, subscriptions, and routing, continue with the Getting Started guide or consult the glossary.