How to Update Clash GeoIP and GeoSite Databases: MMDB/DAT Sources and Rule Syntax

Check the core and database formats first

GeoIP classifies destination IP addresses by location; GeoSite classifies domains using domain lists. Neither is a proxy subscription or a source of proxy servers. Updating these databases only changes the data used by matching rules. It does not add proxies or change the outbound selected by a policy group.

The automatic update settings in this guide are for mihomo, the successor to Clash Meta. Older Clash cores and cores bundled with different clients may support different fields and use different data directories. Check the client's About or core information page and note the core name and version. For a standalone installation, run mihomo -v. Don't assume a client supports GEOSITE based on its name alone.

When researching these files, you'll often see names such as GeoIP.mmdb, Country.mmdb, and GeoSite.dat. They may be project filenames, legacy names, or shorthand for a data type; they don't tell you which path the core actually loads. mihomo typically uses the lowercase filenames shown in the table. Linux filesystems are usually case-sensitive. Matching extensions don't guarantee compatible contents: MMDB and DAT files can't be made interchangeable by renaming them.

Choosing data sources: check the format and categories

You can use build artifacts from the MetaCubeX/meta-rules-dat project, which provides GeoIP, GeoSite, and other data for compatible cores. When choosing a source, check its data documentation as well as the download URL: where the IP geolocation data comes from, how domain lists are generated, which categories are included, and how often the data is updated.

• MMDB: Make sure it's a country or region geolocation database that the core can read. City and ASN databases aren't direct substitutes.
• GeoIP DAT: Check that the file contains the country or region codes you need, along with any additional categories referenced by your rules.
• GeoSite DAT: Check that it includes the categories used by your rules, such as cn. Slimmed-down versions may omit some service categories.
• Update URL: Use the URL for the actual binary release asset, not the repository homepage or a browser-based file preview.

This guide uses the project's latest release assets. These URLs point to rolling updates, not a pinned version. To reproduce routing results later, keep a copy of the data files and record the download date, source URL, and core version. Different sources may classify the same IP or domain differently, so a recent file date alone doesn't mean its classifications are correct.

mihomo automatic update settings

Add these fields at the top level of your YAML file, alongside dns and rules. This example uses MMDB mode and a 24-hour update interval; geo-update-interval is measured in hours, not seconds. All three resource URLs are shown so you can switch modes later, but the data actually loaded depends on the core, the rules you use, and the loading method.

geodata-mode: false
geodata-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"

Merge into your existing config; don't add duplicate keys

First, check whether your config already contains geox-url. Don't define the same key more than once at the same level; how duplicate keys are handled depends on the parser. If a subscription generates your config, use the client's persistent override or merge feature. Direct edits to generated files may be overwritten the next time the subscription refreshes.

If you switch to geodata-mode: true, GEOIP uses geoip.dat. Replacing only country.mmdb won't update the IP data used in this mode. GeoSite still uses geosite.dat; you don't need to switch GEOIP modes for it.

Account for first-download dependencies

Automatic updates require the core to reach the resource URL. DNS failures, TLS handshake errors, and network timeouts can all interrupt an update. If downloading the data depends on geolocation rules that haven't loaded yet, startup can run into a dependency issue. In that case, install a working data file manually first, then troubleshoot the update connection. This is usually more effective than repeatedly restarting the core.

A client's Update Geo Database action is separate from refreshing a proxy subscription. Menu labels vary by client version, so check the core logs for download and load results afterward. Setting a field to true doesn't prove that an update has completed.

Manual replacement: find the data directory and stop the core first

The data directory may be separate from the installation directory and the directory containing your subscription YAML. GUI clients may manage service-mode data files separately. Use the client's config directory shortcut, runtime logs, or core startup arguments to confirm the path. Don't overwrite a matching filename you found elsewhere on disk.

The example below uses mihomo as a standalone process. Specifying -d pins the data directory, preventing the core from reading files from a different working directory. Run these commands from the project working directory. You must have a valid mihomo-data/config.yaml and curl installed.

mkdir -p ./mihomo-data

