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

GeoIP 与 GeoSite：先区分 IP 归属与域名分类

GeoIP 用于按目标 IP 的地区归属进行匹配；GeoSite 用于按域名集合进行匹配。两者都是分流规则的数据来源，不提供代理节点，也不替代订阅。更新数据库，改变的是规则可查询的数据，不会自动增加节点或修改节点的连接参数。

本文的配置示例面向使用 mihomo 内核的客户端。Clash Meta 是该内核的旧称。历史 Clash 内核、不同分支以及图形客户端的封装方式存在差异，不能仅凭客户端名称判断是否支持全部字段。操作前，先在客户端「关于」或运行日志开头确认实际内核名称。

geodata-mode 控制的是 GeoIP 数据格式，不是 GeoSite 的总开关。即使使用 MMDB 模式，只要内核支持并且配置引用了 GEOSITE，仍可能需要 geosite.dat。不要把“已更新 Country.mmdb”当成域名分类数据也已更新。

数据库放在哪里：以运行内核的数据目录为准

客户端安装目录、订阅文件目录和内核数据目录可能是三个不同位置。优先在客户端的设置、更多菜单或托盘菜单中查找「打开配置目录」「打开数据目录」一类入口；具体名称由客户端决定。进入后，查看现有的 Country.mmdb、geoip.dat 和 geosite.dat，不要直接把文件放到下载文件夹。

独立运行 mihomo 时检查启动参数

命令行启动可以用 -d 明确指定工作目录。下面是 Linux 的示例，数据目录为 /var/lib/mihomo，配置文件单独放在 /etc/mihomo/config.yaml。两者不必处于同一个文件夹。

mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml

• 手动启动：检查实际使用的命令，不要只查看终端当前目录。
• systemd 服务：用 systemctl cat mihomo 查看服务定义中的 ExecStart 和运行用户；服务名需与本机实际名称一致。
• 容器运行：检查容器内数据目录对应的宿主机挂载路径，文件应写入该挂载位置。
• 图形客户端：确认文件属于当前启用的内核实例，而不是之前停用的另一个客户端。

大小写也需要保留。Linux 上的 Country.mmdb 与 country.mmdb 不是同一个文件。部分内核支持自定义文件名或位置，此时应以实际生效配置和日志记录的路径为准。

手动更新：备份、替换与重新加载

手动更新适合首次补齐数据库、自动下载失败，或需要回退到上一份数据的场景。先确定当前使用 MMDB 还是 DAT 模式，再下载对应格式。数据来源应提供与 mihomo 兼容的文件，并说明收录范围与分类名称；不同维护项目的分类集合并不保证完全一致。

1. 记录现状。保存有效配置，记录文件路径、修改时间和当前使用的数据来源。把旧文件复制到备份目录，而不是立即删除。
2. 停止内核。在客户端中停止内核服务，或退出客户端后确认后台内核已经结束。服务方式运行时，停止对应服务。
3. 检查下载结果。确认拿到的是数据库本体，不是压缩包、项目说明页或下载失败后的 HTML 页面。压缩包应先解压，再使用其中正确的文件。
4. 按原路径替换。MMDB 模式替换 Country.mmdb；DAT 模式替换 geoip.dat；域名分类更新则替换 geosite.dat。
5. 检查读取权限。运行内核的用户需要有目录访问权限与文件读取权限。自动更新还需要对数据目录有写入权限。
6. 重启并验证。启动内核，查看是否出现数据库解析失败、分类不存在或权限不足等错误，再测试新连接的命中规则。

仅修改磁盘文件，不代表内存中的数据立即刷新。不同客户端的热加载行为不完全一致，手动替换后重启内核更容易确认加载的是新文件。如果替换后无法启动，先停止内核并恢复备份，再检查格式是否匹配，不要连续更改规则来掩盖文件问题。

自动更新：配置周期与下载来源

在支持这些字段的 mihomo 内核中，可以在配置顶层启用数据库自动更新。下面示例选择 DAT 模式，以 24 小时为更新间隔；它不是订阅刷新周期，也不是每次建立连接都下载一次数据库。

geodata-mode: true
geodata-loader: memconservative
geo-auto-update: true
geo-update-interval: 24

geodata-loader 指定 DAT 数据的加载方式，memconservative 是内存节省型加载器。它不负责决定下载地址，也不改变规则的优先级。若继续使用 MMDB，将 geodata-mode 设为 false，不要为了启用自动更新而强行切换格式。

