规则数据 预计阅读 12 分钟

Clash GeoIP 与 GeoSite 使用方法：数据库更新和规则引用

解释两类地理数据库的用途、规则写法、更新流程与常见加载问题。

GeoIP 与 GeoSite 分别解决什么问题

GeoIP 和 GeoSite 都能减少配置文件中逐条维护规则的工作量，但二者判断连接的依据不同。GeoIP 根据目标 IP 地址所属的国家、地区或网络集合进行匹配；GeoSite 根据目标域名所属的网站分类进行匹配。前者面对的是 IP，后者面对的是域名，不能把两个名称理解成同一份数据库的不同写法。

当应用访问一个域名时，Clash 或 Mihomo 通常先取得连接元数据，再按规则列表从上到下匹配。如果规则中存在合适的域名条件，GeoSite 可以在域名阶段直接决定策略；如果前面的域名规则没有命中，内核可能继续解析目标地址，再交给 GeoIP 规则判断。实际行为还会受到 DNS 模式、嗅探、规则顺序和是否添加 no-resolve 的影响。

目标 IP 分类

GEOIP

根据目标 IP 所属集合匹配连接，常用于地区分流和最终阶段的网络归类。

目标域名分类

GEOSITE

根据域名类别匹配连接，可表达站点、服务类型和组合分类等规则集合。

GeoIP 的优点是能够处理直接连接 IP 的请求，也能覆盖域名解析后的地址。不过，云服务和内容分发网络会让同一个网站使用不同地区的节点，IP 注册地也不一定等于业务归属地，因此 GeoIP 适合作为分流依据之一，而不是网站身份的唯一判断标准。

GeoSite 的分类更接近“这个域名属于哪类服务”。例如，某个集合可以包含主域名、接口域名、静态资源域名和内容分发域名。它通常比只写一条 DOMAIN-SUFFIX 更完整，但分类结果取决于数据库项目如何维护；新域名出现后，只有数据库更新并被客户端重新载入，规则才能覆盖它。

Clash GeoIP 与 GeoSite 规则写法

规则放在配置文件的 rules 段中，并按照出现顺序匹配。命中一条规则后，连接会交给该规则指定的策略组或内置动作，后面的规则不再处理这次连接。因此，具体的域名分类通常放在宽泛的地区 IP 规则之前，最终再使用 MATCH 处理尚未命中的流量。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

第一项是规则类型，第二项是数据库中的分类代码，第三项是策略名称或动作。上例先处理广告域名分类，再让常见中国大陆域名直连，然后以 GeoIP 处理此前未命中的中国大陆目标地址，最后把其余连接交给名为“节点选择”的策略组。配置中的策略名称必须与 proxy-groups 里定义的名称完全一致，包括大小写、空格和标点。

no-resolve 应该何时使用

GeoIP 规则可以增加 no-resolve 参数，常见写法如下：

rules:
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,节点选择

no-resolve 表示不要为了执行这一条规则而主动把域名解析成 IP。如果当前连接已经带有目标 IP，GeoIP 仍然可以匹配；如果只有域名，并且此前没有获得可用于判断的地址，这条规则会被跳过。它适合用来控制额外 DNS 查询和避免某些解析链路，但也会降低 GeoIP 对纯域名请求的覆盖率。

是否添加该参数不能只看现成配置。使用 Fake-IP、Redir-Host、TUN 模式或域名嗅探时，内核能够取得的连接信息并不完全相同。修改后应观察连接详情中的目标主机、规则类型和最终命中项，确认实际流量是否按预期分流。

数据库文件、内核版本与兼容边界

不同内核分支和客户端使用的地理数据文件并不完全相同。常见文件包括供 IP 判断使用的 Country.mmdb、GeoIP 数据文件，以及供域名分类使用的 GeoSite.dat。Mihomo 还提供地理数据加载模式、自动更新周期和数据地址等配置能力。具体文件名、默认目录与可用字段应以内核版本和客户端文档为准。

经典 Clash 内核、Clash Meta 的后续分支 Mihomo，以及集成 Mihomo 的图形客户端，支持范围存在差异。某份配置能识别 GEOIP，不代表它一定支持相同的 GEOSITE 分类、加载器选项或新格式数据库。遇到“规则类型不支持”时，首先应核对客户端实际使用的内核，而不是只看客户端界面名称。

查看实际内核与数据目录

  1. 在客户端的关于、内核设置或日志页面确认内核名称与版本。
  2. 检查客户端配置目录，而不是安装程序所在目录。便携版和系统安装版的位置可能不同。
  3. 在启动日志中搜索 GeoIP、GeoSite、mmdb 或 geodata，确认内核最终读取了哪个文件。
  4. 如果客户端提供“更新地理数据”功能，记录更新完成后的文件时间和下一次启动日志。

不要把规则提供者与地理数据库混为一谈。rule-providers 通常加载独立的规则集合，再通过 RULE-SET 引用；GeoIP 和 GeoSite 则由内核按对应规则类型查询地理数据。二者可以同时存在于一份配置中，但更新入口、缓存文件和错误信息通常不同。

GeoIP 与 GeoSite 数据库更新流程

数据库更新不是把文件下载到任意目录即可。内核只会读取配置指定的位置或客户端约定的数据目录，更新后的文件也需要在重新载入配置或重启内核后才会被使用。图形客户端如果内置更新按钮，优先使用该入口，因为它通常会处理下载位置、临时文件替换和内核重载。

