How to Update GeoIP and GeoSite Databases in mihomo

GeoIP and GeoSite: IP Data vs. Domain Categories

mihomo uses geodata to help route traffic. GeoIP looks up the country, region, or address group associated with a destination IP. GeoSite matches destination domains against predefined categories, such as a service's domain group. The databases provide the data used for matching; rules determine which outbound policy applies. Updating a database changes the contents of these groups, but does not reorder your rules.

geodata-mode: true makes GEOIP use DAT data; set it to false to use MMDB data. This setting controls the data format for GeoIP lookups. It does not mean that disabling it turns off all GeoSite rules. GeoSite rules still require the relevant domain database.

Before you update: check the core, active configuration, and data source

FlClash is the client; the core evaluates the rules. The settings in this guide are for mihomo. Older Clash cores and other clients may not support every option shown here. When troubleshooting, note the client and core versions, then inspect the configuration currently in use—not just the original subscription content.

1. Check the core. Confirm that the client is using mihomo by checking its version information or startup logs. Note the version so you can consult the documentation for that release.
2. Check the configuration. In FlClash, confirm which configuration is selected on the Configuration page. If the client applies overrides or merges settings, check the final configuration passed to the core.
3. Check the mode. Look at geodata-mode. In DAT mode, update geoip.dat; in MMDB mode, update the MMDB file actually in use.
4. Check the rule types. Search for GEOIP, GEOSITE, and RULE-SET. A configuration that only uses remote rule sets may not rely on the same geodata.

Subscription updates and database updates are separate processes. Refreshing a subscription usually updates nodes, proxy groups, and configuration text. Geodata is maintained by the core or the client's data update feature. A refreshed node list does not mean the GeoSite data has been updated.

Automatic updates: set a 24-hour interval in mihomo

The example below shows top-level settings using MetaCubeX's public DAT data sources. Merge this snippet into your existing configuration; it is not a complete configuration with proxies and proxy groups. These fields must be at the same indentation level as other top-level fields, such as rules and dns.

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"

• geo-auto-update: true: Enables automatic geodata updates in the core.
• geo-update-interval: 24: Sets the update interval to 24 hours. The unit is hours, not minutes.
• geox-url.geoip: The download URL for GeoIP data in DAT format.
• geox-url.geosite: The download URL for GeoSite data.

If your configuration already has geox-url, merge in its child entries and keep any other sources still in use. Do not add a second top-level key with the same name. In MMDB mode, configure the corresponding geox-url.mmdb; do not put a DAT URL in the MMDB field.

Use persistent overrides for subscription configurations

Direct edits to a downloaded subscription file may be overwritten the next time the subscription refreshes. If your version of FlClash supports persistent overrides or configuration merging, save these fields there. The menu location can vary by version, so use the label shown in your client. For a local configuration, edit the YAML file you manage yourself.

After saving, reload the configuration and restart the core if needed. Check the logs for parsing errors. Automatic updates require the core to be running and the network to be reachable. If the device is asleep, the client is closed, or a download fails, an update is not guaranteed to finish every 24 hours by the clock.

Manual updates: use the client or replace local files

Use the client's built-in data update feature first

If your client offers an update option for GeoIP, GeoSite, or geodata, first check which format it updates, then run it. The menu location and available data may vary between FlClash versions. Don't mistake the subscription refresh button on the Configuration page for a geodata update.

1. Keep a working copy of your configuration and a backup of the databases. Note the files' modification times before updating.
2. Run the client's geodata update, wait for it to finish, and check the logs for download or loading results.
3. If the client asks you to reload the configuration or restart the core, follow the prompt so the new data can be used for subsequent matches.
4. Close existing connections to the test site, reconnect, and check the matched rule and outbound in the connection details.

If the client has no update option, replace the files the core actually reads

On desktop, you can replace files manually once you have confirmed the data directory. Find the working directory in the startup logs, core startup arguments, or the directory option provided by the client. Standalone mihomo can use -d to specify this directory. Clients may store subscription files and core data separately, so don't assume a file is in a particular location just because its name matches.

Exit the client or stop the core. Move the old files to a backup directory, then put the downloaded replacements in the actual data directory. DAT mode typically uses geoip.dat and geosite.dat. In MMDB mode, keep the filename the core is already configured to read, and note that Linux filenames are case-sensitive. Start the core and check the logs to confirm the data loaded.

GEOIP and GEOSITE rules: syntax and match order

mihomo evaluates regular rules from top to bottom and typically applies the policy for the first match. The examples below assume your configuration defines a proxy group named PROXY. If yours uses a different name, update the examples accordingly. Merge them into your existing rule list; don't add a duplicate rules key.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOSITE,google,PROXY
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

• DOMAIN-SUFFIX expresses a specific domain suffix match. Place it first to override a broader category rule later in the list.
• GEOSITE,google,PROXY uses the GeoSite google category. The rule matches only when the destination domain is in that set.
• GEOIP,private,DIRECT,no-resolve uses the private group provided by the data source. Confirm that the selected source includes this group before using the rule.
• GEOIP,CN,DIRECT checks whether the destination IP belongs to the CN group. If a domain request doesn't have an IP yet, this may trigger a DNS lookup.
• MATCH is the catch-all rule and should come after specific rules.

What no-resolve does

Adding no-resolve to a GEOIP rule prevents it from initiating a DNS lookup for a request that has only a domain name. Address matching can still occur if the destination is already an IP or the request context has an available IP. This does not disable DNS for the entire client, nor does it guarantee that the rule can handle every domain request.

GeoSite requires domain information. Domain-category rules may not match when an app connects directly to an IP, domain sniffing returns no result, or the traffic interception method doesn't preserve the domain. TUN intercepts traffic, but it cannot recover the domain for every connection. Check your DNS, Fake-IP, and sniffing settings as well.

Update failures and rules not matching: troubleshoot with logs

Avoid making the download depend on data that hasn't loaded yet

On first launch, the database may be missing while downloading it depends on rules that need that database to initialize. This can create a startup-and-download deadlock. Start with a minimal configuration that can connect to the data source, or prepare the data files manually, then restore your full rules. Repeatedly refreshing the subscription usually won't fix this dependency.

RULE-SET and GeoSite use separate update schedules

RULE-SET references a rule set defined under rule-providers. Each provider manages its own source and update schedule. For example, interval: 86400 for an HTTP provider means 86,400 seconds, or 24 hours. That is different from the hours-based geo-update-interval: 24. Updating geosite.dat does not refresh every provider.

Verify the update: check the matched rule on a new connection

A successful database download is only the first step. To verify the update, switch the client to Rule mode and choose a domain with a clearly defined category in your configuration. Close any existing connection to the site, reconnect, then check the destination domain, destination IP, matched rule, and outbound policy in the connection details or logs. Global mode bypasses the rule-based routing you want to test, so it isn't suitable here.

1. Check the load result: Make sure there are no missing-file errors, missing categories, or data parsing errors.
2. Check rule order: If an earlier domain rule matches, updating the GEOIP data later in the list won't change that connection's policy.
3. Check a new connection: An established long-lived TCP connection usually won't switch routes immediately after a database update.
4. Set the right expectations: IP geolocation and domain service categories are different. Changes to a CDN's IP addresses can also affect GEOIP matches.

For routine maintenance, enable automatic updates every 24 hours and run a manual update if something looks wrong; check the logs afterward. If an update causes a regression, restore the previous database and configuration, then compare the data source, categories, and rule order one at a time. For basic setup, see the FlClash setup guide. For DNS, mode, and connection issues, continue troubleshooting with the Troubleshooting guide.