GeoIP 与 GeoSite 数据库更新方法：geox-url 配置与规则调用写法

先分清 GeoIP、GeoSite 与规则集

网站走错出口，不一定是节点故障。分流链条里至少有三处会影响结果：连接携带的域名或目标 IP、配置里的规则顺序，以及规则所引用的数据。更新 Geo 数据只处理最后一项，不能替代 DNS 排查，也不会自动把新规则插入配置。

本文以使用 mihomo 内核的 Clash 客户端为对象。Clash 是客户端生态中的常用名称，不代表所有内核都支持同一套字段；旧版 Clash 内核不能直接照搬本文的 GEOSITE 与自动更新配置。操作前先在客户端的内核信息中确认实际运行的是 mihomo，而不只看窗口标题。

GeoSite 的分类不是实时识别网站用途，而是数据维护者整理的域名列表。GeoIP 也不是精确定位工具：云服务、CDN、跨境调度和 IP 地址转移，都可能让地理分类与访问意图不一致。对重要业务，明确的域名规则通常比单纯按国家划分 IP 更可控。

geox-url 配置：下载来源与自动更新间隔

下面是用于合并进现有配置的顶层片段，不是包含节点的完整订阅。它选择 GeoIP DAT 模式，指定 GeoIP、GeoSite 和 MMDB 的下载地址，并启用每 24 小时一次的 Geo 数据自动更新。示例来源为 MetaCubeX 的 meta-rules-dat 发布资产；实际使用前，应确认当前网络能够访问这些地址。

geodata-mode: true
geodata-loader: memconservative

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"

逐项看字段，避免把小时写成秒

• geodata-mode: true：让 GEOIP 使用 GeoIP DAT 数据；设为 false 时使用 MMDB 数据。这个开关不是启用或禁用 GeoSite 的总开关。
• geodata-loader: memconservative：选择较节省内存的 DAT 加载方式。它不负责改变规则优先级，也不是下载加速开关。
• geo-auto-update: true：启用内核的 Geo 数据定时更新；客户端还可能另有手动更新入口。
• geo-update-interval: 24：单位是小时，即 24 小时，不是 24 秒。内核运行期间执行定时任务，电脑关机时不会继续下载。
• geox-url：指定来源。只修改地址不等于当前正在使用的数据已经被替换，需要实际完成一次更新与加载。

示例同时保留 mmdb 地址，便于以后切换 GeoIP 数据模式；它不表示一次 GEOIP 判断会同时查询 DAT 与 MMDB。对于只使用国家代码的 MMDB 数据，也不能照搬其他 DAT 数据源才有的自定义分类名。

订阅客户端里如何持久保存更新设置

许多客户端会把远程订阅下载后再生成运行配置。直接编辑生成文件，可能暂时生效，却在下次订阅更新时被覆盖。应先分清“订阅原文”“客户端覆写”和“内核最终配置”这三个位置。

1. 记录当前环境。在客户端内核信息或启动日志中记下 mihomo 版本、当前配置名称，以及 Geo 数据所在目录。文件目录以客户端提供的“打开配置目录”或同类入口为准，不要把另一款客户端的路径直接套过来。
2. 备份可工作的设置。保留当前覆写内容与旧数据库。涉及订阅链接、节点密码的文件只留在本地，不要贴到公共讨论区。
3. 写入持久化层。如果客户端提供 Merge、覆写或扩展配置，应在该功能中合并上面的顶层字段；如果使用自行维护的本地 YAML，则直接编辑该文件。
4. 检查最终配置。重载后确认实际运行配置中保留了 geodata-mode、geox-url 和更新间隔。只在编辑器中看见字段，还不能证明它已经送进内核。
5. 触发一次更新。使用客户端提供的 Geo 数据更新功能，并观察内核日志。不同客户端菜单命名不同，不应把“更新订阅”当作“更新 Geo 数据”的同义操作。

若客户端没有 Geo 数据更新按钮，可以先保留自动更新设置，或使用下文的离线替换流程。首次缺少必要数据时，内核可能尝试下载文件；如果这时可用代理尚未建立，就会出现“需要数据才能启动，下载数据又需要代理”的启动依赖。离线准备数据往往比反复重启更直接。

GEOIP 与 GEOSITE 的正确调用写法

