How to Use Clash GeoIP and GeoSite: Database Updates and Rule References

What Problems Do GeoIP and GeoSite Solve?

GeoIP and GeoSite both reduce the need to maintain rules one by one in a configuration file, but they match connections using different criteria. GeoIP matches the country, region, or network group associated with the destination IP address. GeoSite matches the website category associated with the destination domain. One works with IP addresses and the other with domains; they are not two names for different formats of the same database.

When an application connects to a domain, Clash or Mihomo typically reads the connection metadata first, then evaluates the rule list from top to bottom. If a suitable domain condition exists, GeoSite can determine the policy during the domain stage. If earlier domain rules do not match, the core may continue resolving the destination and then pass it to GeoIP rules. Actual behavior also depends on the DNS mode, sniffing, rule order, and whether no-resolve is added.

GeoIP can handle requests that connect directly to an IP and can also cover addresses returned after domain resolution. However, cloud services and content delivery networks may serve the same website from nodes in different regions, and an IP registration location does not always reflect the service's actual base. GeoIP is therefore useful as one routing signal, not as the sole way to identify a website.

GeoSite classification is closer to answering “What type of service does this domain belong to?” A set may include the main domain, API domains, static asset domains, and content delivery domains. It is usually more complete than writing a single DOMAIN-SUFFIX rule, but coverage depends on how the database project is maintained. When a new domain appears, the rule will cover it only after the database is updated and reloaded by the client.

How to Write Clash GeoIP and GeoSite Rules

Rules belong in the rules section of the configuration and are evaluated in the order listed. Once a rule matches, the connection is handed to its specified policy group or built-in action, and later rules are not evaluated for that connection. Specific domain categories should therefore generally come before broad regional IP rules, with MATCH used last for traffic that remains unmatched.

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Node Selection

The first item is the rule type, the second is the category code in the database, and the third is the policy name or action. The example handles the advertising domain category first, then sends common mainland China domains directly, uses GeoIP for mainland China destination addresses not matched earlier, and finally passes all remaining connections to the policy group named “Node Selection.” Policy names in the configuration must exactly match those defined under proxy-groups, including capitalization, spaces, and punctuation.

When Should no-resolve Be Used?

A GeoIP rule can include the no-resolve parameter. A common form is:

rules:
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Node Selection

no-resolve means the rule should not actively resolve a domain to an IP just to evaluate that rule. If the current connection already includes a destination IP, GeoIP can still match it. If only a domain is available and no usable address has been obtained earlier, the rule is skipped. This helps control additional DNS queries and avoid certain resolution paths, but it also reduces GeoIP coverage for domain-only requests.

Whether to add this parameter should not be decided by copying an existing configuration. With Fake-IP, Redir-Host, TUN mode, or domain sniffing enabled, the connection information available to the core can differ. After making changes, inspect the destination host, rule type, and final matched rule in the connection details to confirm that traffic is routed as intended.

Database Files, Core Versions, and Compatibility

Different core branches and clients do not use exactly the same geodata files. Common files include Country.mmdb and other GeoIP data files for IP lookups, along with GeoSite.dat for domain classification. Mihomo also provides settings for geodata loading modes, automatic update intervals, and data sources. Always check the core version and client documentation for the exact filenames, default directories, and supported fields.

The classic Clash core, its successor branch Clash Meta known as Mihomo, and graphical clients built with Mihomo do not support exactly the same features. A configuration that recognizes GEOIP does not necessarily support the same GEOSITE categories, loader options, or newer database formats. When you see “unsupported rule type,” first verify which core the client is actually running rather than relying only on the client’s product name.

Find the Active Core and Data Directory

1. Check the About, core settings, or logs page in the client to confirm the core name and version.
2. Inspect the client’s configuration directory, not the directory containing the installer. Portable and system-installed versions may use different locations.
3. Search the startup log for GeoIP, GeoSite, mmdb, or geodata to confirm which file the core ultimately read.
4. If the client offers an “Update geodata” feature, record the file timestamps after the update and check the next startup log.

Do not confuse rule providers with geodatabases. rule-providers typically loads an independent rule set, which is then referenced through RULE-SET. GeoIP and GeoSite are queried by the core through their corresponding rule types. Both can exist in the same configuration, but their update entry points, cache files, and error messages are usually different.

How to Update GeoIP and GeoSite Databases

Updating a database is not as simple as downloading a file to any directory. The core reads only the path specified in the configuration or the data directory expected by the client, and an updated file is not used until the configuration is reloaded or the core is restarted. If the graphical client has a built-in update button, use that entry point first because it usually handles the download location, temporary-file replacement, and core reload.

Built-in Client Updates

