How to Update Clash GeoIP and GeoSite Databases: Sources, Auto-Updates, and Rules

1. GeoIP, GeoSite, and Rule Sets: What’s the Difference?

Geographic routing in a Clash configuration usually doesn’t mean the client checks a website’s country on the fly. Instead, the core loads data files. GeoIP matches destination IP addresses to regions or categories; GeoSite matches domain names to site categories. They use different data, so one file cannot replace the other.

This guide is for mihomo, the core that evolved from the original Clash.Meta. Before you begin, check the core name and version in the client’s About or core information page. A client labeled Clash doesn’t necessarily support every setting here. Don’t apply mihomo GeoSite or auto-update settings to older Clash cores.

Updating the database doesn’t rewrite your routing policy

The database tells the core “which collection this domain or IP belongs to”; rules decide “where matching traffic goes.” For example, in GEOSITE,cn,DIRECT, cn comes from the database, while DIRECT specifies the outbound route. Updating the data can change collection membership, but it won’t switch direct connections to a proxy or reorder your rules.

2. Choosing Data Sources and File Formats

Common sources include community-maintained domain category projects, regional IP data projects, and release repositories that compile and repackage upstream data. For example, MetaCubeX/meta-rules-dat offers several builds for mihomo. Think of “source” in two layers: the release repository hosts downloadable files, while upstream projects define the categories. Their update schedules may differ.

• Choose the format first: For DAT mode, set the geoip URL; for MMDB mode, set the mmdb URL. Renaming a file does not convert its format.
• Then check category names: Labels such as cn must actually be included by the data source. Sources may not offer the same site, ad, or service categories.
• Stick to trusted sources: Keep a record of the repository, release channel, and download date. Don’t switch to an unknown mirror whenever a download fails.
• Know which format you’re downloading: Web pages, archives, YAML rule sets, MRS rule sets, and DAT databases serve different purposes and aren’t interchangeable.

geolocation-!cn is a domain category defined by the dataset, not a runtime check that classifies every domain as “outside mainland China.” Unknown domains may not be included. Likewise, GeoIP country or region labels describe how an IP is classified in the data; they don’t necessarily reflect a website’s operator, content language, or the route a user actually takes.

3. Configure Automatic Updates in mihomo

The example below uses DAT mode and an update interval of 24 hours. These fields belong at the YAML top level, alongside rules and dns—not nested under a proxy group or node. This is a configuration snippet to merge into your existing config, not a replacement for the entire subscription.

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 enables automatic updates for the core’s geodata. geo-update-interval is measured in hours, not seconds. The mmdb URL in the example is for switching formats; it doesn’t mean DAT mode uses both GeoIP datasets at once. Actual downloads also depend on the core version, enabled features, and how the client manages mihomo. Check the runtime logs to confirm what happened.

Keeping MMDB mode

If your existing configuration already uses Country.mmdb successfully, change the first line of the example to geodata-mode: false and keep geox-url.mmdb. You don’t need to switch data modes just to update the database. After changing modes, make sure the required file is present and check that your existing GeoIP categories are still supported.

Keep your settings after subscription updates

1. Back up the active configuration and note the current values of the three update fields.
2. Add the top-level settings through the client’s override, merge, or extension configuration feature. Menu names vary by client. Don’t paste the snippet into the node subscription URL field.
3. Reload the configuration and check the core startup logs for unknown fields, download failures, or data parsing errors.
4. Open the runtime configuration shown by the client and confirm the subscription template hasn’t overwritten the fields. Check again after the next subscription update.

4. Replace Database Files Manually and Find the Working Directory

The most common manual update mistake isn’t the download—it’s choosing the wrong directory. A client’s subscription config directory, application directory, and core working directory may all be different. Check startup arguments, directory details in the logs, or the client’s data directory shortcut first. Finding a file with the right name doesn’t prove the core is using it.

Find the actual path from startup arguments

For a standalone mihomo instance, use -d to specify the working directory explicitly. These are custom deployment examples, not default paths for every desktop client:

# Linux: working directory is /home/lin/.config/mihomo
mihomo -d /home/lin/.config/mihomo

