GeoIP and GeoSite databases: How to Update Them—File Locations, Loading, and Rule References

What GeoIP and GeoSite each do

geosite.dat stores domain sets. A category may contain full domains, domain suffixes, keywords, or regular expressions, depending on the data-generation rules. For example, geosite:cn usually matches domains intended for mainland China, while geosite:category-ads-all references an advertising-domain category. It handles the domain in the request target; it does not indicate the region associated with the address returned by DNS.

geoip.dat stores CIDR range sets. geoip:cn compares the destination IP with ranges assigned to the corresponding country or region, while geoip:private matches loopback, LAN, and other private address ranges. It is used only during routing, does not modify DNS results, and does not replace subscription node information.

Whether a domain rule continues to resolve an IP also depends on domainStrategy. With AsIs, routing mainly uses the domain or IP already present in the connection; with IPIfNonMatch, the domain is resolved and IP rules are tried only after no domain rule matches; with IPOnDemand, the core may trigger resolution whenever rule evaluation might require an IP. Updating data files cannot fix an incorrect strategy combination, so check the file version, rule order, and domain strategy together.

• Domain known: Prefer a geosite category instead of inferring service ownership solely from the resolved address.
• Direct IP access: It can match only through geoip, a specific CIDR, or another IP condition.
• One request matches multiple rules: Routing evaluates rules from top to bottom, and the first rule that fully matches usually determines the outbound.
• Category name missing: The core reports a resource or tag loading error in the log rather than automatically selecting a similar category.

Data File Locations and Core Loading

A portable v2rayN installation usually contains the UI program, configuration data, and one or more core subdirectories. For v2rayN 7.12.7 with the Xray core, common locations are v2rayN\bin\Xray\geoip.dat and v2rayN\bin\Xray\geosite.dat. If the v2fly core is selected, the resource files must be placed in the directory that core actually reads, not copied mechanically into the Xray directory.

Directory nesting varies by installation method, architecture package, and version, so file-search results are only clues. A more reliable approach is to confirm the active core in v2rayN under “Settings” → “Parameter Settings”, then check the startup path in the core log. The executable directory and asset-loading errors in the log show which data files the current process is actually using.

The core usually reads geodata when it starts or reloads its configuration. Overwriting a file in use does not mean the running process will immediately adopt the new contents; in some cases, the process still holds the old file handle. After updating, stop the active core and restart the configuration. Simply turning off the system proxy is not necessarily a core restart—look for a new startup time and configuration-loading entry in the log.

Update geoip.dat and geosite.dat in v2rayN

v2rayN menu labels change between releases, but the 7.x workflow is largely the same: use the client to update Geo data, write the files to the corresponding core directory, then restart the core. Before updating, make sure the active node connects normally. A failed data download is unrelated to the routing rules themselves and cannot be fixed by repeatedly rewriting those rules.

1. Launch v2rayN, confirm a usable configuration is selected in the main window, and note the active core type.
2. Open “Settings” → “Parameter Settings” and check the local listening ports and core options. Common defaults are SOCKS 10808 and HTTP 10809; use the values shown in your local UI.
3. Return to the main window, open the “Check for Updates” menu, and choose “Update Geo Files” or the similarly named Geo data update item in your version.
4. Wait for the status bar or log to show that both data files have been processed. If only one finishes, do not treat the update as successful.
5. Choose “Restart Service”. If that option is not visible, stop the service first and then restart the active configuration.
6. Open the core log and confirm there are no errors such as failed to load geoip, failed to load geosite, or missing categories.

If the update times out, first check whether subscription updates and ordinary web requests also fail. If both fail, troubleshoot the active node, system clock, or local proxy port first. If only the Geo data update fails, check the network path used by the updater, write permission for the target directory, and whether security software has temporarily locked a file in use.

v2rayN\
├─ v2rayN.exe
└─ bin\
   └─ Xray\
      ├─ xray.exe
      ├─ geoip.dat
      └─ geosite.dat

When replacing files manually, fully exit the core process first and keep a copy of the old files. Then place both files in the asset directory for the same core. Do not overwrite the first search result based only on its filename. Run the core again and inspect the log; if it fails immediately, restore the old files and check whether the new files match the data format and category conventions supported by the active core.

Update and Reload Data in v2rayNG

v2rayNG uses the Xray core, and Geo data is usually placed in the app’s internal resource directory. Most users do not need to find the actual path in the Android file system, and should not copy the desktop directory layout to mobile. In the v2rayNG 1.10.x interface, look for “Update Geo Files” in the top-right menu; wording may vary slightly by build.

