How to Update GeoIP and GeoSite Databases and Write Routing Rules

GeoIP and GeoSite: IP locations vs. domain categories

GeoIP matches traffic based on the geographic location associated with a destination IP address. GeoSite matches domains against predefined collections. Both provide data for routing rules; neither supplies proxy nodes or replaces a subscription. Updating a database changes the data available to rules, but does not add nodes or change their connection settings.

The configuration examples in this article are for clients using the mihomo core. Clash Meta is the core's former name. Legacy Clash cores, different forks, and GUI client wrappers may behave differently, so a client name alone does not confirm support for every field. Before making changes, check the actual core name in the client's About section or at the start of its runtime log.

geodata-mode controls the GeoIP data format; it is not a master switch for GeoSite. Even in MMDB mode, geosite.dat may still be required if the core supports GEOSITE and the configuration uses it. Updating Country.mmdb does not mean the domain category data has also been updated.

Where databases are stored: check the running core's data directory

The client installation directory, subscription directory, and core data directory may all be different. First look in the client's settings, More menu, or tray menu for an option such as “Open config directory” or “Open data directory”; the exact label depends on the client. Then check for existing files such as Country.mmdb, geoip.dat, and geosite.dat. Do not simply place files in your Downloads folder.

Check startup arguments when running mihomo independently

You can use -d at startup to specify a working directory. The Linux example below uses /var/lib/mihomo as the data directory and keeps the configuration file separately at /etc/mihomo/config.yaml. They do not need to be in the same folder.

mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml

• Manual startup: Check the command actually used; do not rely only on the terminal's current directory.
• systemd service: Run systemctl cat mihomo to check ExecStart and the service's run user; make sure the service name matches your system.
• Container: Check which host path is mounted to the data directory inside the container. Files must be written to that mounted location.
• GUI client: Make sure the files belong to the currently enabled core instance, not another client that is no longer in use.

Preserve capitalization. On Linux, Country.mmdb and country.mmdb are different files. Some cores support custom file names or locations; in that case, follow the active configuration and the paths recorded in the logs.

Manual updates: back up, replace, and reload

Manual updates are useful when adding databases for the first time, when automatic downloads fail, or when you need to roll back to an earlier version. First determine whether you use MMDB or DAT mode, then download the corresponding format. The source should provide files compatible with mihomo and document its coverage and category names; category collections are not guaranteed to be identical across projects.

1. Record the current setup. Save the active configuration and note the file paths, modification times, and data source. Copy the old files to a backup directory instead of deleting them immediately.
2. Stop the core. Stop the core service in the client, or exit the client and confirm the background core has stopped. If it runs as a service, stop that service.
3. Check the download. Make sure you have the database itself, not an archive, project documentation page, or HTML page returned after a failed download. Extract archives first and use the correct file inside.
4. Replace the file in its original location. In MMDB mode, replace Country.mmdb; in DAT mode, replace geoip.dat. To update domain categories, replace geosite.dat.
5. Check file permissions. The core's user needs permission to access the directory and read the file. Automatic updates also require write access to the data directory.
6. Restart and verify. Start the core and check for errors such as database parsing failures, missing categories, or insufficient permissions. Then test whether new connections match the expected rules.

Changing a file on disk does not necessarily refresh data already loaded in memory. Hot-reload behavior varies between clients, so restarting the core after replacing files is the clearest way to confirm that the new files were loaded. If the core fails to start, stop it and restore the backup first, then check that the file format matches. Do not keep changing rules to mask a file problem.

Automatic updates: set the interval and download source

In mihomo cores that support these fields, automatic database updates can be enabled at the top level of the configuration. This example uses DAT mode with a 24-hour update interval. This is not the subscription refresh interval, and it does not download the database every time a connection is made.

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

geodata-loader specifies how DAT data is loaded; memconservative is a memory-saving loader. It does not set the download address or change rule priority. To keep using MMDB, set geodata-mode to false; do not switch formats just to enable automatic updates.

