mihomo GeoIP 与 GeoSite 数据库更新方法及规则写法

GeoIP、GeoSite 与规则集的区别

mihomo 分流时，规则决定匹配顺序，数据库提供匹配所需的分类数据。更新数据库不会自动改变规则顺序，也不会替换订阅节点。排查某个网站走错代理组时，应分别检查当前配置、数据库内容和连接实际命中的规则。

geodata-mode 选择的是 GEOIP 数据后端，并不表示关闭后就不能使用 GEOSITE。GeoSite 根据连接携带或内核取得的域名匹配；GeoIP 根据目标 IP 匹配。域名分类不能说明服务器的物理位置，IP 归属也不能保证某个服务应当直连。

rule-providers 则是另一套机制。它通常由 RULE-SET 引用，使用 YAML、文本或 MRS 等规则集文件，并拥有自己的更新配置。只更新 geosite.dat，不会顺带刷新所有规则提供者。

确认内核、数据来源与工作目录

本文配置针对 mihomo。历史 Clash 客户端可能搭载不同内核，不能仅凭界面名称判断兼容性。先在客户端的内核信息或启动日志中确认正在运行 mihomo；命令行部署可执行下面的命令，记录实际版本，再检查配置。

mihomo -v
mihomo -h

选择与规则标签一致的数据源

常见来源包括 MetaCubeX 的 meta-rules-dat 发布产物，以及 Loyalsoldier 的相关规则数据项目。不同项目可能使用不同上游、裁剪方式和分类名称。文件同名，不代表其中一定包含相同的 cn、github 或广告分类。

• 从数据项目的发布页确认产物格式，再复制实际下载地址。不要把网页地址保存成数据库。
• GeoIP 的 DAT 文件与 MMDB 文件不能通过改后缀互换。
• 精简版可减少存储与加载压力，但可能缺少已有规则引用的分类。
• 先保存一份能正常工作的配置和数据，再切换数据源，避免同时引入多个变量。

定位内核实际读取的位置

直接运行内核时，-d 指定工作目录，-f 指定配置文件。由 Clash 客户端启动时，应查看内核启动日志或客户端提供的数据目录入口。客户端安装目录、订阅保存目录和内核运行目录可能是三个不同位置。

mihomo -d /srv/mihomo -f /srv/mihomo/config.yaml

以上是 Linux 路径示例。此部署通常需要在 /srv/mihomo 中管理数据库；Windows 与 macOS 应使用日志显示的实际路径。Linux 文件名区分大小写，手动替换 MMDB 时尤其要核对 Country.mmdb 的拼写。

配置 geodata 自动更新

以下片段使用 MetaCubeX 发布的数据库，并选择 DAT 作为 GEOIP 后端。把这些字段合并到配置顶层；不要缩进到 dns、tun 或某个代理组内部。若已有 geox-url，直接修改原段落，避免重复键。

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：启用内核的地理数据库自动更新。
• geo-update-interval: 24：更新间隔为 24 小时，不是 24 秒。
• geox-url.geoip：DAT 格式 GEOIP 数据源。
• geox-url.geosite：GeoSite 数据源。
• geox-url.mmdb：MMDB 数据源；切换到 MMDB 后端时使用。

配置列出下载地址，不表示每次启动都会强制重新下载所有文件。实际加载和更新应以当前内核日志为准。保存后先验证配置，再通过客户端重载；若客户端对地理数据库另有管理机制，还应确认它是否覆盖这些字段。

首次启动若缺少数据库，内核可能需要先下载数据才能完成规则加载。此时若网络访问又依赖尚未启动的代理，就会形成启动依赖。可先通过可用网络准备本地文件，完成启动后再验证自动更新链路。

手动替换 GeoIP 与 GeoSite 文件

在下载受限、设备存储紧张或需要回退数据库时，手动更新更容易控制。不要直接向正在使用的目标文件持续写入，也不要只依赖文件名判断下载是否成功。

