How to Update GeoIP and GeoSite Rules and Configure Routing

At a glance

This guide is for users who have imported nodes and are ready to fine-tune routing. First, understand the difference between IP and domain databases. Then update the files your client actually loads and test the results with a minimal set of rules. The examples use the traditional V2Ray/Xray JSON routing syntax. When configuring v2rayN through its interface, map each field to the corresponding routing editor option—don't paste the code into the subscription URL field.

GeoIP vs. GeoSite: Matching IPs and Domains

geoip.dat contains IP ranges organized by tag, while geosite.dat contains domain rules organized by tag. Both are data files read by the core; neither is a node subscription or a proxy protocol. Updating them won't change the server address, user ID, or transport settings of a VMess or VLESS node.

GeoIP: IP Range Collections

Default filename: geoip.dat
Routing field: ip
Common syntax: geoip:cn
Private IP tag: geoip:private

Whether a tag is available depends on the file's source. Geographic classification also doesn't indicate where a website's operator is based.

GeoSite: Domain Rule Collections

Default filename: geosite.dat
Routing field: domain
Common syntax: geosite:cn
Domain syntax: full:example.com

A domain collection may include suffixes, full domains, or regular expressions. It isn't simply a list of domain suffixes.

geosite:cn loads the cn collection from the current domain database; it doesn't mean “all domains ending in .cn.” Likewise, geoip:cn doesn't look up where a website is registered. Websites behind a CDN may resolve to IPs in multiple regions, so domain-based and resolved-IP-based routing can produce different results.

Before You Update: Check the Source, Core, and File Path

Updates commonly fail for one of three reasons: the client updates one directory while the core reads from another; the new data source doesn't include tags referenced by existing rules; or the downloaded content isn't a valid data file. Before you start, back up both currently working files and export your routing rules or client settings.

2 files

Check the GeoIP and GeoSite updates separately

3 rules

The minimal example used below to test routing

7 days

A suggested routine check interval, not a requirement

Note the core first. Check the node settings and startup logs to identify the core. Don't rely on the name of the desktop shortcut.
Check the source next. Prefer the data source bundled with your current client. If you use a custom source, verify that it provides collections such as cn and private that your existing rules rely on.
Verify the actual file path. Use the resource directory managed by the client and the paths shown in startup errors. Portable installs, separate data directories, and multiple client copies may not share files.
Keep a rollback option. Record the original source, update date, and routing configuration. Backing up only the rule text won't help if the new files are missing required tags.

Recommendation: Keep the source consistent before changing rule databases

If routing currently works, update from the same source first. Switch sources only after confirming that the existing database lacks a classification you need, and then check each tag. Avoid combining a file update with a migration to a different rule system.

Update Rule Files in the Client and Reload the Core

Menu labels can vary by client version and interface language. In desktop v2rayN, Geo file updates are commonly under “Check for Updates”; some versions list GeoIP and GeoSite separately. Look for the update function rather than relying on an exact label. If you can't find it, check the current version's menus and logs. “Update subscription” does not update the rule database.

Establish a working connection first. Make sure the node connects. If the rule source is unreachable on your current network, enable the client's proxy option for updates, if available. Don't assume the system proxy is working—check the update logs.
Update the Geo files. In v2rayN, open “Check for Updates” and select the Geo file update option. If GeoIP and GeoSite are listed separately, update both. Wait for each update to complete before changing any routing rules.
Check for errors. A timeout usually points to a connection problem. Errors during parsing, extraction, or writing may indicate invalid download content, directory permissions, or files in use. A changed file modification time is only supporting evidence.
Reload the core. Use the client's restart service or reload core option. If there isn't a separate button, stop and restart the connection. Then check the startup logs for data file or category loading errors.
Test routing once. Keep the routing mode and test destinations the same as before the update, then compare the actual outbound routes. Don't change the node, DNS, and entire routing template at the same time.

On Android, v2rayNG's Geo resource update option is usually in the side menu or a resources page. Open it and use the update action shown. Menu layouts and available update options in v2flyNG depend on the installed version, so don't assume they match another client. After updating on mobile, stop and restart the connection.

Routing Rules: Domains First, IPs Next, Catch-All Last

Routing rules are checked in order, and the matching rule selects the outbound. The example below shows a basic setup: send mainland China domains directly, send private and mainland China IPs directly, and route all other TCP/UDP traffic through a proxy. Here, direct and proxy are outbound tags and must exactly match the values in outbounds[].tag in your existing configuration.

Request enters the core Match domain rules Resolve if needed Match IP rules Fallback outbound

This is a configuration snippet, not a complete client configuration. It's intended for direct editing of V2Ray/Xray JSON. If you manage routing through a client interface, create rules in the same order in the routing editor and save them to the currently active rule set.

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

Rule 1 matches a domain collection. When a request includes a domain that matches geosite:cn, route it through direct. There's no need to rely on GeoIP to make a second routing decision for the same request.
Rule 2 matches IP collections. The two collections in the same ip array use OR logic: either match is sufficient. The target doesn't need to belong to both. The exact range covered by a private address collection depends on the data file.
Rule 3 is an explicit fallback. TCP and UDP requests that don't match earlier rules go through proxy. Put this broad rule last; otherwise, later rules may never be checked.
Don't combine fields indiscriminately. Adding both domain and ip to one rule does not mean “match either the domain or the IP.” Different condition fields typically all need to match. Separate rules are easier to review.