客户端内置更新

  1. 先确认当前配置能够正常启动，并导出或复制一份可恢复的配置。
  2. 进入内核、配置或数据管理页面，找到地理数据更新功能。
  3. 等待 GeoIP 与 GeoSite 两类数据分别完成，不要在写入过程中强制结束客户端。
  4. 重新载入配置或重启内核，查看日志是否出现数据库加载成功信息。
  5. 使用连接列表检查一条已知域名和一条已知地区 IP 的命中规则。

手动替换数据库

只有在客户端没有更新入口，或需要固定数据版本时，才建议手动替换。操作前先完全停止内核，确认旧文件名、目录和配置引用，再用相同用途的新文件替换。不要仅凭扩展名判断文件是否可互换：MMDB、DAT 和其他紧凑规则格式采用不同的数据组织方式，必须与当前内核的加载方式对应。

如果客户端启用了自动更新，应同时检查更新周期和数据来源配置。自动更新成功只表示文件获取与保存完成，最终是否生效还要看后续加载日志。设备长时间休眠、客户端未运行、系统时间异常或网络策略阻止更新连接，都可能导致定时任务没有按预期执行。

更新频率如何确定

地理数据不需要在每次连接前更新。对于普通个人配置，按客户端默认周期更新通常足够；如果规则项目变更频繁，或近期出现新域名无法分类，可以主动执行一次更新。企业网络或固定环境更应先测试新数据，避免分类调整改变大批连接的策略。

数据库版本和配置规则应作为一组变更记录。更新后如果出现分流变化，至少需要知道更新日期、内核版本、配置版本和命中的分类代码，才能判断问题来自数据内容、规则顺序还是内核行为。

加载失败与规则不命中的排查顺序

GeoIP 或 GeoSite 问题通常表现为三类：配置无法启动、数据库加载报错、配置可以运行但连接没有命中预期规则。三类问题的检查重点不同，应先从日志确定属于哪一种，再修改配置。

一、提示找不到数据库文件

先核对日志中的完整路径，确认运行内核的账户对目录具有读取权限。多个客户端共存时，很容易把文件放入另一个客户端的配置目录。还应检查文件名大小写；在区分大小写的文件系统中，GeoSite.dat 与 geosite.dat 可能被视为不同文件。

二、提示格式无效或加载失败

这通常意味着数据文件与加载器不匹配、文件下载不完整，或内核版本无法识别该格式。恢复旧文件后若能正常启动，可以进一步确认新文件的来源类型和目标内核要求。不要通过反复修改规则名称来处理底层文件格式错误，因为规则尚未进入匹配阶段。

三、GeoSite 分类没有命中

  • 确认日志没有报告未知规则类型或未知分类代码。
  • 检查该域名是否确实收录在当前数据库版本的目标分类中。
  • 检查前面是否已有 DOMAIN、DOMAIN-SUFFIX、RULE-SET 或其他 GeoSite 规则提前命中。
  • 查看连接详情中是否保留目标域名；只有 IP 信息时，域名分类无法完成判断。
  • 重新载入配置，避免界面已经保存 YAML，但运行中的内核仍使用旧配置。

四、GeoIP 地区判断与预期不一致

先确认连接详情显示的是最终目标 IP，而不是本地 Fake-IP、代理节点地址或 DNS 服务器地址。内容分发网络会把同一服务调度到不同地区，数据库的网络归属也可能与实际机房位置存在差异。如果特定业务必须稳定走某个策略，优先使用明确的域名规则或维护范围可控的规则集，再把 GeoIP 作为后续兜底。

五、TUN 模式下结果发生变化

TUN 模式能接管更多不遵循系统代理设置的流量，因此连接数量、协议类型和可见目标会变化。开启 TUN 后出现不同命中结果，并不一定是数据库损坏。应同时检查 DNS 劫持、Fake-IP 范围、域名嗅探和路由排除项。先用同一目标分别记录普通系统代理与 TUN 模式的连接详情，再比较目标域名、目标 IP 和命中规则。

更新后的验证方法

验证不能只看客户端是否显示“更新完成”。完整检查应覆盖文件加载、规则解析和真实连接命中三个层次。第一步查看启动日志，确认数据库已被当前内核读取；第二步检查配置解析结果，确认 GeoIP、GeoSite 分类与策略组名称有效；第三步产生测试流量，并在连接列表中查看最终规则和策略。

建议选择几类目标进行对照：一个应由明确 GeoSite 分类处理的域名、一个直接访问 IP 的连接、一个不会命中特定分类的普通域名。测试期间暂时关闭浏览器自身的代理扩展和安全 DNS，减少额外链路对结果的干扰。终端测试还要确认是否设置了 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，这些变量会改变请求进入 Clash 的方式。

如果规则结果与预期不同，可以在配置副本中暂时把待测规则移动到更靠前的位置。若移动后能够命中，问题多半是顺序或覆盖关系；若仍不命中，再检查分类内容、目标信息和数据库加载。定位完成后应恢复合理顺序，避免为了单个域名让宽泛规则长期占据最高优先级。

GeoIP 与 GeoSite 的稳定使用依赖四个条件：内核支持对应规则类型，数据库格式与加载方式一致，规则顺序符合分流目标，更新后的数据已经由运行中的内核重新载入。按这四层逐项检查，比反复更换数据库或复制整套配置更容易找到原因。

下载Clash