GeoIP and GeoSite Database Update Guide: mihomo Geodata Modes and Rule Matching

GeoIP vs. GeoSite: IP Data and Domain Categories

In mihomo rules, GEOIP,CN,DIRECT and GEOSITE,cn,DIRECT may look similar, but they use different types of data. GeoIP maps IP ranges to countries, regions, or categories defined by a dataset. GeoSite groups domains by site, service, or topic. These databases provide the criteria for matching; the rule's policy on the right still determines whether a connection goes DIRECT or through a proxy.

For example, when you visit a website in mainland China, its domain might first match GEOSITE,cn. If it doesn't, a later rule may match the destination IP after DNS resolution with GEOIP,CN. If a site uses an overseas CDN, shared cloud hosting, or a newly registered domain, different results from these two rules don't necessarily mean the database is broken—the categories may not reflect the site's actual deployment.

Data file	Primary use	Keep in mind
`geoip.dat`	Provides IP categories for GEOIP rules in DAT mode	Available categories depend on the data source
`Country.mmdb`	Provides IP geolocation data in MMDB mode	Unlike DAT, MMDB files can't be substituted by simply changing the file extension
`geosite.dat`	Provides domain categories for GEOSITE rules	Category names and attributes vary by dataset

Data sources and category definitions

Common sources include Loyalsoldier's v2ray-rules-dat and MetaCubeX's meta-rules-dat. These projects build and publish data; they don't provide proxy nodes. Even if both sources offer geosite.dat, their categories, attributes, and coverage may differ. Before switching sources, make sure every category used by your config is available in the target dataset.

A GeoIP country assignment doesn't identify the country where a service's company is based, nor does it guarantee the network route used to reach that service. GeoSite categories also don't mean that every subdomain of a site has the same deployment.

geodata-mode: Choose the data format for GEOIP

geodata-mode is a top-level mihomo config option. Set it to true to use DAT data for GEOIP, or false to use MMDB data. This isn't a master switch that enables all geolocation rules, and it won't convert domain rules to IP rules. GeoSite continues to use its own domain database.

# Top-level config, alongside rules and dns
geodata-mode: true

geo-auto-update: true
geo-update-interval: 24

geox-url:
  geoip: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat"
  geosite: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb"

This example sets the automatic update interval to 24 hours and explicitly specifies URLs for all three data files. It's not a complete proxy config and doesn't replace the nodes or proxy groups in your subscription. In DAT mode, check the geoip URL and corresponding file first when troubleshooting GEOIP; in MMDB mode, check mmdb. A successful download of one file doesn't prove that the data currently in use was updated.

Config fields must be in the active configuration

Clash Nyanpasu's UI settings, subscription config, and overrides may all contribute to the runtime config used by the core. The exact controls vary by client version, so check whether the top-level fields above appear in the final active config. Direct edits to a downloaded subscription file may be overwritten the next time the subscription refreshes. For persistent changes, use the client's supported override or config-merge feature.

Make sure mihomo is the active core, not a different core that supports another set of config fields.
Place geox-url at the YAML top level; don't nest it under dns or profile.
Reload the config after making changes. If your version doesn't reinitialize the relevant settings, restart the core to verify them.
Check the runtime logs for parsing errors. A successful save message in the editor doesn't confirm that the changes took effect.

Updating the database: scheduled, manual, and offline options

Subscription updates, rule-set updates, and geodata updates are separate processes. A subscription update typically downloads YAML or node information; rule-providers updates from its own URL on its own schedule; geo-auto-update controls automatic geodata updates. Refreshing a subscription once doesn't mean GeoIP and GeoSite have been updated.

Automatic updates depend on both the setting and network access

In the active config, verify geo-auto-update: true and confirm that geo-update-interval: 24 is measured in hours.
Make sure the runtime environment can reach the actual download URL. GitHub release files may redirect, so being able to open the homepage isn't enough.
Check the core logs for download, loading, and error messages. Note whether a failure occurs during DNS resolution, connection, the HTTP response, or file parsing.
If the client has a geodata update option, trigger it manually to test. If it doesn't, don't treat the subscription refresh button as a substitute.

Some setups need a proxy to download data, but starting the proxy requires the local database. This creates a startup dependency. Keep the working old files so the core can start, then fix the download path. Don't clear the entire data directory first: a stale database could turn into a config-loading failure.

For offline updates, replace files by type

If downloads keep failing, get the required files from a network that can reach the release source, then transfer them to the target device. First locate the actual data directory used by the core in the client's runtime information or logs. Back up the old files and stop the core, replace the corresponding files using their original names, and restart. Don't guess the data directory from the installation location: portable and standard installs may store data in different places.

