How to Update geoip.dat and geosite.dat: V2Ray Routing Rules Guide

geoip and geosite: Know what each one matches

The routing modules in V2Ray and Xray can reference external data sets, so you don't have to list large numbers of domains and IP ranges in your configuration. geosite.dat contains labeled domain lists; geoip.dat contains labeled IP range lists. The files don't determine where traffic goes on their own. Routing takes effect only when a rule references these data sets and specifies an outbound.

geosite:cn does not mean “all domains ending in .cn.” It refers to the data set named cn in the current source, which may include domains with other suffixes. The data source determines which domains are included. Likewise, geoip:cn matches IP ranges listed in the data file; it does not check a website's language or independently determine where its business is based.

An outdated rule database may miss newly added domains or changed IP ranges, but old files aren't the cause of every routing problem. The destination domain may be unavailable, an earlier rule may already match, or the current routing mode may not use this configuration—all of these can make an update appear ineffective. Note what happens before updating; this is more useful for troubleshooting than repeatedly swapping files.

Update Geo data files in v2rayN: check the core first

v2rayN is a management interface; the core it starts is what reads the rule database. The .dat instructions in this guide apply to V2Ray and Xray. If your current setup uses another rule data format, don't assume the file path is the same just because you're using the same client. Check the core name and configuration path in the startup logs before updating.

1. Note the current setup

   On the main screen, note the current server, system proxy status, and routing mode. Save your existing routing settings; if you use a custom configuration, keep a recoverable copy. While troubleshooting, don't change both the server and routing mode at the same time.

2. Find the update option

   In v2rayN builds that provide this option, open “Check for updates” → “Update Geo files.” The menu location and wording may vary between builds. If you don't see it, check the update menu in your current interface; “Update subscription” is not a substitute.

3. Wait for confirmation

   Check the update result or logs to confirm that both required data files have finished downloading. If the operation times out, first check that the update source is reachable. If the updater offers a proxy option, retry through a proxy you've verified works; don't keep clicking repeatedly.

4. Reload the core

   After the update finishes, restart the current service or core. If you're not sure it reloaded, close and reopen v2rayN. Check the startup logs for errors such as missing files, read failures, or unknown categories.

5. Test the same destination again

   Keep the same server and routing mode, then reopen the destination that had the problem. Start a new connection and check the outbound in the logs; existing connections may not be evaluated by the routing rules again.

Update failed? Choose the built-in updater or replace files manually

Use the update option provided by the client whenever possible; it is more likely to put files where the current setup will use them. Don't copy someone else's absolute path: portable, installation, and user data directories, as well as custom launch methods, can use different resource paths. A file with the right name on disk doesn't necessarily mean the running core is reading it.

When replacing files manually, also check that the required categories exist. Different data sources may use the same filename, geosite.dat, but provide different labels; filters using @ also depend on the source file's contents. If you see a “category not found” error, compare the rule's data set with the source documentation instead of changing the server protocol. Keep the original file so you can quickly roll back if the configuration fails to load.

Routing with geosite:cn and geoip:cn

The routing snippet below is intended to be merged into a core configuration; it is not a complete, runnable client configuration. It assumes an existing direct outbound named direct; outbound tags must match your configuration exactly. In v2rayN's graphical routing editor, enter the domain, IP, and outbound fields using the same logic. Don't overwrite the entire configuration generated by the client.

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

IPIfNonMatch means the core first tries to match using the available destination information. If a domain request doesn't match a rule, it then resolves the domain to an IP and tries the IP rules. It does not mean “resolve every request first.” If an earlier rule already proxies all domains, matching stops there, and geoip:cn won't act as a catch-all fix.

• Use two separate rules: To send traffic direct when either the domain or IP matches the cn set, split it into two rules as shown. Putting domain and ip in the same rule does not mean either one can match; multiple condition types in a single rule must all be satisfied.
• Define what happens when nothing matches: This example does not specify a fallback proxy. When no rule matches, V2Ray/Xray typically uses the first outbound; confirm this against your full configuration. Don't assume the direct tag is the global default policy.
• Handle specific exceptions: If a site must use a proxy, put its exact-domain rule before the broader cn direct rule. Choose a matching method based on whether the rule should cover all subdomains.

Routing rules not working? Check order, domains, and DNS

Routing rules are evaluated from top to bottom, and the first match determines the outbound. The database only tells the core whether a destination belongs to a set; it can't override an earlier match. When troubleshooting, check the rule list, destination address, and outbound tag in the logs—not just whether the page loads.

1. Check the mode: Confirm that the routing mode selected on the main screen is the one you expect. Global proxy or global direct modes may bypass the split-routing rules you're editing.
2. Check the domain: If an app passes only an IP address to the proxy, a domain rule may not match. Sniffing can recover a domain from some protocols, but it doesn't cover every connection or work reliably every time.
3. Check DNS: When routing depends on an IP match, the resolved address affects the result. Traditional DNS commonly uses UDP/TCP port 53; encrypted DNS uses other transport methods. A web connection going through a proxy doesn't mean its DNS queries follow the same route.
4. Check rule order: Look for broad domain, port, or fallback rules earlier in the list. Test the outbound with an exact-domain rule first, then restore the set-based rule. This helps distinguish a data source issue from a rule order issue.
5. Test a new connection: Close the destination page or restart the test app, then try again. If necessary, enable more detailed logging briefly. Restore your usual log level once testing is complete, and don't share full logs that contain subscription URLs or destination domains.

If an exact-domain rule routes correctly but geosite:cn doesn't match, check whether that domain is actually in the current set. If the exact rule also fails, first check whether the current configuration is active, whether the outbound tag is correct, and whether an earlier rule is intercepting traffic. Downloading the rule database again is unlikely to help in that case.

Geo file update FAQ