GeoIP and GeoSite Rules: Updating DAT Files and Configuring Routing

What GeoIP and GeoSite Match

geosite.dat contains domain rules organized by category, while geoip.dat contains IP ranges organized by category. These are routing data files—not subscriptions or server configurations. Updating them does not change connection settings such as VMess or VLESS, and it does not add usable servers.

geosite:cn does not mean “domains ending in .cn only,” nor does it classify sites at runtime based on their language. It refers to the cn category in the database. Likewise, geoip:cn refers to the corresponding IP range category. The two are not interchangeable.

V2Ray and Xray deployments commonly use DAT data files. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. For v2rayN, the required data format depends on the selected core. If your active core uses a different rule format, don't assume this DAT setup will work just because the filenames look familiar.

Choose a Source and Update Method

Common data sources include v2fly projects that build domain categories and IP data, as well as community-maintained compatible rule databases. Domain lists are curated and compiled into DAT files; they are not plain text lists that you can edit directly. Check each database's own category documentation to see whether it includes cn, private, or a specific service category.

Update Geo Files in v2rayN

These steps describe the v2rayN interface with a “Check for updates” → “Update Geo files” option. In some versions, the option may be under Settings or an update menu. If you don't see it, don't guess a directory and overwrite files. Check the client help and active core logs to confirm the resource path first.

1. Record Your Current Setup

   Open “Settings” → “Routing settings” and note the active routing configuration, rule order, and default outbound. Back up the current Geo files and record the directory they came from so you can restore them if needed.

2. Check Which Core Is Running

   Check the startup log for the core name and launch parameters to confirm whether you're using the Xray or v2fly DAT format. The installation directory, working directory, and resource directory are not necessarily the same.

3. Update the Data

   Go to “Check for updates” → “Update Geo files.” Wait for the download and replacement to finish, and make sure both files were processed. If you see a network error, resolve the download issue and retry; don't treat a partial update as a complete one.

4. Restart the Active Core

   Restart the service through the client, or quit the client and reopen it, so the core reloads the files. Closing the main window may only minimize the client to the system tray; it doesn't necessarily restart the service.

5. Review the Startup Log

   Look for errors such as missing resource files, unknown categories, or configuration parsing failures. Then test a direct-connection domain, a domain that should use the proxy, and a local network address to verify routing for each.

For a manual update, stop the core first, then place compatible files in the confirmed resource directory. Keep the exact filenames geoip.dat and geosite.dat. Don't rename a downloaded webpage, archive, or file with a duplicate extension and use it as a data file. If the core fails to start after an update, restore the backup and restart, then check the new database's categories and format.

On Android, use the Geo data update or resource import options provided by v2rayNG or v2flyNG. Menu names vary by version, so don't follow the desktop file paths. An app's private directory is also different from the system Downloads folder. If you can't confirm the right option, keep your working configuration and don't clear app data just to try an update.

Routing with geosite:cn and geoip:private

The following is an example of the routing object in a native V2Ray/Xray configuration, not a complete client configuration ready to import. It assumes your existing outbound tags are direct and proxy: the first is for direct connections, and the second is for proxy connections. If your tags differ, replace them with names that already exist in your configuration.

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

• Prioritize private addresses: Use geoip:private to keep local network destinations from being sent through the proxy. This category must exist in your data source; it is not a catch-all for “all addresses that don't need a proxy.”
• Direct-connect by domain category: When a destination domain matches geosite:cn, this rule routes it directly. There's no need to check the IP category as well.
• Supplement with an IP category: geoip:cn matches known destination IPs. Whether a domain connection can be matched by IP also depends on the domain resolution strategy.
• Final fallback: This example sends remaining TCP and UDP traffic through the proxy. If the client already adds a fallback rule, don't add another conflicting rule at the end.

When editing under “Settings” → “Routing settings” in v2rayN, you usually need to enter the domain condition, IP condition, and outbound separately. Don't paste the entire JSON into the “Domain” field. Adding both domain and ip to one rule usually means both conditions must match, not either one. To route directly when either the domain or IP matches, split them into two rules as in the example.

Verify Routing with Specific Destinations

A webpage loading successfully doesn't prove that an update worked. The connection may have used the proxy fallback, an app cache, or an existing connection. Restart the core first, close existing connections in the test app, then inspect the destination and outbound for new requests. If your current log level doesn't show routing details, temporarily increase it and restore it when you're done.

The three IPv4 private ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These ranges help explain CIDR notation, but they are not the full contents of geoip:private in every database. The actual database may also include loopback, link-local, and IPv6 ranges; check the data source's definitions.

Geo files alone can't guarantee that DNS requests use the intended outbound. Traditional DNS on port 53, an app's own encrypted DNS, and the core's built-in DNS may follow different paths. If domain-based routing behaves unexpectedly, check whether the domain is preserved, your DNS settings, and the scope of TUN interception. Don't keep switching category databases to work around a DNS routing issue.

Common Update Failures and Rule-Matching Issues

For long-term maintenance, change one type of variable at a time: update the data files and verify them first, then adjust rules or DNS. Record the data source, replacement location, and local update time to create a rollback record. Update as category data actually changes; there's no need to replace a working database just to get a newer file date.