GeoIP and GeoSite Database Updates: Rule References, Load Checks, and Rollback

First, understand what GeoIP and GeoSite match

GeoIP and GeoSite are both classification databases read by the routing module, but they operate on different inputs. GeoIP matches destination IP addresses, such as geoip:private or geoip:cn in a rule. GeoSite matches domain names, such as geosite:cn and geosite:category-ads-all. GeoIP cannot directly determine a domain category, and GeoSite does not replace IP-range matching.

The common filenames are geoip.dat and geosite.dat. These files are only containers for classification data; rules reference the tags inside them. Different data sources, build dates, or slimmed-down variants may include different tags, so a successful download does not mean every tag used by the current rules is available. Before updating, record the tags you actually use instead of looking only at the file date.

This sequence does not necessarily occur in full every time. In Xray routing, for example, domainStrategy set to AsIs generally applies raw-domain rules first and does not actively resolve the domain for GeoIP matching. IPIfNonMatch attempts resolution when no domain rule matches, then continues with IP rules. IPOnDemand may trigger resolution when a rule requires the destination IP. If routing changes after a database update, check the strategy and rule order together.

Save three types of rollback data before updating

Updating Geo data normally does not change VMess, VLESS, TLS, or REALITY node parameters, but it can change which routing tags are available and what they classify. The safe approach is to save the current rules, data files, and core information before replacing anything. That makes it possible to tell whether a failure comes from the rules, the data, or a core change.

In v2rayN, open Settings → Routing settings first, then record the enabled rule sets, rule order, and default outbound. Check the active core type on the main screen. With Xray, data files in an extracted installation are commonly stored in the relevant core resource directory. Directory layouts can differ between v2rayN 7.x builds, so follow the resource path shown in the startup log or the directory selected by the client instead of overwriting another core's files based on a similar filename.

1. Export or copy the routing configuration: Preserve the active rule order, especially LAN direct connections, blocking rules, specified domains, and the final fallback rule.
2. Copy the existing data files: Place geoip.dat and geosite.dat in a dated local backup folder so they do not get mixed with the new files.
3. Record the core and client state: Note whether the current core is Xray or v2fly, whether it started normally before the update, and whether the test node was reachable.
4. List custom tags: Search the routing configuration for geoip: and geosite:, and record uncommon tags separately.
5. Update one resource set at a time: Do not replace the core, subscription, DNS settings, and Geo data simultaneously, or it will be difficult to identify the cause of a log error.

On desktop, copy the files after stopping the core to avoid replacing them while they are being read. On Android, v2rayNG and v2flyNG usually manage their resource directories themselves, so there is no need to search for files inside the system sandbox. Use the in-app Geo resource update or import option first, and export custom configuration before making changes. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Their support for basic geoip.dat and geosite.dat rules is similar, but that does not mean every extended tag and configuration field is identical.

Check rule tags, order, and core compatibility

The most common Geo data compatibility issue is not that the file cannot be read at all, but that a custom tag is missing from the new data. Basic tags such as geoip:private are common, while region, service-category, and extended-attribute tags depend on the dataset. If the rules came from an older configuration or another data source, confirm before updating that the new files still provide the same tags.

Rule order matters just as much. Routing usually checks rules in sequence, so a broad rule near the top can override a more specific rule below it. For example, if a wide-ranging GeoSite category comes before a direct-connect rule for one domain, the latter may never run. For critical domains, place explicit exceptions before broad categories and keep a final fallback outbound.

The following is a shortened routing snippet for understanding the structure. When importing it into v2rayN, outbound tags must match the tags in the current configuration. If the client uses different names, use its existing values rather than copying this example mechanically.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:intranet.example"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

Here, domain:intranet.example is an explicit domain rule that does not depend on GeoSite data, making it useful as a safeguard for a critical internal service. If a new GeoSite file lacks a business category, temporarily convert a small number of essential domains to explicit rules to restore basic access. Then decide whether to find compatible data or redesign the categories. Do not delete all routing rules at once because of a single missing tag.

• The tag exists but does not match: Check whether the domain has already been resolved to an IP, whether an earlier rule handled it, and whether sniffing can provide the destination domain.
• The tag does not exist: The core will usually report a missing classification list during startup. Restore the old file or switch to tags that are actually included in the new data.
• GeoIP is not taking effect: Check whether the destination is still entering routing as a domain and whether domainStrategy allows IP matching to continue.
• All traffic uses the same outbound: Check the default rule, final fallback rule, and outbound tags; the problem may not be caused by the Geo files.

Use startup logs to confirm that files and tags loaded

To determine whether an update succeeded, fully stop the old core and start it again instead of merely closing the settings window. The core usually reads Geo data at startup or when a referenced tag is first parsed. If the old process is still running, current connections may continue using the old resources even after the files on disk have been replaced.

In v2rayN, stop the service, restart the selected configuration, and watch the first 30 seconds in the log window. If the test environment uses the local SOCKS port 127.0.0.1:10808, first confirm that the inbound listener started successfully, then check for Geo-related errors. If the core failed to start because the port is occupied, subsequent routing tests are meaningless. 10808 is only the port used in this guide; use the local listener configured under Settings → Parameters.

Error messages can vary slightly between core versions, but the diagnostic order is the same: find the first fatal error in the log, then determine whether it points to a file path, tag name, or configuration field. Later connection failures are often just a consequence of the core failing to start. Search for geoip, geosite, routing, failed, and the specific tag name.

Roll back through files, rules, and the core when an update fails

The goal of a rollback is to restore the last known-good state quickly, not to keep making changes while the system is failing. Stop the core first, move the new geoip.dat and geosite.dat out of the resource directory, and put the backup files back. After restarting, if the original rules work again, the issue is narrowed to the new data or tag compatibility.

If the problem remains after restoring the old data, restore the routing configuration exported before the update, paying particular attention to rule order, domainStrategy, and outbound tags. If both the data and rules are restored but the core still cannot start, check whether the Xray or v2fly core was also changed during the update. Record the client version, core version, and data files separately so three variables are not combined into one update.

• Layer 1: Restore the data files. Use this for missing files, missing tags, or a sudden change in classification results after an update.
• Layer 2: Restore the routing rules. Use this when changing tags or rule order causes all traffic to connect directly, use the proxy, or lose access to the LAN.
• Layer 3: Restore the original core selection. Use this when the core was changed during the update and the log reports incompatible configuration fields.
• Layer 4: Return to a minimal rule set. Keep only LAN direct access and the final proxy outbound, confirm basic connectivity, then add Geo rules back one at a time.

Once connectivity is restored, establish a regular maintenance routine: back up both data files and the routing configuration before an update; afterward, check the local port, the first log error, and three fixed test targets; delete temporary backups only after everything is confirmed. Geo data does not need frequent replacement just because the date changed. Update it when the rules genuinely depend on new address ranges or domain classifications.