mihomo GeoIP and GeoSite Databases: Auto-Updates and Rule Syntax

GeoIP vs. GeoSite: Routing by IP and Domain

mihomo is the core that establishes proxy connections, resolves DNS, and applies rules. Desktop clients such as Clash Verge Rev provide the interface and manage the core. The configuration in this guide is for mihomo and should not be applied directly to older Clash cores that don't support these fields.

GEOIP and GEOSITE are both rule types, but they match different things. GeoIP maps IP ranges to countries, regions, or other dataset categories. GeoSite groups domains by site, service, or topic. Both rely on externally maintained data files; neither queries a live online geolocation service from the core.

For example, a service may distribute content across CDNs in multiple regions. The server IP's registered region alone may not identify the service category. Matching the domain with GeoSite first, then using GeoIP for remaining connections, usually expresses your routing intent more clearly. GeoIP results also don't prove physical location; update frequency and changes in IP range assignments can affect them.

Data Sources and File Formats: Choose the Loading Mode First

Data is typically curated and published by community projects. Common sources include MetaCubeX's meta-rules-dat and other projects that maintain domain and IP categories. Even when files share the name geosite.dat, their categories, update schedules, and contents may differ by publisher. Names such as cn and google must exist in the dataset you're using.

geodata-mode determines the GeoIP format

• geodata-mode: true: GeoIP uses DAT format and loads data from the source configured under geox-url.geoip.
• geodata-mode: false: GeoIP uses MMDB format and loads data from the source configured under geox-url.mmdb.
• GEOSITE uses geosite.dat; switching GeoIP to MMDB doesn't disable it.

A file extension doesn't convert a file's format. Renaming an MMDB file to geoip.dat won't make a DAT loader able to read it. Likewise, YAML, text, or MRS rule-set files can't be used directly as the database URL for geox-url.geosite.

Auto-Update Configuration: geox-url and Update Intervals

This example uses DAT mode and data published by MetaCubeX. The URLs shown are database sources, not client installers. Add these fields at the top level of your configuration, alongside dns and rules; don't indent them under a proxy group or DNS settings.

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"

• geo-auto-update: true: Enables automatic Geo data updates in the core.
• geo-update-interval: 24: Sets the update interval to 24 hours, not 24 seconds.
• geox-url.geoip: GeoIP data source for DAT mode.
• geox-url.geosite: GeoSite data source used by GEOSITE rules.

This example configures only the two file types in use. If your existing configuration uses MMDB, keep geodata-mode: false and configure a suitable geox-url.mmdb. Don't change only the download URL and forget to switch the loading mode. An update interval of 24 hours also doesn't guarantee that the data will change every 24 hours: the upstream may not publish new data, a download may fail, or the core may not be running continuously.

Save persistent changes in Clash Verge Rev

1. Open Profiles and check which subscription profile is currently active.
2. Use the client's merge or override feature to add the top-level fields above. The name of the editing option may differ between versions, so check the final effective configuration to confirm the changes.
3. Reload the configuration. If the update task or database status hasn't changed as expected, restart the core and check the startup logs.
4. Check that the effective configuration contains a single, clearly defined geox-url block and that geo-auto-update is still true.

Direct edits to a downloaded subscription file may be overwritten the next time the subscription updates. Take care with how overrides merge lists: some operations replace the entire rules section instead of appending to it. Back up your current configuration before making changes, and confirm the client's merge order.

GEOIP, GEOSITE, and Rule Order

This example shows a common order: match explicit domains first, then domain categories, then IP categories, and finally a catch-all. "Select Proxy" must match a policy group already defined in your configuration; change it to the actual group name if needed. This is a rule snippet, not a complete configuration with proxies, DNS, and listener ports.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOSITE,google,Select Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Select Proxy

mihomo checks ordinary rules from top to bottom and applies the policy for the first match. Explicit domain rules placed earlier can therefore take precedence over category rules below them, while MATCH belongs at the end as the catch-all. If MATCH is first, the Geo rules below it won't get a chance to route those connections.

GEOSITE category names aren't a universal, fixed dictionary

GEOSITE,google,Select Proxy uses the google category in the current database. It doesn't tell the core to collect every domain containing that word. After switching GeoSite sources, check that the categories you use are still available. If a category is missing, fix the rule or switch to a compatible data source instead of repeatedly changing proxies.

GeoSite matching requires the core to know the domain. If an app connects directly to an IP, or the traffic interception path doesn't preserve or recover the domain, GeoSite can't match a site category using only the destination IP. TUN mode expands the scope of intercepted traffic, but it doesn't mean every connection includes a domain that GeoSite can inspect.

