Clash GeoIP & GeoSite Database Update Guide: Sources, Manual Replacement & Auto-Update Setup

What GeoIP and GeoSite actually do in routing rules

Clash routing rules often include lines like GEOIP,CN,DIRECT or GEOSITE,google,PROXY. Behind these two rule types sit two data files: the GeoIP database maps IP ranges to country or region codes, while the GeoSite database groups domain names into predefined categories (such as google, github, or netflix). When matching traffic, the rule engine doesn't need to hardcode every domain or IP range individually — referencing a category name from the database covers thousands of entries at once.

This design separates "rule logic" from "rule data." Rule logic lives in the rules field and rarely needs to change; rule data lives in standalone binary files that can be downloaded and updated independently. The database itself contains no decision logic — it's just an index table, similar to sorting domains and IPs into different folders. When a website changes its IP range, or a batch of new domains appears, keeping the database current means the rule outcomes adjust automatically, without users needing to edit rule entries in their config files by hand.

Conversely, if a database goes unmaintained for too long, rule accuracy gradually degrades: newly registered domains may not land in the right category, and a CDN's new IP range may get misclassified as being outside the mainland. That's why database version and update frequency deserve ongoing attention, rather than being a "set it and forget it" part of the config.

Comparing common database distributions

File names and formats circulating online aren't standardized and are easy to confuse. Let's separate this into two lines based on client core.

Differences between original Clash and Clash Meta (mihomo)

The original Clash core historically used Country.mmdb, a MaxMind-format GeoIP database that only maps IPs to country codes — it has no GeoSite domain grouping, and its GEOSITE rule support is limited. Clash Meta and its actively maintained successor, mihomo, use their own data formats: geoip.dat or the newer geoip.metadb for GeoIP, and geosite.dat for GeoSite. The .metadb format is the mihomo team's own successor format — smaller and faster to query, but not interchangeable with the older .dat format.

Data sources: the V2Ray/Xray lineage vs. MaxMind

The naming and structure of geoip.dat and geosite.dat originally came from the V2Ray/Xray ecosystem and were later adopted directly by Clash Meta, so the two are highly compatible in format, and category names (like cn or category-ads-all) largely align. These databases are typically compiled and published on a regular schedule by community projects, with popular distribution repositories continuously tracking IP range and domain list changes. MaxMind's GeoLite2-Country.mmdb is a separate lineage, with a data structure closer to traditional IP-geolocation databases, mainly used by older cores that only recognize the .mmdb format.

When choosing, keep one rule in mind: first confirm which core branch you're running (original Clash, Clash Meta, or mihomo), then confirm which data file format it recognizes. If the two don't match, replacing the file won't take effect — and may even cause the rule engine to error out on startup.

Full steps for manually replacing the files

Manual updates suit situations where you don't want to touch the config file and just need a one-off refresh. The core idea: download the new database file, place it where the client can read it, overwrite the old file, and restart the core.

1. Locate the client's data directory

   Different clients store GeoIP/GeoSite files in different directories — commonly alongside the config file, or under a data/resources subfolder in the client's install directory. Check the currently active config file path in the client's config management screen first; the database files are usually in the same directory or its parent.

2. Confirm which file format the core expects

   Open the client's core version information to confirm whether you're running original Clash, Clash Meta, or mihomo. Newer mihomo builds default to geoip.metadb, while older builds and Clash Meta use geoip.dat and geosite.dat. Check the file extension before downloading to avoid grabbing the wrong format.

3. Download the latest files from a matching source

   Pick an actively maintained community distribution source and download the file version matching your core. Don't overwrite immediately — back up the original files in their existing directory first, so you can roll back quickly if something goes wrong after replacement.

4. Stop the core before replacing the files

   Database files are typically loaded into memory when the core starts, so overwriting them while the core is running may not take effect right away, and on some systems the replacement can even fail because the file is locked. It's best to stop the proxy service or quit the client before replacing the files.

5. Restart the core and check the logs

   After replacing the files, restart the client or proxy service and check the core log for errors like failed database loads or format mismatches. If the log looks normal with no errors, the new database has taken effect — you can confirm by testing a domain or IP with a known, unambiguous classification and checking the routing result.

Enabling scheduled auto-updates in the config file

Manual replacement requires human intervention and is easy to forget about long-term. Clash Meta and mihomo support declaring database sources and update intervals directly in the config file, letting the core pull new versions on a schedule without manual work. The core fields live at the top level of the config file, under geox-url and related update-interval settings. A typical setup looks like this:

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

geox-url:
  geoip: "https://example.com/geoip.metadb"
  geosite: "https://example.com/geosite.dat"
  mmdb: "https://example.com/Country.mmdb"

Here's what each field does: geodata-mode must be enabled for GEOSITE rules to actually match by domain grouping instead of being ignored by the core; geo-auto-update toggles auto-update on or off; geo-update-interval sets the update interval in hours — 24 in the example means it checks once a day; the three keys under geox-url specify the download URLs for the GeoIP, GeoSite, and MaxMind-format databases respectively, and the core will pull from these addresses on that schedule. Field-name support varies slightly between core versions, so after upgrading the client it's worth checking the current version's changelog to confirm the field names haven't changed — otherwise a stale field name can silently break auto-updates.

If your subscription is provided by a proxy service, its subscription-conversion service sometimes ships a preset geox-url of its own, in which case fields you write by hand may get overwritten by the subscription content. If auto-update isn't working, first check whether these fields in the final effective config have been rewritten by the subscription.

Common issues after updating

When rule behavior looks off after a database update, the cause usually falls into one of these categories.

• Format mismatch: downloading a .dat file but loading it into a newer core that only recognizes .metadb — the core will typically log a parse failure, the rule engine falls back to an "unmatched" state, and a large amount of traffic ends up in the default policy group.
• Category names don't line up: different distribution sources may name categories for the same site differently — some use netflix, others split it into finer sub-categories. The category name written in a rule must exactly match the one actually present in the database, including case and spelling.
• Auto-update URL unreachable: if the address in geox-url is unstable or requires a proxy to reach, and the update happens before the proxy chain is established, updates will keep failing. Choose a distribution source with a simple, stable access path for this URL.
• Cache not refreshed: a few clients apply extra caching to rules in the GUI, so the database file has updated but the displayed match results haven't changed — restarting the client usually resolves this.

A good troubleshooting order is: is the file in the right directory → does the format match the core → have config fields been overwritten → can the network reach the update URL. Working through these steps in sequence catches the cause of most database-related routing issues.