How to Update GeoIP and GeoSite Databases: geodata Mode, Download URLs, and Rule Syntax

1. GeoIP, GeoSite, and subscription updates are different

GeoIP and GeoSite provide data for routing rules; they are not proxy nodes. Updating a subscription typically fetches nodes, proxy groups, or an entire configuration. Updating geographic databases changes the IP ranges or domain lists that rules can match. These are maintained separately, so clicking “Update subscription” doesn’t mean the databases have been updated too.

A GeoIP country or region assignment doesn’t identify where a website operator is based, nor does it guarantee the actual location serving a user’s request. CDNs, deployments across regions, and differences between data sources can all lead to a mismatch between “this domain should go direct” and “the resolved IP is assigned to this region.” That’s why domain rules usually go before IP rules.

2. What geodata-mode does and where files are stored

It changes the GeoIP data format

In mihomo, geodata-mode: true uses DAT for GeoIP; false uses MMDB. This setting isn’t a master switch for all geographic routing, and it doesn’t create any rules. GeoSite still requires the appropriate data file and a GEOSITE rule.

• geox-url.geoip: the download source for GeoIP DAT.
• geox-url.mmdb: the download source for GeoIP MMDB.
• geox-url.geosite: the download source for GeoSite DAT.
• geodata-loader: how DAT data is loaded. Common values are standard and memconservative; this setting doesn’t determine the rule’s target policy.

The core typically stores these files in its working directory. Common filenames include GeoIP.dat, GeoSite.dat, and country.mmdb. Some clients use their own runtime directories, so don’t assume the installation folder is the data directory. Case sensitivity can also affect file detection on Linux; check the core logs, actual files, and client documentation.

Find the working directory from runtime arguments to avoid editing the wrong copy

1. Look for database files in the client’s configuration or working directory. The “configuration directory” and “application logs directory” may be different locations.
2. Check the core’s startup arguments: -d specifies the working directory, and -f specifies the configuration file. The configuration file’s directory isn’t necessarily the working directory.
3. If you run the core yourself, specify the working directory explicitly with mihomo -d ./mihomo-data -f ./config.yaml.
4. When using a container, check the volume mounts. The working directory inside the container may differ from the host location where files are stored.

Back up your current configuration and database files before making changes. If the client supports overrides, merge settings, or extension configs, use those persistent options to add global fields. Direct edits to an auto-generated runtime configuration may be overwritten the next time you update your subscription.

3. Set download URLs and enable 24-hour automatic updates

Here’s an example you can merge into the top level of a mihomo configuration. The data comes from the MetaCubeX meta-rules-dat releases. geo-update-interval is measured in hours, so 24 means updates every day. This isn’t the interval in seconds used by rule providers.

geodata-mode: true
geodata-loader: memconservative
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"

• These fields belong at the same level as rules and dns; don’t nest them under proxy-groups or profile.
• If geox-url already exists, merge the mappings into it instead of adding a duplicate top-level key.
• If you switch to geodata-mode: false, make sure the MMDB source is available. Updating DAT alone won’t replace the MMDB currently in use.
• Automatic updates don’t mean the files download as soon as you save the configuration. Apply the configuration or restart the core, then check the update logs to confirm scheduling is enabled.

See MetaCubeX/meta-rules-dat for the data source and the mihomo general configuration docs for field details. Release assets may change as the project is maintained. If a link stops working, check the releases page first; don’t switch to an unfamiliar download URL based on the filename alone.

4. GEOIP, GEOSITE, and rule order

Clash rules are checked in order; the first matching rule determines the policy. This example puts domain categories before IP rules and uses MATCH as a fallback. It defines an “Outbound” policy group with only DIRECT to demonstrate valid structure. For real use, add your existing proxy nodes or policy groups; this example does not provide a working proxy connection.

proxy-groups:
  - name: Outbound
    type: select
    proxies:
      - DIRECT

rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Outbound

no-resolve does not disable DNS

GEOIP,CN,DIRECT,no-resolve means this rule won’t trigger a domain lookup specifically to find a match. If the connection already has a destination IP, the rule can still match it; if no IP is available, rule evaluation may continue. This parameter doesn’t disable DNS for the entire client or prevent resolution at other stages.

Rule matching depends on the connection information available

GeoSite needs domain information. If an app connects directly to an IP, the domain mapping is lost, or the traffic interception method changes, not every connection is guaranteed to match a domain category. TUN is a way to intercept traffic, not a prerequisite for updating GeoSite; enabling TUN alone won’t automatically recover domain names for every connection. With fake-ip, DNS mappings also affect whether the core can recover the corresponding domain.

To route a specific site a certain way, add a specific rule before the category rules, such as DOMAIN-SUFFIX,example.com,DIRECT. This is a matter of rule order; you don’t need to rebuild the database for a single domain. Use the actual domain you want to handle and verify the match in the connection details.

5. How to replace database files manually when automatic downloads fail

Common causes include download timeouts, unreachable redirect destinations, and an outbound proxy that depends on a configuration that hasn’t loaded yet. Opening GitHub’s homepage in a browser doesn’t prove the core can download release assets; the browser and core may use different proxy settings and network routes.

1. Record the error: Save the resource URL, error type, and destination file location from the logs. Distinguish connection timeouts from HTTP errors and data parsing failures.
2. Get the right asset: Download the actual binary file from the release source specified in the configuration. Make sure you haven’t saved a webpage, sign-in page, or error response instead.
3. Stop the core: Use the client’s stop option. If the app remains in the system tray after closing its window, explicitly stop the background core to avoid leaving the file in use.
4. Back up and replace: Move the original file to a backup directory, then put the new file in the confirmed working directory using the local filename expected by the core.
5. Restart: Check the data-loading logs and configuration parsing results. If a category is missing or parsing fails, restore the backup first, then check the source and file format.

Don’t rename an MMDB file to DAT to try to convert it, and don’t put GeoSite data in the GeoIP file location. Changing a file extension doesn’t convert its format; the core reads the file’s internal structure. On Linux or when running as a service, make sure the account running the core has read access to the directory. Automatic updates also require write access.

6. Verify updates using logs and connection details

A changed file timestamp only shows that a write occurred; a configuration that starts successfully doesn’t prove test traffic matched the expected rule. Check the update process and actual traffic routing separately, recording each result instead of relying only on whether a webpage opens.

Close existing long-lived connections before testing, then make a new request. Established connections usually don’t go through the full routing process again just because a database was refreshed. Browser connection reuse can also make it look as if nothing changed. If you temporarily increase log verbosity, restore it after troubleshooting. Don’t share full logs publicly if they contain node credentials, subscription URLs, or personal browsing history.

7. Common errors and what to check

“Category not found” or GeoSite fails to load

First check whether the current data source provides the category used in your rule, then make sure the downloaded content is actually GeoSite DAT. Switching to a trimmed data source may remove some categories. Restoring a compatible source or removing unsupported rules is more effective than repeatedly restarting.

The database updated, but a website still uses the wrong policy

Check whether an earlier DOMAIN, DOMAIN-SUFFIX, or RULE-SET rule matched first. Then check the DNS response and destination IP shown in the connection details. Database updates don’t change rule order or clear all DNS caches. Identify the exact matching path before deciding whether to fix a rule, clear the cache, or report a missing entry to the data source maintainer.

Do I still need to update GeoSite if I use rule providers?

It depends on whether your configuration still references geographic data. A RULE-SET provider updates according to its own url, path, and interval; automatic geographic database updates don’t replace that mechanism. If your configuration still uses GEOSITE or GEOIP, or your DNS settings reference those categories, keep the corresponding data up to date.