How to Update geoip.dat and geosite.dat: A Guide to Routing Databases

GeoIP vs. GeoSite: IP address matching vs. domain matching

geoip.dat stores IP ranges grouped by country, region, or special purpose. geosite.dat contains domain rules organized by region, service, or use case. These are binary data files read by the core—not server lists or JSON configuration files you can edit in a text editor.

geosite:cn reads the cn category in the current domain database; it does not mean “every domain ending in .cn.” Likewise, geoip:cn is a set of IP ranges recorded in the database, not a way to identify a site's language or provider. A Chinese-language site may use an overseas CDN, while an international service may resolve to an IP address in mainland China.

v2rayN manages subscriptions, generates configuration, and starts the core; the core actually reads these rules. The DAT examples here apply to Xray and V2Fly configurations that use the corresponding Geo data mechanism. On Android, v2rayNG uses Xray and v2flyNG uses V2Fly, but their menus and file storage work differently from the desktop steps in this guide.

Before updating: distinguish subscriptions, routing rules, and Geo data

Updating a subscription mainly changes server addresses, ports, protocol settings, and the node list. Updating Geo files changes category data; editing routing rules determines which route each category takes. These are separate operations. Updating a subscription does not refresh geosite.dat, and replacing a database does not automatically add a direct-routing rule.

Different data projects may include different categories, even when they all produce a geosite.dat file. A database that recognizes cn may not include other categories referenced by your routing template. When switching sources, check whether the category exists separately from whether the file downloads successfully.

Update Geo files in v2rayN: follow these five steps

These steps apply to desktop versions of v2rayN with a “Check for updates” menu. Menu layouts may vary by version. If you don't see “Update Geo files,” first check where resource updates are managed in your version; “Update subscription” is not a substitute. Keep a working copy of your current configuration before you start, and avoid changing nodes, DNS, and routing at the same time.

1. Record your current configuration

   Check the current node, core, and enabled routing configuration, and note any custom rules. To check the local listening port, open Settings → Parameter settings and look for the local listener options. Don't assume every installation uses port 10808.

2. Update the resources

   In the main window, open “Check for updates” → “Update Geo files.” Watch the client status until the download finishes. If your version lists separate resource tasks, check the results for both GeoIP and GeoSite.

3. Troubleshoot download failures

   If the request times out, check the system clock, resource URLs, and current node availability first. Whether the updater uses a proxy depends on the client implementation and settings; enabling the system proxy does not guarantee that every update request will go through it.

4. Reload the configuration

   After a successful update, restart the core. If you can't find the relevant option in the interface, close and reopen the client. Files being saved to disk doesn't mean the running core has reloaded them; check the startup logs for resource-loading errors.

5. Verify the routing results

   Keep your existing routing settings and test one domain expected to connect directly, one expected to use the proxy, and one LAN address. Check the route labels in the connection logs instead of relying only on whether a webpage loads.

After replacing files manually, check read permissions and verify the file contents. A failed download may save an error page instead of the database. Even if the file is still named geoip.dat, the core won't be able to parse it as a database. If parsing fails, restore the backup first, then fetch the resource again.

Writing rules: where to use geosite:cn and geoip:private

The routing snippet below is for illustration, not a complete runnable configuration. It assumes outbounds contains a direct outbound tagged direct, and that the default outbound is a proxy. If no rule matches, Xray and V2Fly usually use the first outbound, so check the outbound order as well.

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

• Rule 1: geoip:private matches the private address ranges in the database. It does not mean “all intranet domains,” and different sources may not include exactly the same special-purpose ranges.
• Rule 2: geosite:cn matches a set of domains. The request must include a domain, or a suitably configured sniffing mechanism must provide one, for this kind of matching to work.
• Rule 3: geoip:cn matches based on the destination IP. If the request already contains an IP address, it can be checked directly. Whether a domain request is resolved first depends on domainStrategy.
• Outbound tag: direct is just a tag name and must match an actual outbound in the configuration. A newer database can't fix a configuration that refers to a nonexistent tag.

IPIfNonMatch means the core tries resolving the IP and matching it if the domain doesn't match any existing rule. If you add a catch-all rule at the end that directly matches all TCP and UDP requests, the domain stage may already match, preventing the expected IP-based fallback. Don't use this strategy while assuming every request will be checked against GeoIP.

Routing is still wrong after updating? Verify these four layers

A website loading only proves that a connection succeeded; it doesn't prove that traffic took the intended route. To verify Geo data, keep the node, routing rules, and test target fixed, and change only one variable at a time. Check the four layers below in order—this is usually more effective than repeatedly switching databases.

1. File layer: Check the update time, actual resource path, and startup logs. If the file is missing, can't be read, or fails to parse, fix resource loading before changing routing rules.
2. Rule layer: Check that referenced categories exist, the active routing configuration is correct, and no earlier rule is already capturing the traffic. Rules are evaluated from top to bottom; the first match takes effect.
3. Domain layer: Confirm whether the core receives a domain or an IP address. Browser-side DNS resolution, apps connecting directly to an IP, and different TUN setups can all change what information is available for matching.
4. Outbound layer: Check the outbound tag in the connection logs. If the current log level doesn't record matching details, temporarily adjust the logging settings. If the route is correct but the connection is slow, investigate the node and network path instead.

If your local SOCKS inbound is listening on 127.0.0.1:10808, use the command below to test through that specific entry point. socks5h sends the domain to the proxy for resolution, helping preserve domain-based matching. This only tests the request path; it does not by itself prove that a particular GeoSite category matched.

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com/

The port shown is an example and must match the client's actual listening port. If the connection is refused, first check the port and whether the core is running. If the request succeeds, check the logs for that time to identify the outbound. When testing a LAN target, distinguish between “the rule selected direct” and “the target service allows access”—they are not the same thing.

FAQ: missing categories, ineffective updates, and update frequency

Keep a simple maintenance log: when you updated, which source you used, whether you changed the routing template, and whether everything worked after restarting. Geo data provides the categories, rules choose the outbound, and DNS and inbound settings determine what information is available for matching. Keeping these layers separate makes it easier to decide whether to update files, adjust rules, or check whether the app is actually routing through the client.