How to Update mihomo GeoIP and GeoSite Databases and Write Rules

GeoIP, GeoSite, and Rule Providers: What's the Difference?

In mihomo, rules determine matching order, while databases supply the data used for matching. Updating a database does not change rule order or replace subscription proxies. If a site is routed through the wrong proxy group, check the active configuration, database contents, and rule matched by the connection separately.

geodata-mode selects the GEOIP data backend; turning it off does not disable GEOSITE. GeoSite matches domains carried by the connection or obtained by the core, while GeoIP matches the destination IP. A domain category does not indicate a server's physical location, and an IP's registered location does not guarantee that a service should connect directly.

rule-providers are a separate mechanism. They're typically referenced by RULE-SET and use rule-set files in formats such as YAML, plain text, or MRS, with their own update settings. Updating geosite.dat does not also refresh every rule provider.

Check the Core, Data Source, and Working Directory

These configuration examples are for mihomo. Older Clash clients may bundle different cores, so don't assume compatibility based on the client name alone. First, check the core information in the client or its startup logs to confirm that mihomo is running. For command-line deployments, run the command below to note the exact version, then inspect the configuration.

mihomo -v
mihomo -h

Choose a Data Source That Matches Your Rule Categories

Common sources include MetaCubeX's meta-rules-dat release builds and related rule-data projects from Loyalsoldier. Projects may use different upstream data, filtering methods, and category names. Files with the same name aren't guaranteed to contain the same cn, github, or ad-blocking categories.

• Check the data project's release page for the available file formats, then copy the direct download URL. Don't save a webpage URL as a database file.
• GeoIP DAT and MMDB files are not interchangeable by changing the file extension.
• A slimmed-down edition can reduce storage use and load time, but may omit categories referenced by your existing rules.
• Save a working copy of your configuration and data before switching sources. Change one thing at a time to make issues easier to diagnose.

Find the Directory the Core Actually Reads

When running the core directly, -d sets the working directory and -f sets the configuration file. If a Clash client starts the core, check its startup logs or the client's data-directory option. The client installation directory, subscription storage directory, and core working directory may all be different.

mihomo -d /srv/mihomo -f /srv/mihomo/config.yaml

These are Linux path examples. This setup manages databases in /srv/mihomo; on Windows and macOS, use the actual paths shown in the logs. Linux filenames are case-sensitive, so check the spelling of Country.mmdb carefully when replacing an MMDB file manually.

Configure Automatic Geodata Updates

This example uses databases published by MetaCubeX and selects DAT as the GEOIP backend. Merge these fields into the top level of your configuration; don't nest them under dns, tun, or a proxy group. If geox-url already exists, edit that section instead of adding duplicate keys.

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

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

• geo-auto-update: true: Enables automatic updates for the core's geolocation databases.
• geo-update-interval: 24: Sets the update interval to 24 hours, not 24 seconds.
• geox-url.geoip: Data source for GEOIP in DAT format.
• geox-url.geosite: Data source for GeoSite.
• geox-url.mmdb: Data source for MMDB; used when the MMDB backend is selected.

Listing download URLs in the configuration doesn't mean every startup forcibly downloads every file. Check the current core logs to see what's actually loaded and updated. After saving, validate the configuration, then reload it in the client. If the client has its own geolocation database manager, check whether it overrides these fields.

If a database is missing on first launch, the core may need to download it before loading rules. This can create a startup dependency if the download requires a proxy that hasn't started yet. If needed, prepare the files over an available network first, then verify automatic updates after startup.

Manually Replace GeoIP and GeoSite Files

Manual updates offer more control when downloads are restricted, device storage is limited, or you need to roll back a database. Don't write directly to a file the core is using, and don't rely on the filename alone to confirm a successful download.

1. Record the runtime settings. Check the core version, working directory, configuration path, and current geodata-mode value.
2. Back up the existing files. Copy the working geoip.dat, geosite.dat, or Country.mmdb to a backup directory.
3. Download to a temporary location. Check that the HTTP download succeeded and the file size looks reasonable. If the content is a login or error page, download the correct release asset instead.
4. Stop the core before replacing files. Exit the client's core or stop the relevant service, then put the new files in the actual working directory. Keep the original filenames and ensure the files have the correct read permissions.
5. Test and restart. Validate the configuration using the same working directory. After startup, check the database-loading logs and the match results for new connections.

mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml

-t tests the configuration; it does not perform a real website visit. If data required by the test is missing, the core may try to download it or return an error. For Linux service deployments, make sure the account running the test has the same directory access as the service account.

Replacing a file doesn't guarantee that a running core will reload it immediately. The clearest process is to stop the core, replace the file, and start it again. If the new data causes missing categories or load failures, restore the backup and original configuration, then restart and verify. Don't change the core, subscription, and database all at once and then try to track down the cause.

Writing GEOIP and GEOSITE Rules

The examples below assume your configuration already has a policy group named PROXY. DIRECT is the built-in direct-connection policy. If your proxy group is named something else, replace PROXY with that name. Policy names must match your configuration exactly.

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - GEOSITE,github,PROXY
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

Rules are checked from top to bottom; the first match wins.

DOMAIN-SUFFIX adds an explicit domain exception; GEOSITE,github,PROXY matches the GitHub category in the database; GEOSITE,cn,DIRECT matches the cn domain collection defined by that data source; GEOIP,CN,DIRECT,no-resolve then checks the destination IP; finally, MATCH handles all remaining connections.

If you put MATCH first, none of the rules below it will get a chance to match. Placing a broad category before a specific exception can also make the exception ineffective. Domain rules generally belong before rules that depend on IP matching, but the right order ultimately depends on your needs.

no-resolve Controls Resolution Behavior, Not IP Matching

no-resolve means the core won't actively resolve the destination domain just to check this IP rule. If the connection already has a usable destination IP, GEOIP matching can still take place. It does not disable global DNS and is not a standalone DNS leak prevention switch.

For example, if an unresolved domain doesn't match an earlier GEOSITE rule, it may skip a GEOIP rule with no-resolve and continue to the next rule. If you always want that domain to connect directly, adding a precise domain rule is usually more predictable than simply removing no-resolve.

Troubleshooting: Updates Not Taking Effect

Test with a new connection, not just a page refresh

First confirm that rule mode is active. Then open the client's connection log and check the destination domain, destination IP, matched rule, and policy chain. In global mode, the final proxy endpoint alone doesn't tell you whether GEOIP or GEOSITE affected routing as expected.

Browsers may reuse existing HTTP/2 or QUIC connections. After changing rules or data, close existing connections and make a new request; refreshing the same tab may not establish a new connection. For testing, record the results for at least one domain that should connect directly, one that should use a proxy, and one known IP address.

Tell DNS Issues Apart from Database Issues

CDNs, DNS caches, and different resolvers can return different IP addresses for the same domain, so a change in GEOIP results doesn't necessarily mean the database update failed. With TUN or fake-ip, also check the domain recognized by the core and the actual destination details. Don't mistake a synthetic address shown by an app for the public IP address of the server.

A reliable troubleshooting order is to confirm the files and core in use, verify rule categories, and then inspect actual connections. Database updates refresh the data used for matching; DNS, rule order, and proxy group selection still need to be configured separately. For core concepts, see the Quick Reference Glossary. For deployment steps, see the Cross-Platform Guide.