Match geox-url keys to the file types

To use a custom source, set download URLs in the top-level geox-url mapping. geoip is for GeoIP DAT, geosite is for GeoSite DAT, and mmdb is for MMDB. Use the complete HTTPS file URL supplied by the data project's maintainers, not the project homepage or a page that requires interactive sign-in.

This article does not provide a fixed remote data URL: whether a category rule works depends on the data project you choose. If you use the trusted source already configured by your client, you do not need to add geox-url. If the client overrides the source, check the effective configuration rather than relying on the original subscription text.

• Managed subscription configuration: Use the client's override, merge, or extension feature to add top-level fields, so they are not overwritten on the next subscription update.
• Standalone configuration: Edit the configuration file actually used at startup. Do not define the same top-level key twice.
• Download failure: Check the request URL and error type in the logs first, then check the network, system time, disk space, and directory permissions.

GEOIP and GEOSITE rules: order determines the match

Rules are evaluated in order, and the first matching rule usually determines where traffic goes. The snippet below handles a specific domain first, then matches domains by GeoSite category, checks IPs with GeoIP, and finally uses a fallback policy group. This example assumes the subscription already defines a policy group named “节点选择”; if it does not, replace it with a name that exists in your configuration.

mode: rule

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,节点选择

GEOSITE: category names come from the database

GEOSITE,cn,DIRECT sends domains matched by the cn collection in the active GeoSite database to DIRECT. It is not a simple check for the .cn domain suffix. Check the data project's category list to see whether cn or another category is available. After changing data sources, confirm that categories referenced by existing rules are still present.

GEOIP: no-resolve does not disable all DNS queries

GEOIP,CN,DIRECT,no-resolve matches based on the geographic information for a destination IP and avoids actively resolving an unresolved domain solely to check this IP rule. If a request already includes a destination IP, it can still be matched. This option does not disable DNS globally or stop applications from making their own DNS queries.

If you want requests that do not match a domain rule to be checked by location using their resolved IP, you can remove no-resolve as needed. The trade-off is that rule evaluation may depend on additional DNS lookups. With Fake-IP, domain restoration, existing DNS results, and the request path can also affect behavior. Check the connection records rather than drawing conclusions from the rule text alone.

MATCH: always put the fallback rule last

MATCH handles requests that have not matched any earlier rule. If you put it before GEOSITE or GEOIP, those later rules will never get a chance to run. Custom domain exceptions usually belong before broad category rules; otherwise, even a domain present in the database may not be routed as expected.

A GeoIP location does not prove who owns a server or where a business operates. Sites that use a CDN, deploy across regions, or rely on Anycast may have domain categories that do not match their IP locations. To keep traffic for a specific service on a particular policy, add an explicit domain rule instead of relying only on country or region matching.

Still not routing after an update? Check the active config, logs, and new connections

When troubleshooting, separate “the file updated successfully” from “traffic matched a rule.” A successful database load only confirms that the data is readable. For a rule to run, the application's traffic must pass through this core, and the core must be in rule mode.

1. Check the effective configuration. Confirm that the running rules, geodata-mode, and update fields are present, rather than only in a configuration that is not enabled.
2. Confirm rule mode. Global or direct mode will not produce the same results as this rule list.
3. Start a new connection. Close existing connections to the test site, then visit it again. Established long-lived connections usually do not switch routes immediately when a database is updated.
4. Review connection details. Note the destination domain, destination IP, matched rule, and final policy chain. Change one setting at a time to compare results.
5. Check the traffic entry point. The system proxy affects only apps that follow its settings. Which traffic TUN can capture also depends on routing and exclusion settings. Requests that never reach the core cannot match Geo rules.

You can temporarily increase the log level while troubleshooting, then restore the usual level to limit log size. Before sharing logs, redact subscription URLs, tokens, node credentials, and sensitive browsing records. Keeping a restorable configuration and database backup makes issues easier to trace than frequently changing data sources.