先分清：IP 归属库、域名分类库与订阅

节点订阅更新成功，不代表分流数据库也已更新。订阅通常提供节点、策略组及规则；GeoIP 与 GeoSite 则是内核读取的本地数据文件。出现“某个域名突然走了兜底规则”，应分别检查规则顺序、分类是否存在、数据库是否加载，而不是反复点击订阅更新。

本文以 mihomo 内核为对象。原版 Clash、部分旧版 Premium 与当前 mihomo 的字段支持范围不同，不能把下面的配置直接套到所有名为 Clash 的程序中。先在客户端的内核信息或启动日志中确认实际内核；使用命令行时，可执行 mihomo -v 查看版本信息。

文件存储内容主要使用位置
Country.mmdbIP 地址与国家或地区映射geodata-mode: false 时的 GeoIP 查询
geoip.dat按标签组织的 IP 网段集合geodata-mode: true 时的 GeoIP 查询
GeoSite.dat按标签组织的域名集合GEOSITE 规则及相关域名匹配

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

来源要与分类标签一起选择

mihomo 常用的数据来源包括 MetaCubeX 的 meta-rules-dat 项目。域名分类也常见于 domain-list-community 及其衍生构建，IP 分类则有不同的 GeoIP 构建项目。这里的关键不是选一个下载最快的文件，而是确认它采用的格式、包含的标签，以及维护者的发布说明。

  • 规则写了 GEOSITE,cn,DIRECT，域名库就必须提供 cn 分类。
  • 规则写了某个服务名，不代表每个来源都会收录同名分类；换库后要重新测试配置。
  • 不要把纯文本域名列表、规则集 YAML 或下载失败的 HTML 页面保存为 GeoSite.dat。
  • 来源一致能降低分类差异，但仍应查看更新说明；数据更新可能改变命中结果。

找内核目录，不猜安装目录

图形客户端的程序目录、配置目录和内核数据目录可能不同。Windows 上内核还可能由服务进程启动，读的是服务使用的目录，而不是当前用户手动运行程序时的目录。优先在启动日志查找配置加载、数据库加载或下载路径；客户端若提供“打开配置目录”，也要继续确认其中是否就是内核正在使用的数据文件。

命令行部署可以用 -d 明确指定工作目录。例如下面的命令将数据目录固定为当前用户的 .config/mihomo，并从该目录读取配置。路径需要提前存在，且其中已有可用的 config.yaml。

mihomo -d "$HOME/.config/mihomo" \
  -f "$HOME/.config/mihomo/config.yaml"

该示例适用于类 Unix Shell，不是所有客户端的默认路径。Linux 文件名区分大小写：发布资产可以叫 geosite.dat，落盘时仍应按内核预期使用 GeoSite.dat；同理注意 Country.mmdb。找错目录时，替换一百次也只是更新了一个无人读取的文件。

手动替换：先备份，再测试，再重启

适合手动更新的场景包括离线设备、自动下载失败、需要固定数据版本，或刚切换数据库来源。不要在客户端持续下载数据库时同时覆盖文件；先退出客户端或停止对应服务，并确认内核进程已经结束。

  1. 记录当前模式。查看最终生效配置中的 geodata-mode。值为 false 时，GeoIP 使用 MMDB；值为 true 时，GeoIP 使用 DAT。GeoSite 仍单独使用域名库。
  2. 保留回退文件。将需要替换的旧文件备份，记录来源和下载日期，不要直接删除唯一可用副本。
  3. 下载到临时文件。确认 HTTP 请求成功，再放入内核工作目录。不要让半个下载文件占据正式文件名。
  4. 测试完整配置。测试必须使用与正式运行相同的内核、配置文件和数据目录。
  5. 重新启动内核。仅刷新界面或重新打开连接页面，不一定触发数据库重载。随后查看启动日志及实际命中规则。

下面以 Bash 更新 GeoSite.dat 为例，假设数据目录已确认且内核已停止。其余数据库按实际模式分别处理，不要只换后缀。

cd "$HOME/.config/mihomo" || exit 1

if [ -f GeoSite.dat ]; then
  cp -p GeoSite.dat GeoSite.dat.bak || exit 1
fi

curl --fail --location --retry 2 \
  --output GeoSite.dat.new \
  "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" \
  && mv GeoSite.dat.new GeoSite.dat

mihomo -t -d "$PWD" -f "$PWD/config.yaml"

curl --fail 能让常见 HTTP 错误返回失败，但不能证明文件内容一定正确。真正的格式与分类验证仍由内核完成。测试失败时先保留报错，再恢复备份；如果旧文件存在，可执行 cp -p GeoSite.dat.bak GeoSite.dat，随后重新测试。只有测试通过后才启动服务。

自动更新：geox-url 与更新间隔

在支持这些字段的 mihomo 中，geox-url 指定下载源，geo-auto-update 控制周期更新，geo-update-interval 的单位是小时。只配置下载地址，不等于已经打开定期更新。下面是顶层配置片段，需合并进已有配置，不是包含节点与策略组的完整配置文件。