curl -fL --output ./mihomo-data/country.mmdb.new \
  https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb

curl -fL --output ./mihomo-data/geosite.dat.new \
  https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat

-f makes the command fail on HTTP error status codes, and -L follows redirects to release assets. After both commands succeed, check that the files aren't empty and aren't HTML pages returned by a gateway. A successful download only confirms that the request completed; the core still needs to be able to read the files.

1. Stop the core using this data directory. In a GUI client, stop its managed core or service; don't start another process that could compete for the same ports.
2. Copy the existing country.mmdb and geosite.dat to a separate backup directory, and keep a copy of the current config.
3. Rename each downloaded .new file to its final filename. In DAT mode, download, back up, and replace geoip.dat instead.
4. Test the config with the same data directory, then restart the core and check the logs and rule matches for real connections.

mv ./mihomo-data/country.mmdb.new ./mihomo-data/country.mmdb
mv ./mihomo-data/geosite.dat.new ./mihomo-data/geosite.dat

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

These rename commands overwrite files with the same name, so back them up first. A config test checks the setup before startup; it doesn't verify every traffic path. If it fails, read the specific error and restore the previous data first. Don't cycle through multiple sources at once, or format and network issues may get mixed together.

GEOIP, GEOSITE, and rule order

Clash rules are generally checked from top to bottom, and the first match determines the policy. This is a rule snippet, not a complete config. Proxy Selection must exactly match a policy group name in your existing proxy-groups; you can also replace it with the name of an existing outbound.

rules:
  - DOMAIN-SUFFIX,internal.test,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy Selection

Domain categories and IP geolocation aren't equivalent

GEOSITE,cn,DIRECT uses the cn domain list in the database. It's not shorthand for “all domains ending in .cn.” GEOIP,CN,DIRECT checks the geolocation of the destination IP. A domain may resolve to IPs in different regions through a CDN, so these rules can produce different results.

Putting domain rules before IP rules lets you make decisions based on domain lists first, with less reliance on the location of resolved IPs. However, GeoSite needs usable domain information in the connection context. If an app connects directly to an IP and no other mechanism can recover the domain, GeoSite can't identify the original service automatically.

What no-resolve actually means

no-resolve means the core shouldn't trigger a DNS lookup solely to match this IP-based rule. If the connection already has a usable destination IP, the rule can still be checked. This doesn't disable DNS globally or make DNS requests bypass the proxy.

So if a domain doesn't match GeoSite and the following GEOIP rule has no-resolve, processing may fall through to MATCH when no destination IP is available. That's a result of the rule design, not necessarily a corrupted database. Put MATCH last; if it comes before the geolocation rules, they won't get a chance to match.

Updates not taking effect? Troubleshoot by error type

Verify using connection logs, not just by opening a website

For testing, use Rule mode and choose a domain you want to check. Record the destination domain, destination IP, matched rule, and final policy from the connection panel. Global mode isn't suitable for checking rule order here. A website loading only proves that some connection path works; it doesn't prove that GeoSite or GeoIP matched.

Updating the database usually doesn't reroute all existing connections. Close old connections from the test page or app, then make a new request. If needed, use the client's connection manager to close the relevant connection. If the result is still unexpected, first test the policy name and rule loading with an exact DOMAIN rule, then check the category list itself.

Update and rollback checklist

• Record the core version, current geodata-mode, data directory, and source URL.
• Confirm the GeoSite category exists, and check whether GEOIP currently reads MMDB or DAT.
• Back up the old files and config; keep downloaded temporary files separate from the files in use.
• Test and reload the config, then check the exact matched rule on a new connection.
• If something goes wrong, restore the config and its matching data files together. Avoid pairing new rules with an old database that lacks the required categories.
• After restoring scheduled updates, check the next update log and make sure subscription refreshes don't overwrite persistent overrides.

The key to updating GeoIP and GeoSite is keeping the categories referenced by your rules, the format selected by the core, and the files actually loaded in sync. Check all three before changing the update interval. For other fields, see the config reference. To understand the difference between rules, policy groups, and subscriptions, see the glossary.