1 典型症状：什么时候该怀疑地理库过旧
很多规则集依赖 GEOIP,XX 或 GEOSITE,tag 做「按地区 / 按站点类别」分流。地理库过旧时，常见现象包括：同一套配置以前正常，近期突然大量国内站走了代理，或反过来；流媒体解锁规则明明还在，却频繁命中错误策略；日志里 IP 归属与常识不符。注意：这类现象并不等价于地理库一定坏了——DNS 返回的解析结果、TUN 下 HTTPS 未嗅探到正确域名、规则顺序被 MATCH 提前截断，都会表现得像「GEOIP 失灵」。本文先帮你把地理文件这条线走通；若替换并校验后问题仍在，再按最后一节回到 DNS 与 Sniffer。
若你使用 fallback-filter 里带 geoip: true 的 DNS 逻辑，或 nameserver-policy 里写了 geosite:cn 一类条件，也同样依赖这些文件；更新地理库有时能一并缓解「解析路径乱跳」的错觉。更系统的 DNS 分层可对照《彻底防止 DNS 泄漏：Meta 内核 DoH + FakeIP 最佳实践》。
2 country.mmdb、geoip.dat、geosite.dat 分工
在 Mihomo 文档里，geodata-mode 控制「GeoIP 相关查询主要走 mmdb 还是 dat」：false 时往往以 country.mmdb（及同类 MaxMind 格式）为主；true 时则更多依赖 geoip.dat 这类二进制库。geosite.dat 则服务 GEOSITE 规则与部分 DNS 策略里的 geosite 条件。三者版本不必来自同一发布日，但长期不更新会导致网段与域名列表落后于现实网络，这是「规则写法没变、行为却变了」的经典诱因。
和 Rule Provider 的区别
Rule Provider 拉的是远程规则文本或二进制 ruleset，更新周期由 interval 决定；而 geoip.dat / geosite.dat / mmdb 是内核自带的「地理与站点字典」。两者都要维护，不能互相替代。流媒体域名细则可参考《ACL4SSR 规则订阅与 Rule Provider》。
geoip-lite.dat、country-lite.mmdb 体积极小，适合路由器或低配设备；若你需要更全的自定义类别或更少误杀，可在设备资源允许时改用完整发行包，并保持一致性（避免混用来源导致行为难以解释）。
3 常用下载源：meta-rules-dat 与镜像
MetaCubeX/meta-rules-dat 仓库为 Mihomo 生态常用的规则数据发布端，Release 或 CDN 镜像中通常提供 geoip.dat、geosite.dat、country.mmdb 及 lite 变体。文档与社区配置里也常见通过 jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/... 或 testingcf.jsdelivr.net 等前缀加速拉取。选择源时建议：固定一条你信任的主源，需要时再在 YAML 里改 geox-url 做切换，而不是在磁盘上手改文件名却忘了配置仍指向旧 URL。
另有 Loyalsoldier/v2ray-rules-dat 等社区数据集，部分用户会与 Meta 分支混用；一旦混用，请记录当前生效的到底是哪一套，避免排错时「看的是 A 仓库文档、磁盘上却是 B 数据」。开源仓库与发布页适合查变更说明与授权信息；安装包下载仍以本站为准，见文末引导。
4 文件应放在哪：工作目录与 GUI 数据目录
手动下载后，最常见做法是放到 Mihomo 的工作目录（与 config.yaml 同级或客户端指定的 home 目录），文件名与配置默认期望一致，例如 geoip.dat、geosite.dat、country.mmdb。Clash Verge Rev、FlClash 等图形客户端往往有独立的数据目录：若在资源管理器里复制了文件却未覆盖「内核实际读取的那份」，就会出现「我明明换了文件，日志里还是旧行为」的假象。排错时请在该客户端设置里确认 配置路径、内核工作目录、是否启用了多套配置档。
Linux 下若用 systemd 托管，工作目录常与 WorkingDirectory 或启动参数 -d 一致；可参考《Linux 安装 Mihomo 并开机自启》里的目录约定，把地理文件与配置放在同一层级，便于备份与版本对照。
5 在 YAML 里声明 geox-url 与自动更新
Mihomo 支持在配置顶层使用 geox-url 指定 geoip、geosite、mmdb（及 asn 等）的下载地址，并可用 geo-auto-update: true 与 geo-update-interval（小时）控制周期拉取。下面是一段示意（URL 请按你网络可达的镜像替换；示例与官方文档常见写法一致，便于对照）。
geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
geoip: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.dat"
geosite: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geosite.dat"
mmdb: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/country.mmdb"
若你更希望完全手动管控版本，可将 geo-auto-update 设为 false，仅在验证无误后自行下载 Release 再覆盖本地文件；这样升级节奏与你的规则集变更窗口一致，也便于出问题时的二分回滚。
6 手动替换：推荐操作顺序
- 备份：复制当前目录下的
geoip.dat、geosite.dat、country.mmdb（及你实际在用的 lite 版本）到单独文件夹，并记下修改日期。 - 停进程：退出 GUI 或
systemctl stop，确认无残留 mihomo 进程占用文件。 - 覆盖：从可信 Release 或镜像下载成对文件，保持文件名与配置期望一致；不要只换 geosite 却留下一年前 mmdb。
- 对表配置：若使用
geodata-mode: true，确认规则引用的 GeoIP 类别在你所选 dat 包中存在；否则日志会出现加载或匹配异常。 - 启动：用
mihomo -t或客户端内置校验先过语法，再启动内核。
7 重启后如何校验「真的换新了」
启动后将日志级别调到 info 或 debug，关注地理资源加载、下载、ETag 更新相关行（具体文案随版本略有差异）。其次，用一条你熟悉的规则做对照实验：例如访问某已知应走直连的国内域名，看日志中策略与解析是否一致；或对某应匹配 GEOSITE,netflix 的站点点名测试。若自动更新开启，也可在更新周期到达后观察文件时间戳是否变化。
外部控制器连接正常时，部分面板会展示规则命中路径；这与地理库是否最新相互印证。若需核对 HTTPS 场景下的域名识别，可结合《Clash Meta Sniffer：HTTPS 嗅探与 SNI 分流修正》检查是否因未嗅探到 SNI 而走了基于 IP 的 GEOIP，从而放大「库旧」或「解析错」的表象。
8 更新地理库后仍然「分流不生效」？
请按优先级复查：规则顺序是否被更靠前的 MATCH 或宽泛 DOMAIN-SUFFIX 吃掉；DNS 返回的 IP 是否导致 GEOIP 判到意外国家；TUN + TLS 场景下是否需要 Sniffer 或 override-destination；以及 策略组当前选中节点 是否本身错误。地理库只是拼图的一块，把它更新到最新后，剩下问题通常落回「规则与解析链路」本身。
9 总结
Clash Meta（Mihomo） 的 GEOIP / GEOSITE 与部分 DNS 策略，都依赖 country.mmdb、geoip.dat、geosite.dat 等地理数据。它们不会随你的机场订阅自动变新，长期忽略维护就容易出现分流误判或规则看似不生效。把下载源、文件名、工作目录、YAML 里 geox-url 与自动更新对齐，并在重启后用日志与固定用例校验，就能把这类问题从「玄学」拉回工程排错。
图形客户端把订阅、TUN、DNS 与内核参数放在同一套界面里管理，比纯手改文件更利于长期保持地理库与规则同步更新。若你希望找一款与 Mihomo 生态配合顺畅、又能快速回到本站获取安装包与教程的客户端，可从站内下载页挑选适合自己系统的版本；相比在多个镜像站之间来回找包，一体化入口在可重复安装与版本追溯上通常更省心。
最后仍建议保留「配置 + 地理文件」的压缩备份：每季度或每次大改规则后备份一次，出问题时整包回滚比单点猜文件要快得多。