# 顶层字段，与 dns、rules 同级
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"
  • geoip 对应 geoip.dat；本例启用 DAT 模式，GeoIP 规则使用它。
  • geosite 对应 GeoSite.dat；GEOSITE 域名分类依赖它。
  • mmdb 对应 Country.mmdb；切回 MMDB 模式时使用。列出来源不代表每次都要下载全部文件。
  • 24 表示 24 小时，不是每天零点，也不是 24 分钟；设备休眠或内核退出时不能按常驻服务的方式期待更新。

首次加载缺失文件时可能触发下载。若下载本身依赖尚未加载的分流规则或尚未可用的代理，就会形成启动依赖问题。此时先手动放入一套可用数据库，再排查更新链路，比在失败日志中无限重启更直接。

规则写法：GEOSITE 在前，GEOIP 在后

域名规则按域名分类，IP 规则按目标地址分类，两者回答的是不同问题。“这是某项服务的域名”不等于“它的服务器一定在某个国家或地区”。网站可能使用境外 CDN，也可能为同一域名返回多个地区的地址，所以通常先写明确的域名规则，再写较宽泛的 IP 规则，最后保留 MATCH。

下面假定现有配置已经定义名为 PROXY 的策略组。该名称区分大小写，实际使用时要与自己的策略组完全一致；不要只复制规则却漏掉它引用的出站。

mode: rule

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

逐条理解匹配行为

  1. DOMAIN-SUFFIX 是明确域名例外，放在分类规则前，避免先被宽泛集合命中。这里的 example.com 仅用于展示语法。
  2. GEOSITE,cn,DIRECT 匹配域名库中的 cn 分类，不需要先把域名解析成真实 IP 才能进行域名集合判断。
  3. GEOIP,private,DIRECT,no-resolve 使用私有地址分类；该标签需得到所选数据源支持。MMDB 模式下不要假定与 DAT 模式拥有完全相同的标签。
  4. GEOIP,CN,DIRECT 根据目标 IP 判断归属。对只有域名的连接，它可能触发解析。
  5. MATCH,PROXY 接住前面未命中的连接。它不是“自动识别”，只是最后一条兜底。

no-resolve 不是 DNS 防泄漏开关

no-resolve 表示不为了匹配这一条 IP 规则主动解析域名。如果连接已有可用目标 IP，规则仍可能匹配；如果只有域名而没有适用 IP，则继续检查后续规则。将所有 GEOIP 规则都加上它，可能让原本依赖解析结果的直连规则失效，更多连接落到 MATCH。

fake-ip 模式也不会让 GeoSite 失去作用。内核能通过 fake-ip 映射关联域名，但这不代表 GEOIP 应拿 198.18.0.0/16 范围里的合成地址当作服务器真实归属。排查时应结合域名、实际解析结果与命中规则看问题，不能只盯连接列表中的一个地址。

更新后仍不命中：按日志拆分问题

现象优先检查处理动作
启动时报分类不存在规则标签与库的来源不一致查看该来源的分类清单，修正规则或换回原库
解析数据库失败文件格式错误、下载不完整或内容是网页恢复备份，重新下载临时文件并执行配置测试
日志仍提示下载缺失文件目录、大小写或实际运行账号不对确认内核启动参数及服务工作目录
定时更新下载超时下载域名解析、网络路径与代理可用性先手动更新恢复启动，再独立测试下载链路
数据库加载成功但走兜底规则顺序、分类内容或连接缺少域名查看该连接的规则命中信息，不只看出口 IP

建议每次只改一个变量：先更新文件并保持规则不动，确认能启动；再调整规则顺序；最后才切换 geodata-mode 或数据来源。将三项一起修改，日志会变得很热闹，定位却不会更快。

验证时先确认客户端处于规则模式，再关闭目标应用的旧连接，重新发起请求。已有 TCP 连接通常不会因为规则或数据库改变就自动迁移出口；浏览器连接复用也会干扰观察。测试可用自己正在排查的域名，并在连接记录中核对命中的规则类型、规则内容与最终策略链。

若临时提高日志等级，排查结束后应恢复原设置；分享日志前隐藏订阅地址、访问令牌、节点凭据及控制接口密钥。数据库问题需要的是加载路径和报错行，不需要整份账号资料。

维护记录：保留能回退的一套组合

  • 记下内核信息：记录 mihomo -v 输出，避免客户端升级后仍按旧内核判断字段支持。
  • 记下数据来源：记录仓库、下载日期、使用的标签与 geodata-mode，便于解释命中变化。
  • 保留可运行配置：备份数据库时同时保存对应配置，回退才不会留下新规则引用旧分类的问题。
  • 分别检查两条更新链路：订阅负责节点与配置，地理数据更新负责分类文件；两者的成功提示不能互相代替。

最终验收只需盯住三个结果：内核能加载正确目录里的文件、规则引用的分类确实存在、新建连接命中预期策略。满足这三项后，再考虑更新频率和下载来源优化。数据库越新不必然越符合个人分流需求，明确规则始终应该留在宽泛分类之前。