GeoIP & GeoSite Database Outdated? How to Update and How Rule Matching Works

What Are GeoIP and GeoSite Databases, Exactly

Open a typical Clash or mihomo config file and you'll often spot lines like GEOIP,CN,DIRECT or GEOSITE,netflix,Proxy in the rules section. Both of these rely on the GeoIP database and the GeoSite database. They're not part of the config file itself — they're separately packaged binary resource files you download and update on their own, typically named geoip.dat (or geoip.metadb) and geosite.dat. In the mihomo core, the GeoIP data often ships as a MaxMind-format database like Country.mmdb.

The GeoIP database maps IP address ranges to the country or region they belong to — for example, a block of IPv4/IPv6 addresses tagged as CN (mainland China), US, or JP. The GeoSite database maps domains or domain suffixes to categories: geolocation-cn bundles a large set of domain rules for sites commonly used in mainland China, while categories like netflix, google, and telegram cover domains tied to specific services. Together, these two databases form the backbone of rule-based proxy routing: when the client receives a connection request, it checks whether the target is a domain or an IP, looks it up in the relevant database to find its category, and then applies your config rules to decide whether to go direct, route through a proxy, or block it.

How Rule Matching Actually Uses These Databases

Understanding the matching flow helps you pinpoint exactly where things break when a database goes stale. Take a common rule set as an example:

rules:
  - GEOSITE,geolocation-cn,DIRECT
  - GEOSITE,netflix,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

When the client tries to reach a domain, the core first attempts domain-based matching — checking whether the geolocation-cn category in the GeoSite database contains that domain (or a parent domain, or a wildcard suffix). A match sends the traffic direct; no match moves on to check the netflix category, which routes to the Proxy group. If no domain rule matches at all, the core resolves the domain via DNS to get an IP address, then looks that IP up in the GeoIP database. A CN match goes direct; otherwise it falls through to the final MATCH catch-all rule and gets proxied.

This flow reveals something important: GeoSite handles domain-level classification, GeoIP handles IP-level classification, and the two complement rather than replace each other. Many users run into "I clearly set this to route through the proxy, but it's still going direct" (or the reverse) — and the root cause is usually not a misconfigured rule, but a database that's missing the latest record for that domain or IP range because it hasn't caught up with changes to the provider's actual infrastructure.

Typical Symptoms of an Outdated Database

Since ISPs and service providers regularly change or expand the IP ranges and domains they use (especially CDN nodes and cloud egress IPs), while GeoIP/GeoSite databases need to be scraped, verified, and packaged for release either manually or via automated scripts, there's always a natural lag between the two. Common symptoms of a stale database include:

• Sites that should go direct are being proxied: a site commonly used in mainland China switches to a new batch of server IPs, but the old database still classifies that IP range as overseas or uncategorized, so traffic that should hit DIRECT falls through to the catch-all rule and gets proxied instead — adding unnecessary latency.
• Services that should be proxied are going direct: conversely, a streaming or social platform restructures its domains or adds new subdomains that the old GeoSite category doesn't include yet, so requests fail to match any rule, fall back to the default direct connection, and the site fails to load or throws a region-lock error.
• Routing rules gradually go “blunt”: over time, more and more connections stop matching any precise rule and end up relying entirely on the final MATCH catch-all — at which point the rule set is essentially dead weight, and proxy group load and latency both get worse.
• LAN or internal service quirks: if you've defined custom private-network rules that depend on comparisons against an outdated GeoIP dataset, internal service matching can also go sideways — this shows up more often in setups running TUN mode for global traffic capture.

Any one of these symptoms on its own can easily get blamed on "bad subscription nodes" or "a client bug." But if it comes with a timeline like "this used to work fine, and it's only recently gotten slow or inaccurate," the database version is the prime suspect.

Comparing the Three Update Methods

Mainstream Clash / Clash Meta (mihomo) clients generally support three types of update methods, each suited to a different scenario.

Method 1: The Built-In Update Button

Most GUI clients (like Clash Verge Rev, FlClash, etc.) have an "Update GeoIP/GeoSite Database" or "Update Core Resources" button in settings. Clicking it pulls the latest packaged files from a built-in default source and overwrites the local cache. This is the easiest, no-fuss option — you don't need to understand the file structure, and it covers most everyday users just fine. The downside is the update source is usually locked to whatever repository mirror the developer chose; if that mirror is flaky in your particular network environment, updates may fail or crawl, and you'll need to step in manually.

Method 2: Manually Downloading and Replacing Files

For command-line setups or deployments without a GUI button, you can download geoip.dat, geosite.dat (or mihomo's .metadb/.mmdb equivalents) directly from the rule set's release repository, replace the old files of the same name in your client's config directory, then restart the core or trigger a config reload to apply the changes. The upside here is precise control — you can pick an exact rule set version. Just make sure the file names and paths match exactly what the client expects; drop them in the wrong folder and it'll keep reading the old cache even after the "update."

Method 3: Specifying an Update Source via Config Fields

The mihomo core lets you declare the geo database download URL and auto-update policy directly in the config file, using dedicated fields such as:

geodata-mode: true
geodata-loader: standard
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://your-trusted-mirror-url-here/geoip.dat"
  geosite: "https://your-trusted-mirror-url-here/geosite.dat"

With geo-auto-update turned on, the core automatically checks for and downloads new versions on the interval set by geo-update-interval (in hours), while geox-url lets you swap the default source for a mirror of your choosing — handy if you're running a self-hosted mirror or have specific speed requirements. This is the most flexible method, but it also demands the most precise understanding of what each config field actually does; a wrong field name or format will cause the core to fail on startup, so back up your original config before making changes.

How to Verify the Update Actually Took Effect

Finishing the update action doesn't guarantee the rules are actually live yet. It's worth running through a quick check in this order:

1. Check the client's log panel or runtime logs for messages like "geoip database loaded" or "geosite updated," rather than assuming success with no confirmation.
2. Pick a site you know recently changed IPs or domains as a test case, clear your browser's DNS cache, revisit it, and watch which proxy group the connection actually routes through (most clients' connection panel shows the matched rule name for each connection in real time).
3. If your client supports a rule test or "lookup rule" feature, just enter the domain/IP directly and check the match result — it's far more direct than trial-and-error browsing.
4. Make sure DNS caches and connection caches at both the system and app level are also cleared, so stale resolution results don't mask the effect of the database update.

If the rules still look off after verifying, it's usually because the rule set version number or URL in the config is pointing to a stale location — not because the database update itself failed. In that case, double-check the geox-url value or the mirror address in your client settings; that's usually more productive than clicking the update button over and over.

Common Issues and Troubleshooting Tips

One easily overlooked detail: some clients keep a local cache validation for the database files, so if you replace the files without clearing the old index in the cache directory, a restart can still pick up the old data. If you're seeing "I definitely swapped the file, but nothing changed," try fully quitting the client process (not just reloading the config) and starting it fresh so the core rebuilds the database index from scratch.

For long-term use, treat "updating the geo database" as just as important a routine maintenance task as "updating your subscription link." Your subscription determines which nodes are available; the database determines whether traffic should even go through them — and if either one lags behind, your overall routing accuracy takes the hit. For most users, turning on the auto-update toggle in client settings and checking the update log now and then is more than enough. Only when you're managing a self-built config or have specific requirements for your update source do you need to dig down into manually managing config fields.