GeoIP and GeoSite Database Update Guide: Check These Two Files When Routing Rules Fail

A node can connect normally while a site that should go direct suddenly uses the proxy, or a domain fails to match the expected rule. The cause may not be the subscription, VMess, VLESS, or the node itself. Whenever routing rules reference geoip: or geosite:, the actual match depends on the data files loaded locally.

First, identify what geoip.dat and geosite.dat match

geosite.dat stores domain-category collections. Entries such as geosite:cn and geosite:category-ads-all do not query a live online service; they instruct the core to read category entries from the local file. If a domain is added, moved, or repurposed while local data remains outdated, it may still be assigned to an old category.

geoip.dat stores IP address-range categories. A rule such as geoip:cn compares the destination IP with address ranges in the database. If a site changes its resolved address, a cloud provider reallocates ranges, or new ranges are missing from the old database, IP rules may fail to match.

Determine whether outdated databases are causing routing anomalies

Do not replace the files after seeing a single incorrect route. First confirm that the core is running normally, then rule out incorrect rule order, DNS results, and outbound tags. Routing systems generally evaluate rules in order; a broad rule near the top may capture the traffic before geosite:cn or geoip:cn ever gets a chance to run.

10808 and 10809 are common v2rayN defaults, not fixed values for every installation. Confirm the actual ports under Settings → Parameters; when testing a browser proxy, the port must match the current local inbound. A wrong port causes complete connection failure, not a Geo data misclassification.

1. Check the nodes: Test two working nodes one at a time. If every node connects but the same group of domains consistently uses the wrong outbound, the routing data or rule configuration is more likely to be at fault.
2. Check rule order: Review exact-domain, GeoSite, GeoIP, and final fallback rules from top to bottom. The final fallback must come after the category rules.
3. Check the logs: Open the runtime log in v2rayN and revisit a test domain to see which outboundTag was selected. If the log level is too low, temporarily raise it under Settings → Parameters, then restart the core.
4. Check file dates: Locate the resource directory actually used by the current core and inspect the modification times of geoip.dat and geosite.dat. Do not check only copies in the download directory.
5. Create a baseline: Before updating, record at least three test targets: one domain that should clearly go direct, one expected to use the proxy, and one request made directly to an IP address.

Update GeoIP and GeoSite in v2rayN

Recent v2rayN versions usually provide a Geo file update entry in the top menu. First connect through a node that can reliably reach the update source, then open Check for Updates → Geo files. Some versions label it GeoIP/GeoSite update; the wording may differ, but the operation still updates the two data files in the current core directory.

Do not exit the client or manually overwrite files with the same names during the update. After the menu reports completion, use Restart Service or quit and relaunch v2rayN so the Xray or V2Ray core releases the old files and loads the new ones. Closing only the main window while leaving the client running in the background may not trigger a full reload.

If the in-client update fails, you can replace the files manually. The important part is not putting them in the v2rayN root directory, but locating the resource directory used by the selected core. Directory layouts vary between v2rayN versions, desktop editions, and WPF editions; common installations contain bin subdirectories organized by core. The safest approach is to confirm the core executable path in the runtime log, then look for the two existing files with the same names in a nearby resource directory.

On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. If the current version offers an Update Geo Files entry, run it when the network is available and restart the core. If no such entry exists, update the bundled resources with the client. For routing tests, open Settings → Routing Settings to confirm the active rule set; do not rely only on whether the subscription refreshed.

Check the routing syntax and domainStrategy

If updating the databases changes nothing, check whether the configuration references them correctly. GeoSite entries belong in the rule’s domain array, while GeoIP entries belong in ip; they are not interchangeable. Each rule must also point to an existing outboundTag, otherwise the core may report an error or fail to select the expected outbound.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn",
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

The order above checks domains first, then IPs, and finally sends all remaining TCP and UDP traffic to proxy. The direct and proxy values must exactly match the tags in outbounds, including capitalization. If the configuration actually uses direct-out, the routing rule must use that same name.

• AsIs: Prefer matching the original domain in the request and do not resolve it proactively for IP rules. When the destination is supplied as a domain, later GeoIP rules may not participate.
• IPIfNonMatch: Resolve the destination address when no domain rule matches, then try the IP rules. This suits common routing setups that use both GeoSite and GeoIP.
• IPOnDemand: Resolution may be triggered earlier when a rule needs an IP address. This changes when DNS queries occur, so verify that the DNS configuration matches your expectations before enabling it.

If a program connects directly to an IP address, GeoSite cannot infer the original domain from that address, so the decision mainly depends on GeoIP. Conversely, remote DNS, built-in DNS, or special forwarding can change what the core sees. Therefore, different routing results for the same site in a browser and a command-line tool do not necessarily indicate a damaged database.

Verify the update with logs and comparison requests

Do not verify only by checking whether a webpage opens, because both direct and proxied connections can succeed. Confirm that the updated target matches the expected rule, selects the expected outbound, and produces the same result after a restart. Before each test, clear browser connections or wait for existing connections to close so connection reuse does not skew the result.

1. Record the current state: Note the modification times of both data files, the current core type, and the name of the active routing configuration.
2. Restart the core: In v2rayN, use Restart Service; on Android, stop the current connection and start it again.
3. Send requests one at a time: Test a domain that should clearly match GeoSite, then an IP address you can enter directly, and finally a target that should use the fallback proxy.
4. Read the logs: Check the destination address, matched rule, and final outbound tag—not just whether the connection was established.
5. Repeat for three rounds: Reconnect at intervals to confirm the result is not an accidental effect of DNS caching or a persistent connection.

Build a rollback-ready update routine

GeoIP and GeoSite do not need to be updated at every startup, but leaving them unchanged for too long can gradually increase classification errors. Check them when a repeatable set of routing mistakes appears, after updating the client core, or when making major changes to a routing rule set—not immediately after every network fluctuation.

• Keep the previous geoip.dat and geosite.dat versions in a separate directory that the core does not scan automatically.
• Treat both files as one release, and record the replacement date and current core type.
• Keep three fixed test targets covering direct domain access, direct IP access, and the proxy fallback.
• Make rule changes and data updates separately so you can tell which step changed the result.
• If an update fails, restore the complete backup before investigating network or directory-permission issues.

When a domain needs an immediate correction but the database does not cover it yet, add an exact-domain rule before the GeoSite rule. Use full:example.com to match one complete domain, or domain:example.com to match that domain and its subdomains. Keep exact rules manageable and review them after the database adds coverage so temporary rules do not accumulate permanently.

A complete troubleshooting sequence can be standardized as follows: confirm the node and local ports, review rule order, check Geo file dates, run the update, restart the core, read the logs, and repeat comparison requests. This sequence applies to both Xray and v2fly cores; only the resource directory and client menu location differ, not the basic matching roles of GeoIP and GeoSite.