mihomo GeoIP 与 GeoSite 数据库：自动更新设置与规则写法

GeoIP 与 GeoSite：按 IP 和按域名分流

mihomo 是负责建立代理连接、解析 DNS 和执行规则的内核。Clash Verge Rev 等桌面客户端负责提供界面并管理内核。本文配置针对 mihomo，不应直接套用到不支持这些字段的旧版 Clash 内核。

GEOIP 与 GEOSITE 都是规则类型，但它们查询的对象不同。GeoIP 将 IP 地址段归入国家、地区或其他数据集分类；GeoSite 将域名归入站点、服务或主题分类。两者都依赖外部维护的数据文件，不是内核实时查询的在线地理服务。

比较项目	GeoIP	GeoSite
匹配对象	连接目标 IP 地址	内核已知的目标域名
常见规则	`GEOIP,CN,DIRECT`	`GEOSITE,cn,DIRECT`
常见文件	`geoip.dat` 或 `country.mmdb`	`geosite.dat`
典型局限	IP 所属地区不能代表网站所属服务	分类可能遗漏新域名，也不自动覆盖纯 IP 连接

例如，一个服务可能把内容部署在多个地区的 CDN 上。只看服务器 IP 所属地区，不一定能识别服务类别；先用 GeoSite 匹配域名，再用 GeoIP 补充处理其余连接，通常更容易表达分流意图。GeoIP 的结果也不能当作物理位置证明，数据更新频率和地址段归属调整都会影响结果。

数据库来源与文件格式：先确定加载模式

数据通常由社区项目整理并发布。常见来源包括 MetaCubeX 的 meta-rules-dat，以及其他维护域名和 IP 分类的项目。即使文件名同为 geosite.dat，不同发布者收录的分类名称、更新节奏和内容也可能不同。规则中的 cn、google 等名称必须实际存在于当前使用的数据集。

geodata-mode 决定 GeoIP 使用哪种格式

geodata-mode: true：GeoIP 使用 DAT 格式，读取 geox-url.geoip 对应的数据源。
geodata-mode: false：GeoIP 使用 MMDB 格式，读取 geox-url.mmdb 对应的数据源。
GEOSITE 使用 geosite.dat，不因 GeoIP 改用 MMDB 就自动停用。

文件扩展名并不是格式转换工具。把 MMDB 文件改名为 geoip.dat，不能让 DAT 加载器读取它。同样，规则集使用的 YAML、文本或 MRS 文件，也不能直接填写为 geox-url.geosite 的数据库地址。

自动更新配置：geox-url 与更新周期

下面使用 DAT 模式，数据来源为 MetaCubeX 的发布文件。示例中的地址是数据库来源，不是客户端安装包地址。将这几项写在配置的顶层，与 dns、rules 同级，不要缩进到某个策略组或 DNS 配置内部。

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：启用内核的 Geo 数据自动更新功能。
geo-update-interval: 24：更新周期为 24 小时，不是 24 秒。
geox-url.geoip：DAT 模式下的 GeoIP 数据来源。
geox-url.geosite：GeoSite 数据来源，供 GEOSITE 规则使用。

本例只设置实际使用的两种文件。若现有配置使用 MMDB，应保留 geodata-mode: false，并配置合适的 geox-url.mmdb，不要只修改下载地址却忘记切换加载模式。更新周期也不意味着每隔 24 小时内容必然变化：上游未发布新内容、下载失败或内核未持续运行时，结果都会不同。

在 Clash Verge Rev 中保存持久修改

打开「配置」，确认当前启用的是哪一份订阅配置。
使用客户端提供的合并配置或覆写功能写入上述顶层字段。不同版本的编辑入口名称可能不同，应查看最终生效配置确认结果。
重新加载配置；如更新任务或数据库状态未按预期改变，再重启内核并查看启动日志。
检查生效配置中是否只有一组明确的 geox-url，以及 geo-auto-update 是否仍为 true。

直接编辑订阅下载得到的文件，可能在下一次订阅更新时被覆盖。覆写还需要注意列表合并方式：某些操作会替换整段 rules，而不是在原列表后追加。开始修改前，先备份现有配置，并确认客户端当前采用的合并顺序。

GEOIP、GEOSITE 与规则执行顺序

以下片段展示一种常见顺序：先处理明确域名，再处理域名分类，最后处理 IP 分类和兜底。示例中的「节点选择」必须是现有配置里已经定义的策略组名称；若实际名称不同，需要同步修改。它是规则片段，不是包含节点、DNS 和监听端口的完整配置。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOSITE,google,节点选择
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,节点选择

mihomo 的普通规则按列表从上到下检查，命中后采用对应策略。因此，放在前面的显式域名规则可以覆盖后面的分类规则，而 MATCH 应放在最后作为兜底。若把 MATCH 放在首行，后面的 Geo 规则就没有机会决定这些连接的去向。

GEOSITE 分类名不是固定通用词典

GEOSITE,google,节点选择 表示使用当前数据库中的 google 分类。它不表示内核会自动收集所有包含该单词的域名。更换 GeoSite 来源后，应检查所用分类是否仍然存在；遇到分类不存在的加载错误，应修正规则或更换兼容的数据源，而不是反复切换节点。

