How to Update GeoIP and GeoSite Databases: mihomo Data Sources, Automatic Updates, and Rules

First, understand the difference: IP geolocation, domain categories, and routing rules

If domestic websites go through a proxy or a service isn't routed as expected, don't assume the database is outdated. A mihomo rule decision involves three things: the domain or destination IP retained by the connection, the database category assigned to that destination, and the first matching rule in the configuration. Updating the database only changes the second; it won't fix rule order or policy group selection.

This guide is for mihomo, the name of the core used by later versions of Clash Meta. Desktop clients provide an interface for managing the configuration and core; a product with “Clash” in its name doesn't necessarily support the same fields. Before applying these settings, check the client's About page, core information, or startup logs to confirm that mihomo is running, then back up your current configuration.

For example, GEOSITE,cn,DIRECT uses a domain category, while GEOIP,CN,DIRECT uses the category associated with the destination IP. These aren't two versions of the same list of websites in China. A website may use an overseas CDN, and domains serving multiple regions may share an IP address, so GeoIP alone can't determine which region a website belongs to.

Data files and sources: choose the right format first

GeoIP formats: DAT and MMDB

mihomo can use different formats for GeoIP. When geodata-mode: true is set, GeoIP uses geoip.dat; with this mode off, the usual file is Country.mmdb. GeoSite uses geosite.dat. Replacing only the MMDB file therefore won't update the GeoIP data used when DAT mode is active.

The keys under geox-url must also match the data format: geoip points to GeoIP DAT, geosite to GeoSite DAT, and mmdb to the corresponding MMDB data. Don't put a plain-text domain list URL under geosite, or rename an MMDB file to geoip.dat and expect it to work.

Common data sources and how to choose

• Loyalsoldier/v2ray-rules-dat: Publishes GeoIP and GeoSite DAT files, making it a good fit for configurations that need common regional and domain categories. The examples below use this source to make troubleshooting easier.
• MetaCubeX/meta-rules-dat: Publishes data files for related core projects. Before using it, check the repository documentation, release branch, and file format. Don't mix download URLs for different outputs.
• Data bundled with the client: Convenient for the first launch, but the bundled files may predate the app installation. How they're updated afterward depends on the client and core configuration.

Different sources may use the same category name but include different entries. For private, geolocation-!cn, and domain categories with attributes in particular, check the documentation for your chosen source. A category in one GeoSite dataset isn't necessarily available in every published file.

Automatic updates: geox-url and a 24-hour interval

The following snippet can be merged into the top level of an existing configuration. It uses DAT mode and a 24-hour update interval. This isn't a complete subscription file; it doesn't include proxies, ports, or policy groups. If a key already exists in your configuration, edit that key instead of adding a duplicate at the end of the file.

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"

• geodata-mode: true: Use DAT for GeoIP; this doesn't enable all routing rules.
• geo-auto-update: true: Enable automatic Geo data updates in the core.
• geo-update-interval: 24: The unit is hours, not seconds, and updates don't run at a fixed time every day.
• geox-url: Set the data download sources. It won't update subscription proxies or rewrite rules.

This example doesn't set mmdb because it uses DAT mode. You can keep an MMDB source already present in your configuration, but its update time doesn't prove that the active GeoIP DAT has been updated. An AS number database serves a different purpose and isn't needed to use GEOIP and GEOSITE rules.

Where to make changes in the client

1. Export or copy the configuration currently in use, and note its name.
2. Look for the client's override, configuration merge, or editor feature to apply these fields to the final configuration. Menus vary by client, so no single menu path is a universal mihomo entry point.
3. Reload the configuration. If the client says global settings require a core restart, restart the core and check the startup logs.
4. Inspect the final runtime configuration and make sure the three top-level fields and two data URLs haven't been overridden by the subscription or global settings.

Changes made directly to a cached subscription file are often overwritten the next time the subscription updates. Put local settings you want to keep in a persistent override layer supported by the client. Subscription updates, Geo data updates, and the interval for rule providers are three separate mechanisms.

GEOIP and GEOSITE rules: domains first, IPs as a fallback

The example assumes your existing configuration defines a policy group named “Proxy Selection.” The name must match the actual group exactly; if yours is called “Proxy,” update the rule targets accordingly. The example covers four levels: LAN traffic, domestic domains, domestic IPs, and a final fallback. It doesn't include extra categories such as ad blocking.

rules:
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy Selection

How to read the five rules in order

1. GEOSITE,private,DIRECT: Matches the private domain category in the selected GeoSite dataset. It won't necessarily cover every corporate intranet domain; add custom rules for internal domains as needed.
2. GEOIP,private,DIRECT,no-resolve: Tries to match an existing destination IP against the private IP category, without actively resolving a domain just for this rule.
3. GEOSITE,cn,DIRECT: Routes by domain category first, rather than relying entirely on IP geolocation.
4. GEOIP,CN,DIRECT,no-resolve: Falls back to the domestic IP category when the destination IP is known.
5. MATCH,Proxy Selection: Sends connections that didn't match any earlier rule to the specified policy group.