no-resolve: Don't resolve domains just to match a rule

In GEOIP,CN,DIRECT,no-resolve, no-resolve is a rule parameter. It tells the core not to resolve the destination domain to an IP solely to check its IP range for this rule. It doesn't disable DNS globally or prevent resolution by apps, proxy connections, or earlier rules.

To reduce unnecessary local DNS lookups, match key domains with GeoSite first, then add no-resolve to your GeoIP fallback rules. The trade-off is that connections not covered by domain rules and without a real destination IP may fall through to the later MATCH rule. That's a result of the rule design, not necessarily a sign that the GeoIP data is corrupted.

If you want remaining domains to be resolved before deciding whether to connect directly based on IP region, use GEOIP,CN,DIRECT. Also review the DNS resolution path, upstream availability, and privacy implications. With fake-IP mode, distinguish virtual addresses from real destination addresses; don't treat a visible fake IP as the public IP GeoIP should check.

Verify Updates and Routing: Check the Configuration, Files, and Connections

Verify the setup in three stages. A successful configuration load means only that the fields and required resources passed the relevant checks; a successful database download means only that the resource was retrieved. Only a connection matching the expected rule confirms that routing worked as intended. Don't rely solely on a client toggle or whether a website loads.

Stage 1: Check the core version and configuration syntax

When running mihomo independently, you can use the commands below. Make sure the data directory and configuration path point to the locations actually in use; otherwise, you may test a different set of files. Desktop clients usually have their own working directories. Don't modify one of those directories from another process while the core is running.

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

Use -v to check the version of the core actually being run, and -t to test the configuration. If you see an unknown-field or resource-loading error, first confirm that the core is a mihomo version that supports the relevant settings, then check YAML indentation and data sources. Don't infer core capabilities from the client name alone.

Stage 2: Check download logs and the actual working directory

• In the client's Logs page, look for entries related to Geo data loading, downloads, and updates. Check for timeouts, HTTP status codes, and parsing errors.
• Check geoip.dat, geosite.dat, or the corresponding files in MMDB mode in the core's actual working directory—not just the directory containing the subscription file.
• Record file modification times and sizes, and review error logs before and after an update. A changed modification time can be a useful clue, but it doesn't by itself prove that the category contents changed.

Stage 3: Use a new connection to confirm the matched rule

1. Switch the client to Rule mode. Global and Direct modes aren't suitable for verifying this routing list.
2. Close existing connections from the target app, or close the relevant connection on the Connections page, then revisit the test domain.
3. Check the new connection's destination domain, destination IP, matched rule, and policy chain. Confirm whether it matched GEOSITE, GEOIP, or MATCH.
4. Change one setting at a time, reload, repeat the test, and record the result.

Existing connections won't choose a new route automatically when the database updates. Browsers may also reuse HTTP/2 or HTTP/3 connections, so refreshing a page may not create a new connection. If both the system proxy and TUN are enabled, first confirm the test app's traffic reaches the current core before treating a rule as faulty.

Common Issues: Download Failures, Missing Categories, and Rules That Don't Match

The database URL opens in a browser, but the core can't download it

The browser may be using a proxy, while the core's download route, DNS state, or available policies during startup may differ. These paths aren't necessarily equivalent. First check the actual download URL and failure stage in the logs: for connection timeouts, check the network path; for HTTP 404, check the published URL; for parse errors, check whether the download returned an HTML error page or the wrong file format.

On first startup, a missing database can also cause a dependency loop: rules need the database to load, while downloading the database depends on a proxy route that isn't available yet. You can retrieve the required files over a working network and place them in the actual working directory before starting the core. Keep the correct source URLs configured afterward so future updates can run.

The update succeeds, but a GeoSite category is reported as missing

This usually means the rule name doesn't match the data source. Check the category list published by the data provider, then verify the rule spelling and category attributes. Don't assume that a custom category name used by one subscription exists in every database, and don't try to fix the issue by changing the file extension.

A site in mainland China still matches MATCH

Check these in order: Is the domain included in the current GeoSite category? Did an earlier rule match first? Does the connection have only a domain while GeoIP uses no-resolve? Was the effective configuration overwritten by a subscription update? Only after confirming that the database really lacks the domain should you consider adding a narrowly scoped DOMAIN or DOMAIN-SUFFIX rule.

For the basics, see the glossary. To learn how DNS, rules, and the core work together, continue with the configuration guide. When troubleshooting, keep your original configuration and logs; you'll find the cause more easily than by changing the database, proxies, and DNS all at once.