geox-url 的键与文件类型需要对应

需要自定义来源时，在顶层 geox-url 映射中设置下载地址。geoip 对应 GeoIP DAT，geosite 对应 GeoSite DAT，mmdb 对应 MMDB。应填写数据维护方提供的完整 HTTPS 文件地址，而不是项目首页或需要交互登录的页面。

本文不提供一份固定的远程数据地址：分类规则是否可用，取决于你选择的数据项目。沿用客户端已配置的可信来源时，不必额外新增 geox-url；如果客户端覆盖了来源，则需要检查最终配置，不能仅凭订阅原文判断。

• 订阅托管配置：使用客户端提供的覆写、合并或扩展功能加入顶层字段，避免下一次更新订阅时被覆盖。
• 独立配置：直接修改实际启动时使用的配置文件；不要重复写两组同名顶层键。
• 下载失败：先查看日志中的请求地址与错误类型，再检查网络、系统时间、磁盘空间和目录权限。

GEOIP 与 GEOSITE 规则写法：顺序决定命中结果

规则模式按顺序匹配，通常由第一个匹配项决定流量去向。下面的片段先处理一个明确域名，再按 GeoSite 分类处理域名，然后按 GeoIP 判断 IP，最后进入兜底策略组。示例假设当前订阅已经定义了名为「节点选择」的策略组；没有这个组时，必须改成配置中实际存在的名称。

mode: rule

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,节点选择

GEOSITE：分类名称来自数据库

GEOSITE,cn,DIRECT 表示把当前 GeoSite 数据库中 cn 集合匹配到的域名交给 DIRECT。它不是对域名后缀 .cn 的简单判断。能否使用 cn 或其他分类，要查看数据维护方的分类清单；更换数据源后，应再次确认旧规则引用的分类仍然存在。

GEOIP：no-resolve 不会停止所有 DNS 查询

GEOIP,CN,DIRECT,no-resolve 表示按目标 IP 的地区信息匹配，并避免仅为检查这一条 IP 规则而主动解析尚未解析的域名。如果请求已经带有目标 IP，仍可以参与匹配。这个参数不是全局关闭 DNS，也不会阻止应用自身发起解析。

如果希望未命中域名规则的请求也通过解析结果判断地区，可以根据实际需求移除 no-resolve。代价是规则判断可能依赖额外的 DNS 解析。使用 Fake-IP 时，目标域名恢复、已有解析结果和具体请求路径也会影响表现，应结合连接记录判断，不能只看规则文本推断。

MATCH：兜底项始终放在最后

MATCH 接受前面没有匹配到的请求。把它放到 GEOSITE 或 GEOIP 前面，后面的规则就失去处理机会。自定义域名例外通常应放在大范围分类规则之前，否则即便数据库里有该域名，实际走向也可能与你预期不同。

GeoIP 的地区归属不是服务器所有者或业务归属证明。使用 CDN、跨地区部署或 Anycast 的站点，可能出现域名分类与 IP 地区不一致。希望某个业务固定走指定策略时，优先添加明确的域名规则，不要只依赖国家地区判断。

更新后仍未分流：按有效配置、日志和新连接检查

验证时应把“文件是否更新成功”与“流量是否命中规则”分开。数据库加载成功，只能证明数据可读；应用流量还需要进入这个内核，并且处于规则模式，相关规则才有机会执行。

1. 查看最终配置。确认运行中的 rules、geodata-mode 和更新字段确实存在，而不是只修改了未启用的配置。
2. 确认规则模式。全局模式或直连模式不会按这份规则列表得到相同结果。
3. 建立新连接。关闭测试站点的现有连接后重新访问。已经建立的长连接通常不会因为更新数据库立即改道。
4. 查看连接详情。记录目标域名、目标 IP、命中的规则和最终策略链。一次只调整一项，便于比较前后变化。
5. 检查流量入口。系统代理只影响遵循该代理设置的应用；TUN 能接管哪些流量还取决于路由与排除设置。没有进入内核的请求，不会命中 Geo 规则。

临时排查可提高日志级别，完成后再恢复日常级别，减少日志体积。分享日志时遮盖订阅地址、令牌、节点凭据和敏感访问记录。最终保留一份可恢复的配置与数据库备份，比频繁更换来源更便于定位问题。