How to Update GeoIP and GeoSite Databases for More Precise V2Ray Routing

What Problems Do GeoIP and GeoSite Solve?

The V2Ray and Xray routing modules first identify the connection target, then send it to a direct, proxy, or block outbound. When the target is an IP address, GeoIP data can identify its network range. When the target remains a domain, GeoSite data can identify its site category. Neither file is part of the client program, and neither changes VMess, VLESS, or other protocol parameters; they only provide the data used for routing matches.

geoip.dat stores IP ranges organized by region or purpose. Common rules include geoip:cn and geoip:private: the former usually matches IPs in mainland China, while the latter matches reserved ranges such as LAN and loopback addresses. When the database is outdated, newly allocated ranges may not match the existing set and may fall through to the final catch-all rule.

geosite.dat stores domain sets organized by category. Common tags include geosite:cn, geosite:geolocation-!cn, and category tags supplied by some data sources. It matches domains, not webpage content. When a site changes domains, adds static-asset domains, or changes service endpoints, old data may match only the main domain and miss image, API, or login domains.

Record Versions, Paths, and Existing Rules Before Updating

Do not overwrite every file as soon as a connection problem appears. First record the client version, core type, current outbound tags, and custom routing rules so you can identify what changed after the update. The paths in this guide use v2rayN 7.x, v2rayNG 1.10.x, and the Xray core as the baseline. Menu labels may vary between minor releases, but the checking order remains the same.

On desktop, also confirm the core directory actually in use. In v2rayN, open “Settings” → “Parameter Settings” → “Core Settings” to see the selected core. Depending on how it was installed, Geo files may be in the program data directory or the corresponding core directory. Do not overwrite the first file with a matching name found by search; confirm the core startup path in the runtime log first.

• Export or copy the current custom routing configuration, especially domain, ip, inboundTag, and outboundTag.
• Record the current core version and configuration-file location in the log, so you do not confuse the v2fly and Xray runtime directories.
• Confirm that the system time and time zone are correct. A significant clock difference can affect update requests and TLS connections and should not be mistaken for a Geo data problem.
• Keep working copies of geoip.dat and geosite.dat; restore both files together when rolling back.

Update Geo Data Files in v2rayN

v2rayN’s built-in updater downloads the data for the current version and replaces the files read by the core. It is more reliable than manually guessing the directory. Stop the proxy service before starting so the core process does not keep the old files open. If TUN mode is enabled, turn it off before updating.

1. Open the v2rayN main window and confirm in the status bar that the current core has stopped running.
2. Open the “Check for Updates” menu and choose “Update Geo Files” or the equivalent Geo data update option. In some 7.x versions, this entry is inside an update submenu.
3. Wait until the interface shows that downloading and replacement are complete. Do not exit the client while the progress is still running.
4. Open “Settings” → “Parameter Settings” → “Core Settings” and confirm that the selected core is the same one targeted by the update.
5. Start the original node, then open the log window and confirm there are no errors such as geoip.dat not found, geosite.dat not found, or an unknown rule tag.
6. Re-enable the system proxy or TUN mode, then test one domain in mainland China and one domain that should use the proxy to verify the outbound results.

If the built-in updater reports that a file is in use, exit v2rayN and confirm in Task Manager that the relevant core process has ended, then reopen the client and try again. If writing fails, check whether the program directory is writable by the current account. Do not run the program permanently as administrator to hide a permissions problem; placing program data in a location writable by the account is safer.

Manual replacement is appropriate only when you have obtained trusted data files and know exactly where the current core reads them. Stop the core, rename and retain both old files, then place the new geoip.dat and geosite.dat together in the same data directory. Replacing only one file can create inconsistent tag coverage and add another variable during troubleshooting.

Check and Update Geo Resources in v2rayNG

v2rayNG uses the Xray core for routing, and the app manages its Geo files. Android generally does not expose an app’s internal data directory as a normal folder, so update from v2rayNG’s Settings page rather than copying desktop files to a downloads folder and waiting for the client to detect them.

