V2Ray GeoIP and GeoSite Rules: Updating Databases and Configuring Routing

GeoIP vs. GeoSite: What They Match

geosite.dat stores domain collections organized by tag, while geoip.dat stores IP address ranges organized by tag. These files provide routing match data; they are not node subscriptions and do not establish VMess or VLESS connections. Updating the rule databases won't add servers or change the authentication details in your subscription.

geosite:cn generally matches China-related domains included by the data source, while geoip:cn matches the corresponding IP ranges. These rules aren't interchangeable: a domain may use a CDN spanning multiple regions, and one IP can host multiple domains. Configure domain and IP rules separately.

The rule database only supplies data for the third step. If an app isn't using the system proxy or TUN, its connections won't enter the routing flow just because the files were updated. GeoSite can't identify a website by name when a connection has only an IP address and no domain. Whether sniffing can recover the domain depends on the traffic protocol and client settings.

Before You Update: Check the Core, Source, and Backups

v2rayN is the client; V2Ray/Xray is the core that handles connections. This guide covers the DAT rule databases used by these cores. If you switch to a configuration that uses another rule format, similar filenames don't mean the files are compatible. Check the active core and startup logs first, then identify which files need updating.

1. Document the current setup. Note the v2rayN version, active routing preset, domain resolution strategy, and resource path shown in the core logs. Don't rely on the location of the app shortcut.
2. Back up your routing rules. In Settings → Routing Settings, note the enabled rules and their order, especially custom direct, block, and proxy rules.
3. Back up the data files. Locate the active geoip.dat and geosite.dat files and copy them to a separate backup folder. Don't give a backup the same name as a file currently in use.
4. Check the source. Prefer the rule database source already configured in the client. Before switching sources, check its documentation to make sure it includes all the tags used by your existing rules.

Updating a subscription, updating the client, updating the core, and updating the rule database are four different tasks. A subscription update primarily refreshes node details; a client upgrade may include resources, but that doesn't prove the active rule database was updated. Change one category at a time when troubleshooting so you can tell whether the cause was a node, a rule, or a data source.

Update the Rule Database: Client Options and Manual Replacement

Use v2rayN's built-in updater when possible. In many desktop versions, Check for Updates includes an Update Geo Files option; menu labels can vary by version and interface. If you don't see it, check the documentation for your version. Update Subscription is a separate operation.

1. Make sure your current network can reach the configured resource download URL. If the updater offers downloading through a proxy, verify that your current node works before choosing that option.
2. Run the Geo file update and check the download results in the logs. If one operation updates multiple files, verify each file's status rather than relying on the final message alone.
3. Restart the core after the update. If you aren't sure how to restart it independently, exit v2rayN normally and reopen it. Minimizing it to the system tray doesn't restart the core.
4. Reconnect and check the startup logs for file read failures, missing tags, or routing initialization errors. Then verify the routing results.

Manual Replacement: Find the Active Resource Directory First

Manual updates can help when the built-in download fails or you need a specific data source. Stop the core, obtain DAT files from a trusted rule-data publisher, and place them in the resource directory the core actually reads. Keep the filenames as geoip.dat and geosite.dat. Extract archives before use; a web page saved with a DAT extension isn't a valid rule database.

• Don't assume a fixed path: portable and installed versions, as well as different platforms, may use different data directories. A machine may also have multiple copies of the client.
• Check the environment when running the core independently: Xray can use XRAY_LOCATION_ASSET to set the resource directory, and V2Ray can use V2RAY_LOCATION_ASSET. When the client launches the core, use the environment it provides.
• Keep a rollback path: if you update both files and something goes wrong, restore the same set of backups and restart the core. This avoids the confusion of mixing files from different sources.

File modification times are only a clue; they don't prove that the new data was loaded. If routing behavior doesn't change after an update, first check whether you replaced a different copy, then confirm that the core actually restarted. Don't overwrite the same directory with files from multiple sources in succession; you'll lose useful troubleshooting evidence.

v2rayN Routing Settings: Fields and Rule Order

Go to Settings → Routing Settings, select the routing profile you want to use, then edit or add rules. Common rule editors include Domain, IP, and outbound selection fields; the layout depends on your version. Enter geosite:cn in the domain field and geoip:cn or geoip:private in the IP field. Don't paste all three into the domain field.

V2Ray/Xray checks rules in order; the first matching rule determines the outbound. Put specific exceptions that need priority before broader collections. For example, if a domain belongs to a direct-route collection but should go through the proxy, place its dedicated proxy rule before the collection's direct rule. example.com in the table is a reserved example domain used only to illustrate exact-match syntax.

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

When a rule includes different conditions, such as both a domain and an IP, they generally all have to match; this doesn't mean “match either the domain or the IP.” Use separate rules for direct routing by domain and by IP. Another common mistake is confusing domain:example.com with full:example.com: the former matches the domain and its subdomains, while the latter matches only the exact domain.

Domain Resolution Strategy: When GeoIP Is Used

domainStrategy controls how routing handles domain destinations; it isn't a DNS server address setting. Requests already addressed to an IP can be matched against IP rules directly. For requests that include a domain, whether the domain is additionally resolved for IP-rule matching depends on the selected strategy.

• AsIs: Routing doesn't proactively resolve domains for IP-rule matching. This suits configurations that rely mainly on domain rules, but a domain request won't trigger resolution just because a geoip:cn rule exists.
• IPIfNonMatch: If a domain doesn't match any rule, the core then tries to resolve it and match by IP. The excerpt above uses this strategy to check domain collections first, then consider the IP's geographic classification.
• IPOnDemand: Resolution can be triggered as soon as a rule requires an IP during matching. Because resolution happens earlier, check how rule order and DNS responses affect behavior.

If you add a catch-all rule near the end of an IPIfNonMatch configuration, the domain may match before resolution is triggered, so the expected “resolve after no match” behavior might not occur. The strategy name alone doesn't guarantee GeoIP matching; check the complete rule list. CDN IPs returned by DNS can also vary, causing the same domain to match different IP collections on different networks.

These ranges are useful examples for understanding geoip:private, not a complete list of everything in the collection. It may also include other special-purpose addresses. LAN access also depends on TUN routing, the system firewall, and permissions on the destination device; not every connection failure is caused by GeoIP.

Verify and Troubleshoot: Check the Match Before Changing Rules

For testing, choose a domain expected to go direct, a destination expected to use the proxy, and a LAN service you have permission to access. Make sure the test app actually uses the client proxy, then check the connection logs for the destination and outbound tag. Lower latency or a successfully loaded page alone doesn't prove the rule matched correctly.

1. Save and enable the updated routing profile, then make sure the previous preset hasn't been reselected.
2. Start a new test connection. Existing browser connections may keep using the previous outbound; close and reopen the test page if needed.
3. Temporarily increase the log level if needed, then check the destination domain, IP, and outbound. Restore your usual log level when done to avoid accumulating detailed browsing records.
4. Change one variable at a time: adjust rule order first, then the resolution strategy, and only consider switching data sources last.

A stable setup is one you can trace: record the data source, update date, rule order, and resolution strategy. Keeping the rule database current can add or update collections, but it won't fix an incorrect outbound selection or replace checks of DNS and the system proxy. For basic client setup, see the Quick Start. For routing and DNS terminology, consult the Glossary.