The downloaded file must be the actual release artifact. If you save a login page, error page, or archive as geosite.dat, the core will still fail to parse it. Check the HTTP status, file type, and release notes. A newer modification time alone doesn't prove the file is valid.

Don't overwrite a database while the core is reading it, and never rename an MMDB file to DAT. If the core won't start after replacement, restore the backup first, then use the logs to identify a format or category compatibility issue.

Rule matching: check rule order even after updating data

mihomo evaluates rules from top to bottom, and the first match determines where traffic goes. Updating the database doesn't change this order. If a broad domain rule or MATCH appears near the top, later GEOIP and GEOSITE rules may never run.

# Rule snippet: PROXY must be the name of an existing node or proxy group
rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

This snippet only demonstrates rule order; it's not a complete LAN and IPv6 routing setup. The first three rules cover common private IPv4 ranges. Domain categories come before country-based IP categories, and unmatched traffic goes to the proxy policy last. If your config already has rules, merge these entries into it instead of adding a second top-level key with the same name. PROXY isn't a built-in policy in every config, so replace it with the name of an existing policy group.

How no-resolve affects IP rule matching

IP rules can use no-resolve to avoid actively resolving a domain for the purpose of matching that rule. If the connection metadata doesn't include a usable destination IP, the rule may not match. Adding no-resolve to GEOIP,CN,DIRECT without considering the consequences may change routing that previously depended on DNS resolution. Decide whether to use it based on your DNS setup, connection metadata, and needs.

With fake-ip, an app may see a mapped address, which doesn't tell you the country of the real server. Check the connection details for the resolved domain, destination, matched rule, and final route. If an app uses its own encrypted DNS or passes only an IP to the core, whether GEOSITE can match depends on whether the domain is available and on related settings such as sniffing.

Signs of outdated data: distinguish missing categories from unexpected matches

Symptom	Check first	How to verify
A new domain doesn't match the expected category	The domain may not be in the dataset, or the category definitions may differ	Check the source's category list and the local database's update time
Config loading reports that a category doesn't exist	The rule category may be misspelled, or the data source may have changed	Check whether the source includes that category and its attributes
Traffic still matches an old rule after an update	The file may not have been reloaded, or an earlier rule may have matched first	Reload, open a new connection, and inspect the match details
The download succeeds, but parsing fails	The downloaded content isn't in the expected format	Check the response content and whether the file is DAT or MMDB
Traffic to a CDN address takes a different route	DNS returned a different address, or the GeoIP assignment changed	Compare the actual DNS results before and after the update

A website in mainland China going through a proxy doesn't automatically mean GeoSite data is outdated. Also check whether the proxy is in Global mode, a custom rule matched the domain first, the connection lacks domain information, or the proxy group is using the wrong exit. Conversely, a correct country assignment in the database may not meet a service's account-region or licensing-region requirements.

rule-providers isn't another name for geosite.dat

RULE-SET references rule sets defined in rule-providers, which may use YAML, text, or the supported MRS format. GEOSITE queries the geolocation domain database. Each has its own data sources, formats, and update process. Putting a rule-set URL in geox-url.geosite or using a DAT file as a plain-text rule set won't convert the format automatically.

Verifying an update: change one variable at a time

To confirm a database update worked, check which rule matches a new connection to the same destination. Browsers may reuse HTTP/2 or HTTP/3 connections, and existing connections won't switch routes just because the rule files were updated. Close the relevant connections or restart the test app, then make a fresh request.

Record a baseline: Choose one domain that should connect directly and one that should use a proxy. Note the current rule mode, matched rule, proxy group, and exit.
Update only the data: Don't change DNS, TUN, or rule order at the same time, so you can identify what caused any change in results.
Confirm the data loaded: Check the logs for download or parsing errors. Restart the core if needed and confirm the config starts normally.
Open a new connection: Visit the same domain again and check whether GEOSITE, GEOIP, or another rule matched in the connection details.
Handle exceptions: If the source's categories don't match your needs, add a narrowly scoped domain rule before the relevant broad rules.

To temporarily connect a specific domain directly, add an exact rule such as DOMAIN,example.com,DIRECT. Use DOMAIN-SUFFIX only when you need to include subdomains. Avoid routing a large block of a cloud provider's IP addresses directly to fix one site; other services may share those addresses.

For routine maintenance, follow three steps: keep a backup database that lets the core start, check that automatic updates succeed, and test key sites with new connections. GeoIP and GeoSite updates keep the matching data current and usable; rule order, DNS behavior, and proxy-group routing still need to be checked separately. See the Technical Reference for related config concepts, or start with the User Guide if you're setting things up for the first time.