GeoSite 匹配需要内核掌握域名。应用直接连接 IP，或接管链路没有保留、恢复出域名时，不能期待它仅凭目标 IP 命中某个站点分类。TUN 模式扩大的是流量接管范围，并不意味着每条连接都会带有可供 GeoSite 判断的域名。

no-resolve：避免规则为匹配主动解析域名

GEOIP,CN,DIRECT,no-resolve 中的 no-resolve 是规则参数。它告诉内核：执行这条 IP 规则时，不要仅为了判断 IP 归属而主动把目标域名解析为 IP。它不是全局关闭 DNS，也不是阻止应用、代理拨号或前面规则已经进行的解析。

连接状态	带 no-resolve	不带 no-resolve
目标已有可用的真实 IP	可以用已有 IP 判断归属	可以判断归属
只有域名，尚无可用真实 IP	不为本条规则主动解析，继续检查后续规则	可能触发解析，再判断归属
前面的域名规则已经命中	不会执行到本条规则	不会执行到本条规则

如果目标是减少不必要的本地解析，可以先用 GeoSite 覆盖主要域名，再给 GeoIP 补充规则加上 no-resolve。但代价是：未被域名规则覆盖、又没有真实目标 IP 的连接，可能直接落到后面的 MATCH。这属于规则设计结果，不应立即判断为 GeoIP 数据损坏。

如果希望剩余域名都先解析，再按 IP 地区决定是否直连，可以使用 GEOIP,CN,DIRECT。此时要同时审查 DNS 的解析路径、上游可达性和隐私需求。在 fake-ip 模式下尤其要区分虚拟地址与真实目标地址，不能把看到的 fake-ip 地址直接当作 GeoIP 应查询的公网地址。

验证更新与分流：配置、文件、连接分别检查

验证应分成三层。配置加载成功，只说明字段和所需资源通过了相应检查；数据库下载成功，只说明资源可取得；实际连接命中了预期规则，才说明本次分流达到了目标。不要只看客户端开关或网页是否能打开。

第一层：检查内核版本和配置语法

独立运行 mihomo 时，可以使用下面的命令。数据目录与配置路径必须指向实际使用的位置，否则测试的可能是另一套文件。桌面客户端通常有自己的工作目录，不要在内核运行期间用另一进程同时改写该目录。

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

-v 用于确认实际执行的内核版本；-t 用于测试配置。若提示未知字段或资源加载错误，应先确认内核是否为支持对应配置的 mihomo，再检查 YAML 缩进和数据源，不要仅凭客户端名称推断内核能力。

第二层：检查下载日志和实际工作目录

在客户端「日志」页查找与 Geo 数据加载、下载、更新有关的记录，关注超时、HTTP 状态和解析失败。
在内核实际工作目录检查 geoip.dat、geosite.dat，或 MMDB 模式下的对应文件，而不是只查看订阅文件所在目录。
记录更新前后的文件修改时间、文件大小与错误日志。修改时间变化可作为辅助线索，但不能单独证明分类内容发生变化。

第三层：通过新连接确认命中规则

将客户端切换到「规则」模式。全局模式或直连模式不适合验证这份分流列表。
关闭目标应用已有连接，或在「连接」页关闭对应连接，再重新访问测试域名。
查看新连接的目标域名、目标 IP、命中规则与策略链，确认命中的是 GEOSITE、GEOIP 还是 MATCH。
每次只调整一项配置，重新加载后重复测试，并记录结果。

旧连接不会因为数据库更新就自动重新选择路线。浏览器还可能复用 HTTP/2、HTTP/3 连接，因此刷新页面未必产生一条全新连接。若同时开启系统代理与 TUN，应先确认测试应用的流量确实进入当前内核，再判断规则是否异常。

常见故障：下载失败、分类缺失与规则不命中

数据库地址能在浏览器打开，内核却下载失败

浏览器可能使用了代理，而内核的资源下载路径、DNS 状态或启动阶段可用的策略不同，两者不能直接等同。先确认日志中的实际下载地址和失败阶段：连接超时优先检查网络路径；HTTP 404 优先检查发布地址；解析失败则检查是否下载到了 HTML 错误页或错误格式。

首次启动缺少数据库时，还可能出现依赖循环：规则需要数据库才能加载，数据库下载又依赖尚未可用的代理路径。可先在可达网络下取得相应文件，放入实际工作目录，再启动内核。手动放置文件后仍应保留正确来源配置，以便后续更新。

更新成功，但提示某个 GeoSite 分类不存在

这通常是规则名称与数据源不匹配。先核对数据发布项目提供的分类列表，再检查规则拼写和分类属性。不要把某个订阅使用的专有分类名当成所有数据库都具备的标准名称，也不要通过改扩展名尝试修复。

访问国内站点仍然命中 MATCH

按顺序检查：域名是否被当前 GeoSite 分类收录；前面是否已有其他规则抢先命中；连接是否只有域名而 GeoIP 又带有 no-resolve；最终生效配置是否被订阅更新覆盖。只有确认数据库内容确实缺失后，才考虑添加范围明确的 DOMAIN 或 DOMAIN-SUFFIX 规则。

需要补充基础概念时，可查看术语表；需要了解 DNS、规则与内核的配合，可继续阅读协议手册。排查时保留原配置和日志，比同时更换数据库、节点与 DNS 更容易定位问题。