# Windows PowerShell: working directory is C:\mihomo\data
.\mihomo.exe -d C:\mihomo\data

In the Linux example above, common target paths are /home/lin/.config/mihomo/geoip.dat, /home/lin/.config/mihomo/geosite.dat, or, in MMDB mode, /home/lin/.config/mihomo/Country.mmdb. If your configuration or client specifies another data location, use that path instead. Linux filenames are case-sensitive, so the downloaded country.mmdb must match the Country.mmdb filename expected by the core.

Replacement steps

1. Record the current state: Save the active configuration, data source URL, file modification times, and current test results.
2. Download the complete file to a temporary location: Don’t overwrite a file that’s in use. Make sure you downloaded a release artifact, not an error page or repository file preview.
3. Stop the core: In a desktop client, stop the service or exit the app. For a container deployment, stop the relevant container. Closing the settings window alone usually leaves the core running in the background.
4. Back up, then replace: Save the original as something like geosite.dat.bak, then add the new file. On Linux, the service user needs read access to the working directory; automatic updates also require write access.
5. Restart and check: Review the file-loading logs and rule matches. The core may cache data, so replacing a file on disk doesn’t guarantee that the running process will reload it immediately.

For container deployments, also check how the host directory is mounted to the working directory inside the container. Replacing a same-named file in an unmounted host directory won’t affect the container’s data. If parsing fails after an update, stop the core, restore the backup, and restart it. Then check the new file’s source and format.

5. Writing GEOSITE and GEOIP Rules

The rule snippets below assume your configuration already has a usable policy group named Proxy. Replace that name with the exact name of your own policy group before pasting. Rules are evaluated from top to bottom; once a connection matches a rule, the core won’t keep looking for a “better” route.

rules:
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,Proxy
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

• GEOSITE,cn,DIRECT: Send domains in the database’s cn collection directly.
• GEOSITE,geolocation-!cn,Proxy: Match domains in this category from the data source and send them to the specified policy group.
• GEOIP,CN,DIRECT,no-resolve: Match IP addresses in China. no-resolve means this rule won’t trigger an extra domain lookup; it does not disable DNS for the entire client.
• MATCH,Proxy: Handle connections that didn’t match any preceding rule. Place it after all rules you want evaluated.

If you want GeoIP to resolve a domain that doesn’t have an IP yet before checking it, remove no-resolve as needed. This changes DNS query behavior and the matching process. If you keep it, whether a domain connection matches the IP rule depends on whether the core already has a destination IP available to check.

Fix individual domains instead of replacing the whole database

To route a few specific domains through a particular outbound, add DOMAIN or DOMAIN-SUFFIX rules before the general category rules. This is easier to track than replacing the entire data source. If your DOMAIN-SUFFIX rules come before GeoSite rules, they take precedence; updating GeoSite won’t change that order.

Also, interval: 86400 under rule-providers usually means the rule provider updates every 86,400 seconds. It’s a different field and unit from the geodata setting geo-update-interval: 24. A successful rule set update doesn’t mean the GeoSite data has also been updated.

6. Troubleshooting Update Failures and Rule Mismatches

Verify the result with a fresh connection

1. Make sure the client is in Rule mode. Global and Direct modes won’t follow the routing rules above in the same way.
2. Choose a domain you need to troubleshoot. Find its new connection in the client’s connections panel, then note the destination domain, matched rule, and outbound policy group.
3. After updating, close the site’s existing connection and make a new request. Established TCP or QUIC connections usually won’t be rerouted automatically when database data changes.
4. If the app connects directly to an IP address, or the core doesn’t know the domain, check DNS, sniffing, and how the app connects first. GeoSite needs domain information; updating the file alone can’t provide it.

TUN mode determines how some traffic enters the core; it doesn’t update GeoIP or GeoSite. System proxy and TUN cover different traffic, so the connections you see may also differ between modes. Change one variable at a time while troubleshooting: keep traffic capture and DNS settings unchanged, then compare rule matches before and after the database update. This helps avoid mistaking a change in traffic handling for an effect of the data update.