GeoIP and GeoSite Database Update Guide: How to Fix GEOSITE Rules That Don’t Work

1. Understand the difference between GeoSite, GeoIP, and subscription updates

FlClash uses the mihomo core to process rules. Subscriptions provide configuration, proxies, and policy groups; GeoSite and GeoIP provide the category data referenced by rules. These are separate update paths: a successful subscription refresh does not mean the local databases are up to date, and a successful database download does not guarantee that a connection will match the intended rule.

GEOSITE,cn,DIRECT matches a domain category; it does not check whether a server is located in mainland China. GEOIP,CN,DIRECT matches the destination IP address; it does not identify which company owns a website. A service using different domains or CDN addresses can produce different results for these two conditions.

2. GEOSITE rules not working? First check that the configuration loaded

Open the configuration list in FlClash and make sure the intended configuration is active, then check the runtime log. Depending on the version, the relevant controls may be labeled “Configuration” or “Logs,” or shown as icons; this guide does not assume a specific menu layout. The original error in the log is more useful than repeatedly clicking Update.

Choose your next step based on what you see

• Configuration won’t activate: First resolve loading errors, such as invalid YAML indentation, a missing policy group, a missing database, or an unavailable category. Rule matching cannot be tested until the configuration loads successfully.
• Configuration is active, but traffic uses the wrong proxy: Confirm that Rule mode is selected, then check which rule the connection actually matched. Global and Direct modes do not apply the full ruleset as expected.
• Only some domains use the wrong route: Check whether the domain is included in the database and whether an earlier rule is matching first. Reinstalling the client should not be your first step.
• Updates time out or fail certificate checks: Check connectivity to the download host, the system date and time, and whether the update request depends on a proxy that is not yet available.

Keep these three details: the active configuration name, the proxy mode, and the complete error line from the log. Before sharing logs, redact subscription URLs, access tokens, and proxy credentials. “Update failed” alone is not enough to tell whether the remote server returned an error or the client failed to parse the data.

3. Update Geo databases manually in FlClash

A manual update can help when the initial load fails, the database has not been refreshed in a long time, or you have just changed data sources. First check which resource update options are available in your version: look in Settings for Geo data, geolocation data, or resource updates, and distinguish Geo data updates from subscription updates. Some versions combine multiple resources into one operation; others do not offer a separate update button.

1. Back up your configuration. Save the working configuration and any local overrides. Don’t rely on the subscription URL alone; locally added rules may not be included in the remote subscription.
2. Check the resource URLs. If you have set a custom Geo data URL, make sure it returns the relevant binary data file—not a download information page or login page.
3. Run the resource update. If the interface has a Geo data update button, run it once and wait for it to finish. Avoid starting several updates in a row, or it may be hard to tell which action produced each log entry.
4. Reload the configuration. After the update finishes, reload the active configuration. If needed, stop and restart the core so the running rules reload the databases.
5. Test with a new connection. Close the existing connection in your test page, then visit it again. Check the connection log for the matched rule and final proxy; don’t rely on results shown for an old connection.

If problems persist after a successful download, compare the logs from before and after the update. If the error changes from “download failed” to “category not found,” the network issue may be resolved. Next, check which categories the data source includes instead of continuing to change proxy ports.

4. Configure geox-url and automatic updates every 24 hours

This mihomo Geo data configuration uses public data releases from MetaCubeX. It is not a complete subscription and contains no proxy settings. Before merging it, check whether the existing configuration already defines these keys. They belong at the top level of the YAML file; don’t indent them under dns:, rules:, or a policy group.

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"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb"

• geo-auto-update: true: Enables automatic Geo data updates in mihomo.
• geo-update-interval: 24: The interval is in hours, so 24 means one day—not 24 minutes.
• geox-url.geoip: Sets the GeoIP source for DAT mode.
• geox-url.geosite: Sets the domain-category source used by GEOSITE rules.
• geox-url.mmdb: Sets the source for MMDB mode. This example enables DAT mode; it does not mean every GEOIP rule reads both file types.

FlClash may generate the final runtime configuration from the settings in its interface. After editing the original subscription, confirm that these fields make it into the configuration actually used by the core. Prefer the override or configuration-merge features in your version to avoid losing changes on the next subscription refresh. If the interface cannot show the runtime configuration, check the startup and update logs to confirm the options took effect.