no-resolve means “don't actively resolve a domain for this IP rule,” not “this connection will never use DNS.” If the connection already has a real destination IP, the IP rule can still be evaluated. If no usable IP is available, the rule may not match, and evaluation continues with the next rule. Whether to keep this parameter depends on your DNS settings, connection method, and routing goals.

mihomo evaluates rules in order. Once an earlier, broader rule matches, later, more specific rules won't take over. Putting MATCH first blocks all subsequent rules; routing all overseas services through an earlier category can also mask later domain-specific exceptions. Put exceptions before the broader rule they need to override.

How to verify an update: check the download, load, and match stages

A “download complete” message only confirms that one step of the update process finished. Full verification also means confirming that the core parsed the data successfully and that the target connection matched the expected rule. Check each of the following three stages; don't rely only on file dates or whether a website loads.

Stage 1: Confirm which files are in use

Find the working directory using the client's Open Configuration Directory option or the core's startup arguments. Don't assume it's the Downloads folder or the app's installation directory. In DAT mode, check geoip.dat and geosite.dat; in MMDB mode, check the MMDB file actually loaded. Operating systems may hide file extensions, so avoid names such as geosite.dat.dat.

Stage 2: Confirm the configuration and data can be parsed

When running mihomo from the command line, you can validate the configuration in a copied test directory. Create ./geo-check beforehand and put the configuration and data files you want to test there. Don't run a test command against the directory currently in use.

mihomo -t -d ./geo-check -f ./geo-check/config.yaml

If validation fails, read the first error. YAML indentation errors, missing policy groups, unavailable GeoSite categories, and data parsing failures each need a different fix. Passing validation doesn't mean all traffic will route as expected; it only clears the way for connection testing.

Stage 3: Start a new connection and check the matched rule

1. Switch to Rule mode and make sure you're not in Global or Direct mode.
2. Close any existing connection to the target website, then open it again. If needed, quit and restart the app.
3. Check the client's connections panel for the domain, destination IP, matched rule, and final policy chain.
4. Test one destination expected to go direct and another expected to use “Proxy Selection,” then record both results.

For example, if the connections panel shows GeoSite(cn) as the matched rule and DIRECT as the policy, that matches the expected behavior for the domestic domain rule. The exact display varies by client, so logs don't have to show precisely the same text. Existing long-lived connections aren't automatically re-established under new rules after a database update; use a new connection for testing.

Update failures and routing issues: troubleshoot by symptom

Can't download data on first launch?

If the configuration needs Geo data to start but the current network can't reach the data source, startup can get stuck in a dependency loop. On a network that can access the source, download the required files and place them in the core's actual working directory, then restart. Before replacing files manually, stop the core and back up the old files. Once the data loads successfully, troubleshoot the automatic update connection.

Don't remove all GEOIP and GEOSITE rules just to get the core to start while leaving the original fallback behavior unchecked. Removing rules can send connections that used to go direct to a proxy group, or leave exception services without the intended routing. Record any temporary changes and verify the configuration again after restoring it.

Does TUN mode need a separate database?

No. TUN changes how traffic is intercepted; it doesn't automatically switch to a different GeoIP or GeoSite dataset. The same core usually reads data from the same working directory. If results change after enabling TUN, first check whether domains are preserved, where DNS requests go, Fake-IP mappings, and destination connection details—not whether you need another database.

GeoSite can't match a connection that has only an IP address because there's no domain to match. In some protocols and conditions, sniffing may recover the domain, but it isn't guaranteed to work for all traffic. To learn how traffic interception, DNS, and rules fit together, see the technical reference, or look up the definitions of Fake-IP and TUN in the glossary.

A reliable maintenance routine: use a consistent source, keep a fallback, and test new connections

• Use a consistent source: Record the chosen data repository, format, and configuration fields instead of keeping only a mirror URL.
• Set a sensible interval: Start with 24 hours for routine updates; Geo data rarely needs minute-by-minute polling. Updates also pause while the computer is asleep or the core is stopped.
• Keep a fallback: Save your current configuration and working data before changing sources or replacing files manually, so you can restore both if something goes wrong.
• Verify the actual results: After updating, confirm the data loaded and use a new connection to check the domain, matched rule, and policy chain.

The goal of Geo data maintenance isn't to keep file dates as recent as possible; it's to keep the data format, category names, and rule targets aligned. Confirm the core and data mode first, configure the update source next, then verify the results in the connections panel. This usually makes problems easier to pinpoint than repeatedly replacing database files.