Before starting, tap the Stop button on the main screen and confirm that the proxy service has ended in the status bar. If “Bypass LAN” or custom routing is enabled, record the current options as well, because updating the resources does not automatically fix rule order.

1. Open v2rayNG and stop the current connection.
2. Open the top-right menu, then go to “Settings” → “Geo Resource Files”. Some minor versions may label this “Geo Files” or “Update Geo Data”.
3. Run the GeoIP and GeoSite updates separately and wait for both to show completion. On a slow network, keep the app in the foreground to prevent the system from interrupting the tasks.
4. Return to the Settings page, open “Routing Settings”, and check that both predefined and custom rules are still enabled.
5. Return to the main screen, start the node again, and check the runtime log to confirm that resource loading and routing initialization completed without errors.
6. Toggle airplane mode once, restore the network, and then run domain and IP tests to rule out the effects of existing connections and DNS cache.

Rule Order Determines the Actual Result After an Update

Geo data only provides matchable sets; the routing rules still determine the final outbound from top to bottom. Put more specific LAN, domain, and IP rules first, broader regional sets later, and a proxy or direct fallback last. If the first rule already matches all of 0.0.0.0/0, later GeoIP rules never get a chance to run.

The snippet below shows a common order: send private addresses direct first, then send domains and IPs in mainland China direct, and send domains outside the region through the proxy. direct and proxy must match the actual outbound tags; do not copy these labels without checking the configuration generated by the client.

{
  "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",
        "domain": ["geosite:geolocation-!cn"],
        "outboundTag": "proxy"
      }
    ]
  }
}

IPIfNonMatch means that when no domain rule matches, the core resolves the IP and tries the IP rules. It suits configurations that use both GeoSite and GeoIP, but adds another resolution step. With AsIs, the core does not resolve domains for IP routing, so rules relying on geoip:cn may not process targets that remain in domain form.

• Place LAN rules before regional rules so printers, router admin panels, and local services do not use the proxy outbound.
• Place exact domain rules before broad GeoSite tags to handle a small number of sites that need special treatment.
• Use block rules only with tags that are actually present in the current data file. If the log reports an unknown tag, verify the data source and tag name.
• Keep one clearly defined direction in the final fallback rule and avoid multiple empty-condition rules masking one another.

How to Confirm the Core Loaded the New Data

A “Update successful” message alone does not prove that routing is using the new data. Verify three layers: file loading, rule matching, and actual outbound behavior. First check the startup log, then inspect rule order, and finally compare whether the target connection uses direct access or the proxy. Checking the layers separately prevents DNS caching, node latency, or browser connection reuse from being mistaken for a failed Geo update.

1. Immediately after restarting the core, check the log and search for keywords such as geoip, geosite, failed, and routing.
2. Visit a domain in mainland China that the routing rules explicitly send direct, and record the target domain, target IP, and outbound tag shown in the log.
3. Then visit a domain handled by geosite:geolocation-!cn and confirm that the log shows proxy outbound.
4. Connect directly to a known IP and check whether the GeoIP rule participates in the match. Run this separately from the domain test.
5. If you use a local HTTP or SOCKS inbound, confirm that the app’s connection port matches the value shown by the client, such as 10808 in a common setup. Do not test the new configuration with an old port.

Update Frequency and Common Questions

There is no fixed update schedule that suits every Geo data user. For ordinary use, check once a month. Check immediately when custom routing changes frequently, new domains need to be recognized, or some addresses suddenly use the wrong outbound. After upgrading the client core, also confirm that the Geo files still load correctly; without symptoms, there is no need to update every day.

Treat updates as part of routing maintenance, not a universal fix for connection failures. An unavailable node, incorrect VMess or VLESS parameters, a disabled system proxy, or an occupied port will not be fixed automatically by replacing Geo files. Use the logs to determine that the fault is in the routing layer before updating the data.