1. First confirm that the current configuration starts normally, then export or copy a recoverable backup.
2. Open the core, configuration, or data management page and find the geodata update feature.
3. Wait for both GeoIP and GeoSite data to finish updating separately; do not force-quit the client while files are being written.
4. Reload the configuration or restart the core, then check the logs for a successful database loading message.
5. Use the connection list to check the matched rule for one known domain and one IP address from a known region.

Manually Replace a Database

Manual replacement is recommended only when the client has no update entry point or when a specific data version must be pinned. Stop the core completely first, confirm the old filename, directory, and configuration reference, then replace it with a new file serving the same purpose. Do not judge interchangeability by file extension alone: MMDB, DAT, and other compact rule formats organize data differently and must match the loading method supported by the current core.

If automatic updates are enabled, also check the update interval and data source settings. A successful automatic update only means that the file was retrieved and saved; whether it takes effect depends on the subsequent loading log. Long device sleep periods, a stopped client, an incorrect system clock, or network policies blocking update connections can all prevent scheduled tasks from running as expected.

How Often Should Databases Be Updated?

Geodata does not need to be updated before every connection. For a typical personal configuration, the client’s default interval is usually sufficient. If the rule project changes frequently or a new domain has recently gone uncategorized, run an update manually. On enterprise networks or fixed environments, test new data first to avoid changing the policies of a large number of connections because of classification changes.

Treat database versions and configuration rules as a single change record. If routing changes after an update, record at least the update date, core version, configuration version, and matched category code. This is necessary to determine whether the cause is the data, rule order, or core behavior.

Troubleshooting Order for Load Failures and Missed Rules

GeoIP and GeoSite issues usually appear in three forms: the configuration will not start, the database fails to load, or the configuration runs but connections do not match the expected rules. Each requires a different focus. Use the logs to identify which type of problem you have before changing the configuration.

1. Database File Not Found

Start by checking the complete path shown in the log and confirm that the account running the core has read access to the directory. When multiple clients coexist, it is easy to place the file in another client’s configuration directory. Also check filename capitalization; on case-sensitive filesystems, GeoSite.dat and geosite.dat may be treated as different files.

2. Invalid Format or Load Failure

This usually means the data file does not match the loader, the download is incomplete, or the core version cannot recognize the format. If restoring the old file lets the core start normally, compare the new file’s source type with the requirements of the target core. Do not try to fix a low-level file-format error by repeatedly changing rule names; the data has not reached the matching stage yet.

3. GeoSite Category Does Not Match

• Confirm that the logs do not report an unknown rule type or unknown category code.
• Check whether the domain is actually included in the target category in the current database version.
• Check whether an earlier DOMAIN, DOMAIN-SUFFIX, RULE-SET, or other GeoSite rule has already matched the connection.
• Check whether the destination domain is preserved in the connection details; domain classification cannot be completed when only IP information is available.
• Reload the configuration so the running core does not continue using an older version after the YAML has been saved in the interface.

4. GeoIP Region Does Not Match Expectations

First confirm that the connection details show the final destination IP, not a local Fake-IP, proxy node address, or DNS server address. Content delivery networks may route the same service to different regions, and the network registration shown in the database may differ from the physical data-center location. If a particular service must consistently use a specific policy, prefer a clear domain rule or a rule set with controlled coverage, and use GeoIP as a later fallback.

5. Results Change in TUN Mode

TUN mode can take over more traffic that does not follow system proxy settings, so the number of connections, protocol types, and visible destinations may change. Different matches after enabling TUN do not necessarily indicate a damaged database. Check DNS hijacking, the Fake-IP range, domain sniffing, and routing exclusions together. Record the connection details for the same destination first in ordinary system-proxy mode and then in TUN mode, and compare the domain, IP address, and matched rule.

How to Verify an Update

Verification should cover three layers, not just whether the client displays “Update complete”: file loading, rule parsing, and real-connection matching. First inspect the startup log to confirm that the current core read the database. Next check the configuration parsing result to confirm that the GeoIP and GeoSite categories and policy group names are valid. Finally generate test traffic and inspect the final rule and policy in the connection list.

Choose several targets for comparison: a domain that should match a specific GeoSite category, a connection made directly to an IP, and an ordinary domain that should not match a particular category. During testing, temporarily disable the browser’s proxy extensions and Secure DNS to reduce interference from extra routing paths. For terminal tests, also check whether HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY is set, as these variables change how requests enter Clash.

If the result differs from expectations, temporarily move the rule under test higher in a copy of the configuration. If it matches after being moved, the issue is probably rule order or an override. If it still does not match, check the category contents, destination information, and database loading. Restore a sensible order after troubleshooting; do not leave a broad rule at the highest priority just to handle one domain.

Stable GeoIP and GeoSite behavior depends on four conditions: the core supports the rule type, the database format matches the loading method, the rule order serves the routing goal, and the updated data has been reloaded by the running core. Checking these four layers in order is more effective than repeatedly swapping databases or copying an entire configuration.