1. Select a configuration that connects successfully, tap the start button, and confirm that the live test returns a latency result.
2. Open the top-right menu, select “Update Geo Files”, and keep the app in the foreground until the completion message appears.
3. Stop the current VPN service, then restart the selected configuration so Xray rereads the asset files and routing configuration.
4. Go to “Settings” → “Routing Settings” and confirm that the active rules actually contain geosite or geoip references.
5. Open the log, visit one domain expected to connect directly and one expected to use the proxy, and compare the target, rule, and outbound tag.

Subscription updates and Geo data updates are separate processes. A subscription updates node information such as server address, port, user ID, and transport; a Geo update refreshes routing categories. Updating a subscription does not prove that the geodata was updated, and updating geodata does not change VMess or VLESS node parameters.

Mobile data and Wi-Fi may use different DNS servers and IPv6 paths. For testing, keep one network environment fixed and record logs before and after the update. If routing is correct on Wi-Fi but wrong on mobile data, the cause may be different DNS responses, missing IPv6 rules, or Private DNS settings—not the Geo files themselves.

How to Reference geosite and geoip in Rules

Geodata files participate in matching only when referenced by routing rules. The structure below blocks ad categories first, allows private addresses and mainland China IP ranges, then sends mainland China domains directly. Unmatched traffic goes to a later proxy rule or the default outbound. Outbound tags in the actual configuration must match the tags generated by the client; do not copy the example names blindly.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

Rule order matters more than the number of categories. If the first rule matches every connection with network: tcp,udp and sends it to the proxy, later direct rules for mainland China will never get a chance to match. Ad blocking generally belongs before ordinary direct rules, private-range allowances should come early, and the fallback proxy rule should be last.

geosite:cn and geoip:cn are not interchangeable. An international service may deploy nodes in mainland China while its domain category is still organized by service, and its resolved address may fall within geoip:cn. With IPIfNonMatch, a domain-category match prevents further reliance on IP ownership; that is why the intent of each rule must be explicit.

• To connect directly to devices on a LAN, place geoip:private before the fallback proxy rule.
• To override a category for a specific domain, place the exact-domain rule before the broader geosite rule.
• When handling IPv6, confirm that the current geoip data and custom CIDR rules include the relevant address family.
• After changing custom rules, restart the core and verify the result in the log; do not rely only on whether a webpage happens to open.

How to Distinguish Stale Data, Rule Conflicts, and Loading Failures

Stale data most often affects a small number of new domains, new IP ranges, or services with recently changed infrastructure, while many older rules continue to work. Rule conflicts are consistent: the same target is always intercepted by the earlier broad rule. Loading failures are more direct—the core startup log reports missing files, unreadable resources, or nonexistent tags.

For verification, choose at least four target types: a LAN address, a known mainland China domain, a domain expected to use the proxy, and a direct IP request. First clear the effects of browser connection reuse, then start a new connection for each target. In v2rayN, observe the core log and local port connections together; in v2rayNG, check the target address and outbound result on the log page. A single latency measurement cannot prove a routing match because network congestion also changes response time.

1. Record the active core type, data-file modification times, and routing mode.
2. Restart the core and confirm that the log contains no Geo asset-loading errors.
3. Test 127.0.0.1 or a LAN target to confirm direct access to private addresses.
4. Test a stable mainland China domain and confirm that it matches the direct outbound.
5. Test a domain explicitly configured for the proxy and confirm that it reaches the proxy outbound.
6. Place a temporary exact rule first and test again to distinguish a category-data problem from a rule-order problem.

If an exact-domain rule fixes routing while the corresponding geosite category still does not match, then it is reasonable to inspect the GeoSite content or version. If the exact rule also has no effect, first check whether the client is using a different routing mode, whether the subscription-generated configuration overrides custom entries, and whether the core was actually restarted after the change.

Update Frequency and Maintenance Boundaries

There is no fixed Geo data update schedule that fits every environment. For regular use, checking once a month is usually enough to cover normal domain and IP-range changes; update immediately when a new service routes incorrectly, an operator changes address ranges, or the log reports a missing category. Frequent updates cannot fix incorrect rule order or improve node quality.

In teams or multi-device environments, record the client version, core type, update time, and rule version. Desktop and Android clients can share the same routing intent, but do not assume they load the same physical files. The cores, asset directories, and update controls of v2rayN, v2rayNG, and v2flyNG are independent, so verification results should be kept separately.

• Keep the currently working rule configuration before updating so you can roll back if the update fails.
• Always restart the core after updating and check the new startup log.
• Test both domains and IPs so you do not verify only GeoSite or only GeoIP.
• Record subscription changes, DNS changes, and Geo data changes separately.
• When rules behave unexpectedly, check their order and enabled state before suspecting stale data.

A reliable maintenance workflow is not repeated file replacement. Confirm the core path, update through the client, reload the process, inspect the log, and verify with fixed test targets. Only by connecting file version, loading process, and rule matches can you determine whether a routing change comes from the database, configuration, or network environment.