GeoIP 与 GeoSite 数据库如何更新:geodata 模式、下载地址与规则写法

1. 先区分 GeoIP、GeoSite 与订阅更新

GeoIP 和 GeoSite 是分流规则引用的数据，不是代理节点。更新订阅通常用于取得节点、策略组或整份配置；更新地理数据库则改变规则能够匹配的 IP 网段或域名集合。两者由不同机制维护，点击一次“更新订阅”，不能据此判断数据库也已更新。

GeoIP 的国家或地区归类不等于网站运营主体所在地，也不保证反映用户访问时的实际服务位置。CDN、跨区域部署以及数据源的收录差异，都会让“域名应该直连”和“解析出来的 IP 被归在哪个地区”出现不同结果。因此，域名规则通常放在 IP 规则前面。

2. geodata-mode 的作用与文件存放位置

开启后改变的是 GeoIP 数据格式

在 mihomo 中，geodata-mode: true 让 GeoIP 使用 DAT 数据；设为 false 时使用 MMDB 数据。这个开关不是“开启所有地理分流”的总开关，也不负责创建任何规则。GeoSite 仍然需要相应的数据文件和 GEOSITE 规则。

• geox-url.geoip：GeoIP DAT 的下载来源。
• geox-url.mmdb：GeoIP MMDB 的下载来源。
• geox-url.geosite：GeoSite DAT 的下载来源。
• geodata-loader：DAT 数据加载方式，常见值为 standard 与 memconservative；它不决定规则目标策略。

文件通常由内核放在工作目录中，常见名称包括 GeoIP.dat、GeoSite.dat 和 country.mmdb。不同客户端可能维护自己的运行目录，不能把安装程序所在文件夹当作数据目录。大小写还可能影响 Linux 上的文件识别，应以该内核日志、实际文件和客户端说明为准。

用运行参数定位，避免改错副本

1. 在客户端提供的配置目录或工作目录入口中查找数据库文件；“配置目录”与“应用日志目录”可能不是同一个位置。
2. 查看内核启动参数，-d 指定工作目录，-f 指定配置文件。配置文件所在目录不一定就是工作目录。
3. 如果自行运行内核，可显式使用 mihomo -d ./mihomo-data -f ./config.yaml，让工作目录位置明确。
4. 使用容器时检查目录挂载关系；容器内的工作目录与宿主机保存文件的位置可能不同。

修改前保存当前配置与现有数据库。若客户端提供覆写、合并或扩展配置，应通过这些持久化入口写入全局字段；直接修改自动生成的运行配置，可能在下次更新订阅后被覆盖。

3. 配置下载地址与每 24 小时自动更新

下面是一段可合并进 mihomo 配置顶层的示例。数据来源为 MetaCubeX 的 meta-rules-dat 发布资源，geo-update-interval 的单位是小时，数值 24 表示一天的更新间隔。它不是规则提供器所使用的秒数间隔。

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"

• 这些字段与 rules、dns 同级，不要缩进到 proxy-groups 或 profile 下面。
• 已有 geox-url 时合并原映射，不要重复添加同名顶层键。
• 改用 geodata-mode: false 后，应重点检查 MMDB 来源是否可用；只更新 DAT 不能替代当前使用的 MMDB。
• 自动更新不等于保存配置后立即下载。应用配置或重启内核后，结合更新日志确认调度是否启用。

来源项目可在 MetaCubeX/meta-rules-dat 查阅，字段说明可对照 mihomo 通用配置文档。发布资源会随项目维护变化；链接失效时先核对发布页，不要仅凭文件名改成陌生下载地址。

4. GEOIP、GEOSITE 与规则顺序

Clash 系列规则按顺序匹配，前面的规则命中后就采用其目标策略。下面的片段把域名集合放在 IP 规则前面，最后用 MATCH 兜底。示例定义了“出站选择”策略组，但组内只有 DIRECT，用于展示可解析的结构；实际使用时应将已有代理节点或策略组接入，不能把这个示例当作现成代理连接。

proxy-groups:
  - name: 出站选择
    type: select
    proxies:
      - DIRECT

rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,出站选择

no-resolve 不是关闭 DNS

GEOIP,CN,DIRECT,no-resolve 表示这条规则不会为匹配目的主动触发域名解析。如果连接信息里已有目标 IP，仍可进行 IP 匹配；如果没有可用 IP，就可能继续向下检查规则。该参数不会关闭整个客户端的 DNS，也不妨碍应用在其他阶段进行解析。

规则能匹配到什么，取决于连接信息

GeoSite 需要域名信息。应用直接连接 IP、域名映射丢失或流量接管方式改变时，不能保证每条连接都能命中域名分类。TUN 是流量接管方式，不是 GeoSite 更新的前置条件；启用 TUN 本身也不会自动补齐所有连接的域名。使用 fake-ip 时，DNS 映射关系同样会影响内核能否恢复对应域名。

需要固定某个站点走向时，可以在分类规则之前写具体规则，例如 DOMAIN-SUFFIX,example.com,DIRECT。这是顺序控制，不需要为了单个域名重新制作数据库。正式规则应使用实际需要处理的域名，并在连接详情中验证命中项。

5. 无法自动下载时的手动替换流程

常见失败包括下载超时、重定向目标不可达，以及代理出站本身依赖尚未成功加载的配置。浏览器能够打开 GitHub 首页，也不能证明内核能下载发布附件；两者可能使用不同的代理设置与网络路径。

1. 记录错误：保存日志中的资源地址、错误类型和目标文件位置，区分连接超时、HTTP 错误与数据解析失败。
2. 取得对应资源：从配置中指定的发布来源下载实际二进制文件，确认没有保存为网页、登录页面或错误响应。
3. 停止内核：使用客户端的停止功能；若关闭窗口后仍驻留托盘，需要明确停止后台内核，避免文件被继续占用。
4. 备份并替换：将原文件移至备份目录，再把新文件放到已确认的工作目录，沿用内核要求的本地文件名。
5. 重新启动：检查数据加载日志与配置解析结果；若出现分类不存在或解析错误，先恢复备份，再检查来源与格式。

不要把 MMDB 文件改名为 DAT 试图转换格式，也不要把 GeoSite 数据放进 GeoIP 文件位置。扩展名不是转换工具，内核读取的是文件内部结构。Linux 或服务方式运行时，还要确保运行内核的账户对目录有读取权限；启用自动更新则需要相应写入权限。

6. 更新后用日志与连接详情交叉验证

“文件时间变了”只说明发生过写入；“配置能启动”也不代表测试流量命中了预期规则。建议把更新过程和实际分流分成两组检查，逐项记录，而不是仅观察网页能否打开。

测试时先关闭原有长连接，再发起新请求。已经建立的连接通常不会因为数据库刷新而重新执行完整选路；浏览器连接复用可能让结果看起来没有变化。若需要临时提高日志详细程度，应在排查结束后恢复，并避免对外分享含节点凭据、订阅地址或个人访问记录的完整日志。

7. 常见报错与调整边界

出现“分类不存在”或 GeoSite 加载失败

先核对规则中的分类名是否由当前数据源提供，再确认下载内容确实是 GeoSite DAT。切换到精简数据源后，某些分类可能被移除；恢复兼容的数据源或删除不再支持的规则，比反复重启更有效。

数据库已更新，某个网站仍走错策略

查看是否被更靠前的 DOMAIN、DOMAIN-SUFFIX 或 RULE-SET 抢先匹配；再核对 DNS 返回的地址与连接详情中的目标 IP。数据库更新不会调整规则顺序，也不会清除所有 DNS 缓存。确认具体匹配路径后，再决定修正规则、清理缓存还是反馈数据源收录问题。

已经使用 rule-providers，还需要更新 GeoSite 吗？

取决于配置是否仍引用地理数据。RULE-SET 对应的规则提供器按自己的 url、path 和 interval 更新，地理数据库自动更新不会代替这套机制。如果配置仍使用 GEOSITE、GEOIP，或 DNS 配置引用了相关分类，就要继续维护相应数据。