GeoIP and GeoSite: Matching IP Addresses and Domains

Accurate Clash routing depends on both rule order and the data those rules reference. GeoIP groups IP address ranges by country or region, while GeoSite groups domains by site, service, or region. Both provide matching data; neither provides proxy nodes or decides whether a category should go direct or through a proxy.

For example, GEOIP,CN,DIRECT sends traffic direct when the destination IP matches the database's CN set. GEOSITE,cn,DIRECT sends it direct when the domain matches the cn category. If a site uses an overseas CDN, serves multiple regions, or shares IP addresses, the two rules can produce different results. That doesn't necessarily mean the database is corrupted—the rules match different things.

PropertyGeoIPGeoSite
MatchesDestination IPv4 or IPv6 addressDomain associated with the connection
Common filesgeoip.dat、Country.mmdbgeosite.dat
Example rulesGEOIP,CN,DIRECTGEOSITE,cn,DIRECT
Common mismatchIP location differs from service locationNew domain not listed or categorized differently

Data sources don't follow one universal standard

GeoSite commonly comes from v2fly/domain-list-community and derivative builds. GeoIP may be converted from various IP address datasets. MetaCubeX/meta-rules-dat provides builds suited to mihomo. Even files with the same name can differ in categories, coverage, and update schedules depending on their source. Before using a category such as geolocation-!cn, confirm that your data source includes it; don't assume a tag from another rule database is available.

Before You Configure: Confirm You're Using mihomo

The geodata-mode, geox-url, and automatic update settings below are for mihomo. Clash is a common name in the client ecosystem, but a similar interface doesn't mean the underlying cores support the same features. Older Clash cores may not support these fields, and the client version number is not a substitute for the core version.

  1. Check the About page, core information, or startup logs for the core name and full version. Confirm that it identifies as mihomo.
  2. Check which subscription config is active and whether overrides, merges, or scripts modify it.
  3. Back up the active config. Add global fields through the client's persistent override feature when available, so subscription updates don't overwrite your changes.
  4. Set the operating mode to Rule. Global and Direct modes don't use the routing rules below to select an outbound policy.

geox-url and Automatic Updates: Configuration You Can Add

Add the following snippet at the YAML top level, alongside rules and dns—not inside a proxy group. This example enables DAT-format GeoIP and uses release files from MetaCubeX. It sets database options only; it isn't a complete subscription with proxy nodes.

geodata-mode: true
geodata-loader: memconservative

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"
  • geodata-mode: true: Uses DAT mode for GEOIP. Set it to false to use MMDB mode. This option does not enable or disable GEOSITE.
  • geodata-loader: memconservative: Selects a geodata loader that uses less memory. It doesn't set the update interval or convert downloaded files to another format.
  • geo-auto-update: true: Enables automatic GEO data updates in the core. The core actually running must support this field.
  • geo-update-interval: 24: Sets the update interval to 24 hours—not 24 minutes, and not a scheduled run at midnight each day.
  • geox-url: Sets download URLs for each file type. MMDB and DAT files aren't interchangeable just by changing the file extension.

The example keeps an mmdb URL for a possible mode switch, but that doesn't mean every file is used every time the core runs. Which resources are downloaded and loaded depends on the effective config, rule references, and core implementation. If a file is already cached, changing its URL alone doesn't prove that an update occurred; run an update and check the logs.

Use a direct link to the database file

A custom URL must return a binary file in the expected format—not a repository homepage, sign-in page, or download instructions. GitHub release links may redirect, so your network setup must allow access to both the initial URL and the host serving the final file. If a download times out, check the destination and error in the logs before switching to a trusted data source.

Database downloads can also affect startup. If the core hasn't obtained the data needed for routing, rules that depend on it may fail to load. For a first-time setup, make sure the download URL is reachable; if needed, use the client's manual update feature or place the database files offline before loading a config with GEO rules. Don't assume download requests use the currently selected proxy node.

GEOIP and GEOSITE Rules: Categories and Proxy Groups Must Exist

Rules are evaluated from top to bottom, and the first match determines the policy. This snippet handles LAN addresses first, then domestic domains and categorized overseas domains, followed by domestic IPs, with a catch-all at the end. It assumes your config already has a proxy group named Proxy; replace it with the actual group name in your config before use.

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,Proxy
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

DIRECT is a built-in direct policy; Proxy is a user-defined name and must exactly match the proxy group. If your existing group is named PROXY, replace “Proxy” in both places. Don't add a second top-level rules field. Merge or replace the existing rule list, preserving any specific exceptions your subscription needs.

