How to Update geoip.dat and geosite.dat: Using geoip:cn and geosite:category-ads

GeoIP and GeoSite: What Each One Matches

geoip.dat stores IP ranges grouped by country or other labels; geosite.dat stores domain rules grouped by label. These are data files read by the core, not server lists or subscription URLs. Refreshing a subscription updates server configurations, but does not mean the Geo files have also been updated.

geoip:cn refers to the set of IP addresses labeled cn in the database; it does not mean “all Chinese-language websites.” geosite:cn refers to a domain category, and the two sets do not correspond one-to-one. Websites may use international CDNs, and the same domain can resolve to different addresses on different networks. Treat domain rules and IP rules separately.

Update Geo Files in v2rayN

First, check whether the active node uses V2Ray or Xray, and which routing profile is enabled. v2rayN generates configurations and manages the core; the core itself reads the databases and applies routing rules. The steps below use a desktop interface with a “Check for Updates” → “Update Geo Files” option. Menu names and locations may vary by version. Updating a subscription is not a substitute for updating Geo files.

1. Note the Current Setup

   Record the active routing profile, the core used by the node, and the domain you're trying to fix. Save a copy of the routing configuration first so you can distinguish rule changes from database updates.

2. Run the Update

   In the main window, select “Check for Updates” → “Update Geo Files.” Check the interface message or logs to confirm the download finished. Clicking the menu option alone doesn't prove the files were written successfully.

3. Verify the Files

   Find the data directory used by this running client and check the modification times and file sizes of geoip.dat and geosite.dat, along with the update logs. If multiple files with the same name exist, confirm which one the core actually uses.

4. Restart and Test

   Restart the active core. If there's no separate restart option, fully quit and reopen the client. Check the logs for Geo file loading errors, then reconnect and verify that the expected outbound is selected.

If the update fails, troubleshoot based on the error: for a download timeout, check network access to the update source; for a certificate error, check the system date and time; for a write failure, check directory permissions and whether another process has locked the file. “Update via proxy” in subscription settings applies to subscription updates; don't assume it also controls Geo file downloads.

File Locations: Check the Active Instance and Core Logs

Don't replace files based on a single path found online. Portable folders, installation directories, user data directories, and different package layouts can all vary. If two copies of v2rayN are installed, updating files in the old directory won't change the data used by the active instance.

For example, in Windows PowerShell, you can run the read-only search below from the confirmed client directory. It only lists files in that directory tree and won't overwrite anything. If resources are stored in the user data directory, search there separately.

Get-ChildItem -Path . -Recurse -File -Filter '*.dat' |
  Where-Object { $_.Name -in @('geoip.dat', 'geosite.dat') } |
  Select-Object FullName, Length, LastWriteTime

When managing the core manually, also check resource-directory environment variables, such as V2Ray's V2RAY_LOCATION_ASSET or Xray's XRAY_LOCATION_ASSET. If the client manages the core, don't add these variables casually; they may cause the core to bypass the directory you just updated. Manual replacement only makes sense once you've confirmed how the core starts and which path it actually reads.

Rule Examples: Block Ads, Bypass the Proxy for Domains and IPs

The following is a routing snippet for a V2Ray/Xray configuration, not a complete client configuration you can run as-is. It shows three rules: send the ad category to a blocking outbound, and send domestic domains and IPs to a direct outbound. Before using it, check the actual outbound tags. block and direct are example tags here; adding them to a rule does not create those outbounds.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

• Put the ad rule first: Rules are evaluated in order, and the first match determines the outbound. If a broad direct rule comes first, the ad rule below it may never handle the connection.
• Use separate domain and IP rules: Adding both domain and ip to one field rule does not simply mean “match either one.” To send traffic direct when either condition matches, create separate rules.
• Use a configured blocking outbound: block must point to a defined blocking outbound, such as one using the blackhole protocol. The direct tag must point to a freedom outbound. Use the names shown in the generated configuration.
• Set a default outbound: This snippet doesn't specify what happens to unmatched traffic. V2Ray/Xray typically uses the first outbound for unmatched traffic, so check the outbound order or fallback rules in the configuration generated by the client.

In v2rayN's routing editor, use geosite:category-ads for the domain condition and geoip:cn for the IP condition. Don't paste the entire JSON object into a single condition field. After saving, make sure this profile is the active routing profile. See the complete configuration guide for how the fields fit together.

Domain Strategy: Why an IP Rule Didn't Match

The example uses AsIs, which means the routing stage won't resolve a domain just to check it against an IP rule. If a connection already provides an IP address, it can still match geoip:cn. But if it provides a domain that doesn't match a domain rule, don't assume it will fall through to the domestic IP direct rule.

If an app connects directly to an IP address, GeoSite may not have a domain to match. Sniffing can extract domains from some protocol traffic, but it can't recover a domain from every connection; the app's transport and encryption also affect the result. Updating geosite.dat alone won't fix a routing problem where there's no domain to match.

Still Not Working After the Update? Narrow It Down with Logs

Don't verify the change solely by checking whether a webpage opens. Record a test domain, the expected outbound, and the time of the request, then review the core logs for that period. The detail shown depends on the current log level; temporarily increase it if needed, then restore it when you're done. Avoid sharing complete logs that contain subscription URLs or credentials.

Ongoing Maintenance: Update Databases and Rules Separately

Updating a database changes which items belong to each category; updating routing changes conditions, order, and outbounds. Both can affect routing results. Change one variable at a time to pinpoint whether an issue comes from changed data, rule precedence, or DNS resolution differences. You don't need to replace every file manually after each subscription refresh.

• Keep a backup before changing anything: Save the working Geo files and routing configuration, and note the data source and update date so you can roll back if something goes wrong.
• Check startup after updating: First confirm that the core loads the files successfully, then test the expected direct, proxy, and block results—not just a single webpage.
• Start fresh connections: Existing connections may continue using their original route. Restart the core and make new requests to get a clearer view of the updated configuration.
• Desktop and Android differ: v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Their data management options and resource directories differ, so don't reuse desktop file paths.

If the client won't start or the network connection drops, restore the last working configuration first, then troubleshoot each setting separately. For common connection issues, see Troubleshooting. Geo data is only one part of routing; traffic capture, rule order, DNS strategy, and outbound tags all determine the final connection path.