Automatic updates require the client and core to be running, and the download source must be reachable. Don’t expect updates while the computer is off or Android has stopped the app in the background; this is not a system-level scheduled task. After restarting, check the update history instead of assuming the data is current just because the configuration says 24.

5. Missing categories: a successful download doesn’t mean rules can use the data

Different data maintainers may use different category names and cover different domains. If a configuration references a category unique to one data source, switching to another database may trigger a “category not found” error. Updating to the latest file only gets you the data available from that source; it does not add categories maintained elsewhere.

Check that the data source, category, and rule match

1. Copy the category name from the error log, including attribute filters such as @. Don’t record only the first part.
2. Check the current data source’s category index or documentation to confirm the category exists. A display name on a website is not necessarily the identifier used in rules.
3. Check which data source the subscription expects. If it depends on a specific collection, use compatible data rather than swapping in a smaller, trimmed version at random.
4. If the upstream source has removed or renamed the category, update the corresponding rule. If only a particular domain is missing, add a narrowly scoped domain rule.

When adding a temporary rule, use the full domain where possible. The example below affects only www.example.com and demonstrates an exact match. In practice, use a verified domain that should connect directly, and place the rule before any broader rules that could match first.

rules:
  - DOMAIN,www.example.com,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy outside mainland China

Proxy outside mainland China must be the name of a policy group that already exists in your configuration. If your group has a different name, use that instead. Don’t replace your subscription’s entire rules section with this example, or you’ll lose existing app-routing rules and exceptions.

6. Database updated, but rules still route traffic incorrectly? Check these in order

Check rule order first, then DNS and the destination address

mihomo evaluates rules in order; the first match determines what happens next. If a broader domain rule higher in the list already matches, a later GEOSITE rule won’t be evaluated. MATCH is the catch-all rule and usually belongs at the end. Moving it earlier will prevent later category rules from matching.

In the example above, no-resolve means this GEOIP rule won’t trigger a domain lookup just to find a match. If the connection has a domain name but no usable destination IP at that point, the IP condition may be skipped and matching can continue with the next rule. This is how the rule option works, not a database update failure. Check the connection’s domain, destination IP, and matched rule when troubleshooting.

TUN mode controls how traffic enters the core; it does not add categories to GeoSite. The system proxy only works for apps that respect it. If an app bypasses the system proxy, repeated database updates won’t change its route. First confirm on the Connections page that FlClash is receiving the request, then troubleshoot rule matching.

DNS caching and reused browser connections can also affect retests. After changing rules or loading new data, establish a new connection. If you also changed DNS or Fake-IP settings, clear the relevant cache using the method supported by your version. Don’t wipe all app data just to test a category update.

7. Update failures, rollback, and routine maintenance

Troubleshoot download errors by type

• HTTP 404: Check the filename, release path, and letter case. A release page URL is not a data file URL.
• Timeout or dropped connection: Check connectivity to the download host and any redirect targets. Being able to open a project homepage in a browser doesn’t mean the data file can be downloaded in full.
• Certificate validation error: Sync the system clock first, then check for a network sign-in page or local HTTPS inspection. Don’t disable certificate checks outright.
• Parsing fails after download: Check for a format mismatch, HTML returned in place of the file, an interrupted download, or data that is incompatible with the core.

If the core must download data before it can start, but downloading depends on the core’s proxy, break the loop by using an available network to fetch compatible data or choosing a source that can be reached directly. Don’t keep entering an unreachable URL in multiple fields, and don’t submit public subscription URLs to unknown online conversion services.

If the configuration won’t load after an update, restore the previously working data file or source and the corresponding configuration options. Stop the core before making changes, then reload it and keep the error log for comparison. If you changed sources, check the category names too; restoring the old file while leaving rules for a different set of categories won’t fix the problem.

Checklist for verifying an update

1. The configuration activates successfully, with no Geo data download or category loading errors in the log.
2. The automatic update options are present in the runtime configuration, and the interval is set in hours.
3. Test at least one domain that should connect directly and one that should use a proxy, and check the matched rule for each.
4. Retest with new connections and confirm the policy group selects the expected proxy.
5. Save the working configuration and data source so you can roll back and compare if something fails later.

The goal is to keep the rules, data source, and runtime configuration in sync. Identify whether the failure is in downloading, loading, or matching before changing anything. This usually gives you results you can verify more easily than changing DNS, TUN, and every rule at once.