Why Put Overseas Domain Rules Before GEOIP

Suppose an overseas service's domain is categorized, but it resolves to a domestic CDN address. If GEOIP,CN,DIRECT matches first, the connection may go direct. Placing an explicit domain rule before the IP-location check lets you prioritize the service-level intent. However, geolocation-!cn is just a set defined in the database, not a complete list of every overseas website. Later rules still need to handle domains that aren't included.

no-resolve Doesn't Disable DNS

no-resolve means the IP rule won't actively resolve a domain just to evaluate that rule. If the connection already has a real destination IP, GEOIP can still check it. If it has only a domain and no real IP is available yet, the rule may be skipped and evaluation will continue. This option is neither a DNS leak protection setting nor a GeoIP auto-update switch. To resolve uncategorized domains at this rule, remove the parameter, but consider the impact on lookup latency and DNS routing.

Update Workflow: Load the Config, Update Files, Verify Matches

Database updates and subscription updates are separate. A subscription update usually fetches nodes and config; a GEO data update replaces classification files. A client reporting a successful subscription update doesn't mean that geosite.dat was updated.

  1. Check the effective config. Make sure the subscription or override mechanism hasn't replaced the auto-update fields or URLs in the YAML that actually loads.
  2. Reload the config. Check the logs for unknown fields, YAML indentation errors, missing categories, or proxy groups that can't be found.
  3. Run a GEO data update. Use the client's clearly labeled GEO data update option. If there isn't one, follow the client's documentation; don't treat the subscription update button as a substitute.
  4. Verify the result. Check the logs for download success or failure and note the modification time of files in the active data directory. A changed timestamp only shows that the file changed; you still need to check whether it loaded correctly.
  5. Start new connections. Visit a domestic domain, a categorized overseas domain, and a LAN address. Check each connection's rule type, matched content, and final policy in its details.

Test with new connections. Browsers may reuse connections, and long-lived app connections or existing sessions can keep using the old policy. Refreshing a page may not create a new connection. For troubleshooting, close and reopen the target app or disconnect only the relevant connection instead of interrupting everything.

Common Issues: Download Failures, Missing Categories, and Unexpected Routing

SymptomCheck firstWhat to do
Download times out or connection failsDNS resolution, outbound route, release-file redirectsRestore access to the file URL, then retry the update
Database parsing failsWhether the download is a web page and whether the format is correctGet the correct DAT or MMDB file
Category not foundWhether the current data source includes the referenced categoryChange the category or use a data build that includes it
Rule references a missing policyProxy group name and capitalizationSet the rule target to the exact name of an existing proxy group
Update succeeds, but routing stays the sameOperating mode, earlier rules, existing connectionsSwitch to Rule mode and check the first match using a new connection

Check the data directory before replacing files offline

Data directories vary between clients, and service mode may use a different location from regular user mode. Find the path through the client's directory option or the core's startup arguments; don't assume the files are in the installation folder. To replace files manually, stop the core using that directory, back up the old files, place correctly formatted databases there under the expected names, then restart and check the loading logs.

If only one domain is misrouted, you don't need to replace the entire database right away. Add a narrowly scoped DOMAIN or DOMAIN-SUFFIX rule before the relevant GEO rule, verify the result, and report the categorization issue to the data source. Specific exceptions are easier to remove if the database is corrected later.

Maintenance Boundaries: Check Rule Sets, DNS, and TUN Separately

  • rule-providers update independently. The interval for remote rule sets is usually in seconds—for example, 86400 means one day. By contrast, geo-update-interval: 24 is measured in hours. These settings control separate update mechanisms.
  • DNS determines what resolution data is available. GeoSite needs a domain associated with the connection. In fake-IP setups, mapping helps preserve domain information, but it can't turn every IP-only connection into a domain connection.
  • TUN determines which traffic is captured. Enabling TUN can capture more system traffic, but it won't fix database categories or change rule priority.
  • GEO data doesn't provide proxy nodes. A successful database download doesn't guarantee a working proxy; that still depends on your subscription, node status, and proxy group selection.

For reliable maintenance, confirm the core and effective config first, then verify the database source and update result, and finally check the match path using new connections. Keep domain exceptions specific, add an IP fallback where needed, and clearly separate the responsibilities of subscription updates and local overrides. This prevents the next update from restoring old behavior. For field definitions, see the mihomo general configuration docs. For categories and file coverage, see the MetaCubeX data repository.