How to Update GeoIP and GeoSite Files: Replace Databases and Configure Rules in v2rayN and v2rayNG

1. What GeoIP and GeoSite Match

geoip.dat contains collections of IP address ranges organized by tag, while geosite.dat contains domain rules organized by tag. These are binary resources queried by the core—not node lists or subscription URLs. Updating them does not change your server, port, or user credentials.

geosite:cn does not mean “all domains that resolve to IPs in China.” Likewise, geoip:cn does not mean “all Chinese-language websites.” A domain may use an overseas CDN, and a service based outside China may have an access point in mainland China. Treat domain and IP collections as separate matching criteria.

The databases provide collections for matching; routing configuration determines whether traffic is sent direct, through a proxy, or blocked. Even after a successful update, routing behavior will not change unless the active configuration references the relevant collection.

2. Before Updating: Note the Core, File Path, and Rollback Plan

v2rayN is a desktop client that passes generated configurations to the selected core to handle traffic; v2rayNG uses the Xray core. Do not assume the client installation folder, configuration folder, and core resource folder are the same. In particular, after switching cores on desktop, the files you replaced may no longer be the ones read by the running process.

1. Record your current setup: Note the client version in the About or version information screen, and record the core name and version from the startup log. Keep the original error message instead of just noting that it “won't connect.”
2. Back up your routing configuration: Save your custom rules and current Geo update URLs. If replacing files manually, also back up the existing geoip.dat and geosite.dat.
3. Confirm the resource format: This guide uses dat files. Do not rename a ruleset in another format to geosite.dat; matching filenames do not make the file formats compatible.
4. Keep changes isolated: Update the resources first, then verify them before changing rules. Avoid upgrading the client, replacing the core, changing DNS, and reordering routes all at once, or it will be difficult to identify what caused a change.

3. v2rayN: Use the Built-In Updater Before Replacing Files Manually

In v2rayN desktop versions that support this feature, open the top-level “Check for updates” menu and select “Update Geo files.” Menu locations and labels may vary by version and interface layout, so use the Geo update option shown in your current version. This is separate from “Update subscription”: refreshing a subscription updates server configurations, not routing resources.

1. Make sure the update network is available: First connect to a working node using your current configuration. If the updater offers direct and proxied downloads, choose the option that works on your network. A download working in your browser does not mean the client's update request uses the same route.
2. Run the Geo update: Check the client log and confirm that the files were downloaded and saved. A timeout, interrupted connection, or write error means the update did not succeed; don't assume it worked just because the menu closed.
3. Reload the core: After updating, restart the active service through the client, or exit the client normally and reopen it. This ensures the new files are loaded the next time the configuration starts.
4. Check the startup result: Confirm there are no resource loading errors, then test one destination expected to go direct and another expected to use a proxy. If the new database lacks a tag used by an existing rule, roll back the database or update that rule.

When Replacing Files Manually, Find the Active Resource Directory

In portable installations, a visible bin subdirectory can be a useful clue, but it is not a universal path. Check the startup log, core launch arguments, and client directory settings to find the resource location actually in use. If multiple files have the same name, don't guess based on their modification dates.

• Stop the core process started by the client, then back up the old files in the target directory to avoid overwriting them while they are being read.
• Get compatible files from a data source you already trust. If you downloaded an archive, extract it first; a saved webpage or download error page cannot be used as a dat file.
• Replace geoip.dat and geosite.dat as needed, keep their filenames exact, and make sure the account running the core has permission to read them.
• If you changed data providers, check all tags referenced by your routing rules again. A resource being parseable does not mean it includes every category from the old data source.

4. v2rayNG: Update Through the Geo Resource Menu

Open the “⋮” menu in the upper-right corner of the v2rayNG main screen and look for an option such as “Update Geo resources.” Some versions call it “Update Geo resource files.” This updates local resources used by Xray, not the nodes in your subscription. If your version has no matching option, check its version and feature documentation first; don't overwrite a file with the same name in your system Downloads folder.

1. Keep your routing settings: Note the current routing mode, custom rules, and resource source settings. Updating resources should not change these configurations.
2. Update the resources: Make sure the update URL is reachable. If your version supports custom Geo resource URLs, enter a URL that returns the corresponding binary file—not a release page or subscription link.
3. Check each result: If the interface reports GeoIP and GeoSite download statuses separately, verify both. A successful update of one file does not mean the other was updated too.
4. Restart the connection: Stop and restart the connection after updating, then check the core log and test a domain and a local network destination that should match your rules.

Use a stable custom resource source. After changing providers, check that tags such as cn and private used by your rules are available. Some extended categories exist only in particular datasets; don't assume they are available just because another guide uses them.

5. How to Reference geosite:cn and geoip:private

The following is an example of the V2Ray/Xray routing field, not a complete client configuration. It assumes the existing outbounds are tagged direct and proxy; adjust the example if your tags differ. Client-generated node configurations are typical, so don't paste this entire snippet into a subscription URL field.

{
  "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"
      }
    ]
  }
}

• Put domain collections in domain: geosite:cn refers to the cn category in geosite.dat. The core needs the destination domain to match this rule.
• Put IP collections in ip: geoip:private is commonly used for local and private network addresses; geoip:cn matches address ranges classified as China in the database.
• Different fields are combined with AND: Including both domain and ip in one rule means both conditions must match, not “either one.” To send traffic direct when either the domain or IP matches, split them into separate rules as shown in the example.
• Rules are evaluated in order: Put catch-all TCP and UDP proxy rules last. If they come first, later direct rules generally won't get a chance to match.

IPIfNonMatch means that if no rule matches during domain matching, the core then tries to resolve the domain and match the resulting IP. It does not mean “resolve every domain first, then run all rules.” With AsIs, a request that has a domain but no destination IP will not automatically get the same IP matching just because geoip:cn is configured. DNS results also affect the final IP classification, so don't confuse resource updates with DNS troubleshooting.

Reference: Private IPv4 Address Ranges

When troubleshooting direct connections to a local network, start with these three RFC 1918 ranges to check whether the destination is on a private IPv4 network. They are reference points, not the complete contents of geoip:private; loopback, link-local, and IPv6 ranges require separate consideration.

6. Verify the Update and Troubleshoot Common Errors

Verify in two stages: first confirm that the files loaded successfully, then check that requests matched the expected rules. A completed download, a successful core startup, and an accessible website are three different outcomes. Being able to open a website once does not prove that a direct rule is working.

1. Check the startup log: Search for terms such as geoip, geosite, and failed to find missing files, format errors, or missing categories.
2. Check the actual outbound: If the log shows routing or access records, confirm which outbound tag was used for the test request. If needed, temporarily increase the log level, then restore it afterward to avoid keeping access records longer than necessary.
3. Keep test conditions consistent: Use the same node, routing mode, and destination. Close existing connections before making a new request; an active connection won't select a new outbound immediately after a database replacement.
4. Keep a rollback plan: If the new resources prevent startup, stop the core, restore the original files or resource source, and restart to verify. Once rollback works, check new tags and resource formats one at a time.