IPIfNonMatch means that if a domain request isn't routed by its domain rules, the target IP is resolved and checked against IP rules. The final network fallback doesn't classify domains or replace this resolution step. With AsIs, the routing module won't resolve domains specifically for IP rules, so requests that include only domain information may go to the fallback outbound.

DNS and Rule Order: A Successful Update Doesn't Guarantee the Expected Route

GeoSite doesn't choose a DNS server, and GeoIP can't fix incorrect DNS resolution. The routing module decides which outbound a connection uses; DNS settings determine how an address is resolved. They're related, but “route mainland China domains directly” doesn't mean DNS queries will necessarily go to a DNS server in mainland China. Check DNS server selection and query routing separately.

Observed symptom	Check first	What to do
Domain rules never match	Whether the core receives a domain or an IP address	Check how the app connects through the proxy. Consider sniffing settings if needed, but don't assume every encrypted connection can reveal its domain.
All websites use the same outbound	Routing mode and first rule	Make sure custom routing is enabled and move any catch-all rule to the end.
The same site sometimes uses a different outbound	CDN addresses and IP classification	Check whether routing depends on GeoIP. For consistent results, add a domain exception near the top.
Existing connections don't change after editing rules	Whether the connection was already established	Reload the core and create a new test connection. Don't use an existing long-lived connection to judge new rules.

Even with IPIfNonMatch, a domain rule matched earlier won't be overridden by a later GeoIP rule. Conversely, if an app resolves a domain to an IP before the request reaches the proxy, GeoSite may not have a domain to match. Whether sniffing can recover the domain depends on the protocol, traffic, and configuration; it isn't a guaranteed fix.

Recommendation: Check the Request Details Before Blaming Stale Data

If traffic takes the wrong outbound, first check the destination domain or IP in the logs, the outbound selected, and the rule order. Consider updating the data or adding a specific exception only after confirming that the request details are correct, the rules are enabled, and the collection still doesn't include the destination.

Troubleshooting Failed Updates and Missing Categories

The update says it succeeded, but startup reports a missing category. Why?

First, note the missing tag shown in the logs, such as geosite:cn. Check whether the current file source includes that collection, then verify the path read by the core. Don't replace the tag with a similar-looking name. Restore the backed-up files if needed, confirm the core starts successfully, and then adjust the rules to match the categories provided by the new data source.

GeoIP updated, but the GeoSite download timed out. What should I do?

Check the result of each update separately, then verify the source and network connection for the failed one. If the client supports updates through a proxy, retry using a node you've confirmed works. Don't repeatedly overwrite a working file, and never copy one file and rename it as the other.

The subscription updated, but why is the routing database still old?

Subscriptions mainly provide node information; Geo files have a separate update option. Run the update from the client's Geo resource menu, then restart the connection. If the subscription service also provides routing configuration, check the rule text and data file update status separately.

Some websites stopped loading after the update. Should I switch nodes right away?

First check whether the core started normally, then see whether the website's outbound changed. If the site worked before the update and works again after restoring both data files, investigate changes to tags and categories. If all connections fail, check the node connection, DNS, and local proxy settings.

There's no need to change data sources every day just to stay current. For typical use, checking once a week is reasonable; update sooner if categories change or the logs report errors. Updating a rule database won't increase node bandwidth or change which protocols the server supports. It only updates the data used to make routing decisions.

Verify the Results: Test Three Destinations and Keep a Rollback

For testing, choose a domain expected to connect directly, one expected to use a proxy, and a local network service you have permission to access. The goal isn't to measure speed but to confirm that each type of connection uses the expected outbound. Use a real address for the local service; don't repeatedly send test requests to random addresses.

Check the connection endpoint. For example, if an app uses 127.0.0.1:10808, first verify that this is the current client's listening port and check which proxy protocol it accepts. Port 10808 is just an example; use your actual settings.
Confirm the configuration loaded. Save the routing rules, reload the core, and check for file read errors, missing tags, or configuration parsing errors. If startup fails, don't try to infer routing behavior from what you see in the browser.
Create a new connection for each test. Record the destination, time, and outbound tag shown in the logs. If the client only shows direct/proxy, that can confirm the outbound but may not identify the specific rule that matched.
Narrow down the issue. If needed, temporarily keep only the minimal rule set or increase log detail for a brief reproduction. Restore your usual log level afterward. Before sharing logs, remove node addresses, user IDs, and browsing history.
Keep the working version. Once all three destinations behave as expected, clean up outdated backups. If something goes wrong, restore the original files and rules, then redo the update and changes separately.

Keep three things on record: the rule file source, the order of routing rules, and the core in use. Even if you switch devices or reinstall the client, you can restore the same routing behavior before deciding whether to change categories or DNS. For initial setup, see the setup guide; for field definitions, consult the protocol reference.