How to Update geoip.dat and geosite.dat: Routing Rule Data and Syntax

1. What GeoIP and GeoSite Match

geosite.dat contains domain rules organized by tags, while geoip.dat contains IP ranges organized by tags. These are binary data files read by the core—not server lists or DNS servers. Updating a file changes the entries in its sets; it does not automatically change where a rule sends traffic.

A connection may reach the core with a domain name, or with only a destination IP. Domain rules require the core to have the domain; IP rules require the destination address, or DNS resolution during routing. Being able to open a website does not mean both domain and IP sets were involved in the match.

For example, a local network address such as 192.168.1.1 can be matched directly against an IP range. A domain may be included in geosite:cn yet resolve to an overseas CDN. The two databases describe different properties and cannot replace each other.

2. Data Sources and Tag Compatibility

Common sources include V2Fly’s domain-list-community, GeoIP data projects, and rule data builds maintained by projects such as Loyalsoldier. Source projects may publish text lists, while the build artifacts are the .dat files the core actually reads. Don’t rename a webpage or raw domain list to geosite.dat.

Files with the same name don’t necessarily contain the same tags. The cn tag is common, but service-specific, ad-blocking, and attribute-based sets may be available only from certain sources. Referencing a missing tag can prevent the core from loading the configuration—not just disable one rule.

• Check the format first: The geosite:, geoip:, and JSON examples in this guide use Xray/V2Fly routing syntax. Don’t copy them unchanged into other rule formats.
• Then verify the tags: Check the categories published by the data source; don’t assume a category exists based on its name.
• Keep a restore point: Back up both existing files and your routing configuration before updating. When switching sources, check the data files and rules together.

3. Update Geo Files in v2rayN

On desktop, first check whether the active configuration uses the Xray or V2Fly core, then update the corresponding data files. The steps below use a v2rayN interface with an “Update Geo files” option. Menu locations may vary by release; different labels don’t mean the files are corrupt.

1. Back up your routing setup

   Open “Settings” → “Routing settings” and note the active routing profile and any custom rules. If you manage Geo files manually, copy the original files to a backup folder as well.

2. Update the data

   In the main window, open “Check for updates” → “Update Geo files.” Wait for the result and check the status of geoip.dat and geosite.dat separately. A node subscription update notice does not confirm that the rule databases were updated.

3. Check the logs

   Review the main window’s log or message panel. If the download fails, check network access and the source URL. If a tag can’t be loaded, verify the tag name and data source instead of deleting the entire routing setup.

4. Reload the data

   Stop and restart the current connection through the client so the core reloads the files. If the client already restarted as part of the update, check the startup log for Geo file loading errors.

5. Test the rules again

   Keep the same server, proxy mode, and DNS settings; change only the data files, then test the same destinations. This isolates the effect of the update from other configuration changes.

In v2rayNG and v2flyNG, first check “Routing settings” in the side menu to review the active rules and available data update options. Menus vary between Android client versions. If there’s no dedicated Geo update option, follow that version’s instructions for importing files or updating resources; don’t use desktop directory paths. Updating a subscription mainly refreshes server details, so it doesn’t confirm that Geo data was refreshed.

4. Writing Rules with geosite:cn and geoip:private

The following example uses the Xray/V2Fly routing object. It sends private addresses direct first, then checks domain sets, and finally uses the China IP set as a fallback. Tags must exist in the installed data files. Rules are checked from top to bottom, and the first match determines the outbound.

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

Multiple different conditions in a rule usually all have to match; multiple options in the same array match any one of them. If you want direct routing when either the domain is in cn or the IP is in cn, split them into two rules as shown. Putting both fields in one rule won’t make them work as an “OR.”

5. How domainStrategy and DNS Affect Routing

routing.domainStrategy controls how domain resolution is handled during routing; it is not the DNS configuration for the entire client. Don’t confuse it with similarly named settings on an outbound: routing decides which outbound to use, while the outbound determines how to establish the connection.

• AsIs: The routing stage does not resolve domains to check IP rules. Requests that already have a destination IP can still match IP rules, but don’t expect every domain to trigger a GeoIP check.
• IPIfNonMatch: If a domain doesn’t match a rule, the core tries to resolve its IP and continue checking. If the domain already matched an earlier rule, it usually doesn’t need to resolve the domain for that routing decision.
• IPOnDemand: Resolution can be triggered as soon as a rule requires an IP check. Putting IP rules first may cause more domain requests to trigger DNS lookups during routing.

That’s why the example uses IPIfNonMatch: it checks known domain sets first and tries IP classification only for unmatched destinations. The DNS lookup path also depends on DNS servers, query rules, and connection settings; updating these two data files alone won’t fix DNS pollution or timeouts.

6. Manual Replacement, Verification, and Common Errors

If automatic updates fail, you can manually obtain both build files from the same maintained source. Stop the core before replacing them, find the resource directory the active core actually reads, keep the exact file names, and restart the core afterward. Installed desktop versions, portable builds, and Android apps use different resource locations; there is no universal directory path.

1. Verify the file location: Check the client’s directory documentation, resource settings, or logs. A file with the right name in the program folder doesn’t prove the running core reads it.
2. Verify the download: The file shouldn’t be empty, a login page, an error page, or an archive. If your system hides extensions, make sure it hasn’t been saved as geosite.dat.dat.
3. Verify startup: After restarting, check for errors such as missing files, data parsing failures, or unknown set tags. If startup fails, restore the backup before making further changes.
4. Verify actual routing: Make sure the app is using the client’s proxy, then visit a local network destination, an expected direct-connection destination, and an expected proxy destination. Check the outbound tags in available access logs.