What Are Clash GeoIP and GeoSite Databases? Update Methods & Rule Setup

1. What GeoIP and GeoSite Each Handle

Think of rule-based routing as a sorting problem: for every incoming connection, the core has to answer two questions — which country or region does the destination IP belong to? And which category of site does the destination domain belong to? The first question is answered by looking up the GeoIP database; the second by looking up the GeoSite database. The two files handle separate jobs and can't substitute for each other — if either one is missing, the rules that depend on it simply can't find an answer.

GeoIP: A Lookup Table From IP to Country/Region

The GeoIP database maps IP address ranges to country/region codes. When a rule reads GEOIP,CN,DIRECT, the core takes the connection's destination IP, looks it up in the database, and routes it directly if it falls within a CN range. The mihomo (Clash Meta) core reads country.mmdb by default, generating its own geoip.metadb cache on first load; once geodata-mode is set to true, GEOIP rules switch to reading the v2ray-format geoip.dat instead. There's also an optional ASN database, GeoLite2-ASN.mmdb, which lets IP-ASN rules route by autonomous system number. All these terms have entries on the glossary page if you need to double-check any of them.

GeoSite: A Lookup Table From Domain to Site Category

The GeoSite database comes from the community-maintained domain-list-community project: maintainers organize huge numbers of domains into categories by service, provider, and region, then compile them into a geosite.dat file. When a rule reads GEOSITE,google, the core compares the destination domain against every entry under the google category. Categories also support attribute tags — for example, google@cn only matches entries in the google category flagged with the mainland China attribute, giving you finer-grained control than matching the whole category.

2. Why These Two Databases Need Regular Updates

Both databases are living data. Cloud providers expand capacity every month, and IP ranges get reassigned between regions; new services launch and old domains change ownership, shifting site categories along with them. If your database is stuck at a state from six months ago, your routing decisions are still operating on a six-month-old picture of the internet. This typically causes three kinds of problems:

• Traffic that should go direct gets proxied instead: IP ranges newly assigned to CN aren't recorded in an outdated database, so the fallback rule sends them to the proxy — meaning access to sites in mainland China ends up taking a detour.
• Traffic that should be proxied goes direct instead: a newly launched service outside mainland China hasn't been added to any geosite category yet, so GEOIP or fallback rules let it through directly — showing up as sites that won't load or work inconsistently.
• Rule hit rate drops: as category entries change, the category name a rule relies on may get split up or renamed, quietly turning the old rule into dead weight.

For typical usage, updating every one to four weeks is enough. If your rules are time-sensitive — say, you need to catch newly launched services right away — you can shorten the auto-update interval to 24 hours; the only cost is pulling a few extra megabytes once a day.

3. Three Ways to Update the Databases

Method 1: A Button in the Client UI (Easiest)

GUI clients turn this into a one-click action. In Clash Verge Rev, for example, the settings page lists external resources like GeoIP and GeoSite, and clicking Update pulls the latest files; clients like FlClash have a similar resource-update option. Once the update finishes, reload the config or restart the core so the new database actually takes effect. This method works for everyone — and under the hood, that button is just running the same download-and-replace steps covered in Method 3.

Method 2: Enable Auto-Update in the Config File

The mihomo core has a built-in auto-update switch — just add it at the top level of config.yaml:

# Auto-update the geo databases
geo-auto-update: true        # Enable auto-update
geo-update-interval: 24      # Update interval, in hours

# Custom download source (swap in a mirror URL if needed)
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"
  asn: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/GeoLite2-ASN.mmdb"

Three things to note: geo-update-interval is measured in hours, not seconds; the four keys under geox-url correspond to geoip.dat, geosite.dat, country.mmdb, and the ASN database respectively — you can leave out any key you don't need; and if GitHub is unreliable on your network, just swap the URL for a working mirror — the file contents are identical.

Method 3: Manually Download and Replace the Files (Most Control)

When the in-app update fails, or you want precise control over which file version you're running, a manual swap is the most reliable option:

1. Open the download sourceVisit the meta-rules-dat repository's Release page in your browser and find the four files: geoip.dat, geosite.dat, country.mmdb, and GeoLite2-ASN.mmdb.
2. Download the filesClick through and download each one; on the command line, you can also grab a single file at a time with curl.
3. Locate the config directoryThe mihomo config directory sits alongside config.yaml; in Clash Verge Rev, you can open the config directory directly from Settings with one click.
4. Replace the files and restartOverwrite the old files with the new ones, then restart the core or reload the config so it reads the databases fresh.

4. Referencing geoip and geosite in Routing Rules

Once the databases are in place, the rules finally have something to look up. A typical routing tail looks like this:

rules:
  - GEOSITE,category-ads-all,REJECT   # Ad domains, block outright
  - GEOSITE,google,Proxy Select        # Google services go through the proxy
  - GEOSITE,cn,DIRECT                 # Sites in mainland China go direct
  - GEOIP,CN,DIRECT,no-resolve        # Direct if the destination IP is in mainland China
  - MATCH,Proxy Select                 # Everything else goes through the proxy

Here's the order of operations: an incoming connection is checked against domain categories first, so the three GEOSITE rules handle everything that can be judged by domain. By the time GEOIP comes into play, if the target is already an IP it's looked up directly; if it's a domain, the outcome depends on no-resolve — without it, the core resolves the domain via DNS first and then checks the database, which is more thorough but adds a resolution step; with no-resolve, the rule only applies to connections that are already in IP form, skipping the resolution overhead at the cost of letting domain-form connections slip past this rule. The config above puts GEOSITE,cn earlier to catch mainland domains first, so adding no-resolve to the GEOIP rule won't let them slip through.

Quick reference for common geosite categories:

Two writing conventions to keep in mind: category names should always be written in lowercase exactly as they appear in the official list — a typo won't throw an error, it'll just silently fail to match. For finer control, use the @ attribute — for example, GEOSITE,google@cn,DIRECT routes only the Google domains reachable in mainland China directly, while GEOSITE,geolocation-!cn,Proxy Select effectively means "route all sites outside mainland China through the proxy."

5. Common Questions About Updating and Referencing

The update button keeps failing

Nine times out of ten it's an unreachable download source. GitHub Releases can be hard to reach directly on some networks — try swapping geox-url for a mirror, or get the client itself routed through the proxy before clicking Update. You can also skip the client's download logic entirely and just use Method 3 to replace the files manually.

The rule is written but doesn't seem to work

Check three things in order: first, rule order — see whether a broader rule earlier in the list (like a MATCH placed too early, or a large IP-CIDR block) is intercepting the connection before it ever reaches your GEOSITE/GEOIP rule. Second, whether you reloaded — after editing the config, you need to reload or restart the core for it to re-read the databases. Third, category name spelling — a misspelled category name won't throw an error, it'll just quietly fail to match.

Loading is slow on low-memory devices

On low-spec devices like routers, you can set geodata-loader to memconservative, trading load speed for lower memory usage; on a regular PC, the default standard mode is fine.

Let geo-auto-update handle refresh timing and a sensibly ordered rule set handle the actual routing decisions, and these two databases will keep doing their job quietly in the background. If you haven't set up your overall rule-based routing framework yet, go back to the setup guide to cover the basics first, then come back for this advanced config — don't skip ahead.