1. 记录运行参数。确认内核版本、工作目录、配置路径，以及 geodata-mode 当前值。
2. 保存旧文件。把当前可用的 geoip.dat、geosite.dat 或 Country.mmdb 复制到备份目录。
3. 下载到临时位置。检查 HTTP 下载是否成功、文件大小是否合理。若内容是登录页或错误页，应重新获取正确产物。
4. 停止内核后替换。退出客户端内核或停止对应服务，再把新文件放进实际工作目录；保持原文件名及正确的读取权限。
5. 测试并重新启动。使用相同工作目录验证配置，启动后检查数据库加载日志及新连接的匹配结果。

mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml

-t 用于配置测试，不等于完成一次真实的网站访问。测试需要读取的数据若缺失，也可能触发下载或报错。Linux 服务部署还要注意执行测试的账号与服务账号是否具有相同的目录访问权限。

替换文件不保证运行中的内核立即重新读取。停止后替换、再启动是较明确的操作流程。若新数据导致分类缺失或加载失败，恢复备份文件与原配置，再启动验证；不要同时更换内核、订阅和数据库后再寻找原因。

GEOIP 与 GEOSITE 规则写法

下面示例假定配置中已经存在名为 PROXY 的策略组。DIRECT 是内置直连策略。若实际代理组叫“节点选择”，应将示例中的 PROXY 替换为该名称；策略名称必须与配置一致。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - GEOSITE,github,PROXY
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

从上到下，首条命中

DOMAIN-SUFFIX 提供明确的域名例外；GEOSITE,github,PROXY 匹配数据库中的 GitHub 分类；GEOSITE,cn,DIRECT 匹配该数据源定义的 cn 域名集合；GEOIP,CN,DIRECT,no-resolve 再检查目标 IP；最后由 MATCH 处理剩余连接。

把 MATCH 放到最前面，后面的规则就不会获得匹配机会。把范围很大的分类放在精确例外之前，也可能让例外失效。域名规则通常应先于需要按 IP 判断的规则，但具体顺序仍要服从业务需求。

no-resolve 控制解析行为，不代表跳过 IP 匹配

no-resolve 表示不要仅为检查这条 IP 规则而主动解析目标域名。如果连接本来就有可用目标 IP，仍然可以进行 GEOIP 匹配。它不会关闭全局 DNS，也不是阻止 DNS 泄漏的独立开关。

例如，一个尚未解析的域名没有命中前面的 GEOSITE，遇到带 no-resolve 的 GEOIP 时，可能直接继续到后面的规则。若希望该域名始终直连，添加准确的域名规则通常比单纯去掉 no-resolve 更可控。

更新后仍未生效的排查顺序

用新连接验证，不只刷新页面

先确认处于规则模式，再打开客户端的连接记录，观察目标域名、目标 IP、命中规则和策略链。全局模式下，不能仅根据最终代理出口判断 GEOIP 或 GEOSITE 是否按预期参与分流。

浏览器可能复用已有的 HTTP/2 或 QUIC 连接。更改规则或数据后，应关闭旧连接并发起新请求；仅刷新同一个标签页，不一定会重新建立连接。验证时至少记录一个应直连域名、一个应走代理域名，以及一个已知 IP 目标的结果。

区分 DNS 问题与数据库问题

CDN、DNS 缓存和不同解析器可能让同一域名得到不同 IP，因此 GEOIP 结果变化不一定意味着数据更新失败。使用 TUN 或 fake-ip 时，还要查看内核识别出的域名及实际目标信息，不能把应用看到的合成地址直接当成公网归属地址。

稳定的维护顺序是：先确认正在使用的文件和内核，再验证规则分类，最后观察实际连接。数据库更新负责刷新分类依据；DNS、规则顺序和代理组选择仍需分别配置。更多基础概念可查阅概念速查，部署步骤可参照全平台指南。