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

Two .dat files: one matches domains, the other IP addresses

geosite.dat contains domain lists organized by region, purpose, or service. geoip.dat contains IP address ranges grouped by labels such as region. In routing rules, geosite:cn looks up a domain list, while geoip:cn looks up an IP list; they are not interchangeable. The databases define what each list contains, while routing rules decide which outbound connection handles a match.

For example, when a browser passes a domain to the local proxy, a domain rule can match it directly. If an app passes only a destination IP to the proxy, the domain database may never come into play. Sniffing can provide domain information for supported traffic, but it cannot recover the original domain for every connection. Updating geosite alone won't help if an app never provides a domain.

Update in v2rayN: back up first, then check the update log

Use the Geo update option built into the client whenever possible. In many desktop versions, the path is “Check for Updates” → “Update Geo Files”; some interfaces shorten this to “Geo Files.” Menu locations and labels can vary by version and interface, so look for a Geo option in the update menu—not “Update Subscription” or an app update option.

1. Keep your current configuration

   Note the active core, routing preset, and Geo data source first. If you need a local copy of the configuration, close the client before copying its actual configuration directory. Don't treat files that are still being written as a reliable backup.

2. Update the databases

   Choose “Check for Updates” → “Update Geo Files” and wait for the task to finish. Check the output for updates to both geoip.dat and geosite.dat; don't close the window just because the download progress has stopped.

3. Verify the update

   Check the log for success or failure, then check the modification time and size of the files in the actual data directory. A file's presence doesn't mean its contents are usable, and a changed timestamp doesn't mean the core has reloaded it.

4. Reload the core

   Restart the active core through the client, or fully quit and reopen the client. Then check the startup log for file read errors, missing categories, or routing configuration errors.

5. Test routing

   Test one site that should connect directly, one that should use the proxy, and a LAN service you actually use. Keep the same node, routing preset, and proxy mode so you don't change multiple variables at once.

If the update times out, first confirm that your current network can reach the data source configured in the client. If the interface offers a download-through-proxy option, select a node you've verified works and try again. If there is no such option, don't assume that enabling the system proxy will fix it; whether update requests use the system proxy depends on the client. Check whether the error is a connection timeout, a permissions issue, or a data loading failure before deciding what to try next.

Choosing an update method: use the built-in updater first; replace files manually for troubleshooting

Don't guess the file location based on a fixed directory in a tutorial. The installation method, operating system, and client version can all affect where resources are stored. Confirm the path the core reads by checking the client settings, startup logs, and actual file locations. Finding a .dat file next to the main program doesn't mean the running core is using it.

• Use a compatible format: The .dat rule syntax in this article is for Xray and V2Fly. Other resource formats can't be used just by changing the file extension.
• Use a consistent source: Get both files through the same trusted maintenance process to reduce troubleshooting caused by inconsistent category conventions.
• Roll back on failure: If the core won't start after replacement, restore the last working files and inspect the specific error. Don't reinstall the client, switch nodes, and change DNS all at once.

Routing rules and order: specific matches first, catch-all last

Common field-based routing rules in Xray and V2Fly are evaluated in order; the first match determines the outbound connection. Put a rule covering all TCP and UDP traffic at the top, and later rules for direct connections to destinations in mainland China may never take effect. The five-rule example below prioritizes private addresses, sends domains in mainland China direct, then does the same for IPs in mainland China, with proxy as the final fallback.

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

Here, direct and proxy are example outbound tags, not keywords automatically created by the core. A complete configuration must define outbounds with those exact names. Client-generated tags may differ, so use the ones in your active configuration. Don't paste the entire JSON into a field that accepts only a single rule, or overwrite v2rayN's generated runtime configuration; it may be regenerated the next time the client starts.

• Prioritize private addresses: Give LAN destinations a chance to connect directly first. This does not replace system routing, firewall rules, or TUN exclusions.
• Keep domain and IP rules separate: Put geosite:cn in the domain array and geoip:cn in the ip array.
• Don't accidentally require both conditions: When a field rule includes different conditions such as domain and IP, they usually all have to match. If you need “domain or IP,” use two separate rules.
• Put custom exceptions first: If a site must use the proxy, place its specific domain rule before broad rules for direct connections to destinations in mainland China.

DNS and rule databases: updated files don't always change the result

domainStrategy determines how domains are handled during routing; it is not a complete DNS configuration. AsIs does not actively resolve domains for IP-based routing matches. IPIfNonMatch attempts resolution when no domain rule matches, then continues evaluating rules. IPOnDemand resolves a domain when an IP is needed during matching. The latter two involve trade-offs around resolvers, network access, and privacy, so don't choose based only on whether sites in mainland China connect directly.

When deciding whether a site should connect directly, don't use the IP's region as the sole indicator of where the site belongs. Content delivery networks can resolve the same domain to different addresses on different networks, and databases have their own update cycles. For sites with specific requirements, a more precise domain rule is usually easier to maintain than repeatedly adjusting regional rules.

1. First, check whether the connection enters the core as a domain or an IP address, and confirm that the app is actually using the proxy.
2. Next, check the destination and outbound tag in the routing logs. Temporarily increase the log detail if needed, then restore the original level when you're done.
3. Finally, check DNS resolution and database categories. Don't rely only on the browser's displayed exit IP to judge every resource request.

Still not working after an update? Troubleshoot by error type

Update as needed; there's no need to do it before every connection. Refresh the data when changing sources, finding a missing category, or troubleshooting unexpected routing. Subscription updates manage node details, Geo updates manage rule lists, and routing edits control where traffic goes. Keeping these separate makes troubleshooting more useful. To check routing fields, see the routing configuration reference. If the connection itself fails, start with connection troubleshooting to verify the basic connection.