下面的规则片段假定现有配置中已经有一个名为 代理选择 的策略组。若实际组名不同，必须同步改写；DIRECT 是内置直连策略，不需要自行创建。请把片段合并到已有的 rules 中，而不是再添加第二个 rules 键。

mode: rule

rules:
  - DOMAIN,example.com,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,代理选择
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,代理选择

从上到下，先命中先结束

DOMAIN,example.com,DIRECT 是精确域名规则，用于展示单站例外应放在大类规则之前。随后两条 GeoSite 规则按域名分类选择出口。示例中的 cn 与 geolocation-!cn 需要当前数据源确实提供；更换精简数据库后，应重新检查分类是否保留。

GEOIP,CN,DIRECT,no-resolve 则检查已知目标 IP 是否属于 CN 分类。尾部的 no-resolve 表示不要为了这一条 IP 规则额外发起域名解析；如果连接已经具有可用目标 IP，仍然可以参与匹配。它不是“关闭 DNS”，也不会让所有请求跳过 DNS 模块。

最后的 MATCH 接住前面没有命中的连接。若它被放在第一行，后面的 GeoSite 和 GeoIP 规则就没有机会运行。规则模式之外，全局模式会按全局策略转发，无法用来验证这份分流顺序。

域名缺失时，GeoSite 不会自动补齐

如果应用直接连接 IP，或者流量进入内核时没有可关联的域名，GeoSite 规则可能无法命中。TUN 只是一种流量接入方式，不代表所有连接都天然携带域名。此时要检查 DNS 是否经过预期路径、Fake-IP 映射是否有效，以及是否需要并正确启用了嗅探；不要仅靠反复更换 GeoSite 文件解决信息缺失。

更新后怎么确认真正生效

“下载完成”“文件已替换”和“新连接命中新数据”是三个不同检查点。只看到文件修改时间变化，不足以证明新数据已经被当前内核加载；只看到某网站能打开，也不能证明它走了预期出口。

1. 确认下载与加载结果。检查更新动作之后的日志，区分网络超时、下载失败、数据解析失败和分类不存在。日志原文因内核版本而异，应记录具体报错与时间。
2. 确认运行模式和规则。切到规则模式，在最终配置中确认 Geo 规则位于 MATCH 前面，目标策略组名称确实存在。
3. 重新建立测试连接。关闭测试应用的旧连接，再发起请求。已经建立的 TCP 连接通常不会因为数据库更新而自动迁移到另一条代理链。
4. 查看连接详情。核对目标域名、目标 IP、命中规则和实际出口。若显示命中前置的 DOMAIN-SUFFIX，就说明本次连接没有走到后面的 Geo 规则。

排查时可以临时提高日志详细程度，完成后恢复常用级别，避免长时间记录大量连接信息。提交问题前应删除订阅地址、访问令牌和私人域名；保留内核版本、规则片段、数据来源与报错上下文，通常已经足够定位方向。

离线替换、回滚与维护节奏

当启动阶段无法下载数据时，离线替换是可重复的修复办法。先从选定数据源取得对应格式的文件，再通过客户端确认内核实际使用的数据目录。不要根据安装程序所在目录猜测：桌面界面、系统服务和便携运行方式可能使用不同工作目录。

1. 备份当前数据文件，记录其来源与获取日期。
2. 停止实际运行的内核；使用服务模式时，确认后台服务也已经停止，而不仅是关闭窗口。
3. 按原有文件名替换数据，例如 geoip.dat、geosite.dat 或 Country.mmdb，并保持运行账户可读。
4. 启动内核，检查加载日志，再用新连接验证规则命中。
5. 若出现解析失败或分流异常，停止内核并恢复备份，同时排查格式、分类和来源差异。

下载得到的文件若实际是登录页、限流提示页或错误文档，即使被重命名为 .dat 也不能使用。先核对下载结果是否来自预期发布资产，再处理内核报错。也不要用 GeoSite 文件覆盖 GeoIP 文件，两者扩展名相同并不意味着内容可互换。

日常维护可以先采用 24 小时间隔，不必缩短到每小时反复下载。站点分流异常时，先查看命中规则与域名信息，再决定是更新数据、增加单站例外，还是修复 DNS 路径。把问题拆到对应环节，比整套配置来回替换更容易保留可工作的基线。更多字段解释可查看技术参考；接入和基础设置则从配置教程继续。