进阶技巧 · 预计阅读 9 分钟

GeoIP 与 GeoSite 数据库更新方法：分流规则失准的排查与修复

分流突然把国内网站也走了代理，或者境外服务被判定成了直连？多数情况下不是规则写错了，而是本地的 GeoIP/GeoSite 数据库过旧。本文梳理这两类地理数据库的作用机制、手动与自动更新方式，以及更新后规则依旧不生效时的排查顺序。

GeoIP 与 GeoSite 到底是什么

Clash 系配置文件里常见这样的规则写法：

rules:
  - GEOIP,CN,DIRECT
  - GEOSITE,google,Proxy
  - GEOSITE,cn,DIRECT
  - MATCH,Proxy

这里的 GEOIP,CN 和 GEOSITE,google 并不是内核自己判断出来的，而是查表得到的结果。查的表就是两份预先编译好的地理数据库：

  • GeoIP 数据库（常见文件名 Country.mmdb 或 geoip.dat）：把全球 IP 段划分到对应国家/地区代码，内核收到一个目标 IP 后先查这张表，得到类似 CN、US、HK 这样的归属地，再对照规则决定直连还是走代理。
  • GeoSite 数据库（常见文件名 geosite.dat 或 geosite.db）：把常见域名或域名后缀归类到预设分组，比如 cn、google、github、netflix，命中分组即触发对应策略。

这两份数据库都是社区维护的静态文件，跟随上游项目（如 Loyalsoldier 的规则集、v2fly 的 domain-list-community）定期重新编译发布，本身不会随内核升级自动更新，也不会因为你换了订阅就刷新。它们更像是一份"字典"，字典印刷的时间点决定了查得到还是查不到。

数据库过旧为什么会让分流"失准"

互联网的 IP 段分配和域名归属并不是一成不变的：云服务商的 IP 池会扩容或迁移，CDN 节点会在不同地区之间调度，新上线的域名短期内根本不在任何分组里。如果本地数据库停留在几个月甚至一两年前的版本，就会出现两种典型症状：

  • 该直连的走了代理：国内网站换用了新的 IP 段或接入了新 CDN，旧版 GeoIP 库里查不到归属为 CN，规则判定失败后落到默认策略（通常是代理），表现为访问明显变慢、偶尔连接失败。
  • 该代理的却被直连：某个境外服务更换了域名或增加了新的子域，旧版 GeoSite 分组里没有收录，规则匹配不到对应分组，最终被 MATCH,DIRECT 之类的兜底规则接管，直接暴露在没有代理的网络环境下。

注意：规则文件本身没有任何改动，只是底层查询用的数据库过期，这种问题往往被误判为"订阅出问题了"或"规则写错了"，排查方向一旦错了会浪费大量时间。

先确认当前数据库版本与更新时间

动手更新前，先确认问题确实出在数据库上。不同客户端查看方式略有差异，但思路一致：找到数据库文件的最后修改时间，对比上游发布记录。

  1. 在客户端的"内核/规则"设置页面，通常能看到 GeoIP、GeoSite 文件的本地路径与最后更新时间戳；部分客户端会直接标注版本号或提交哈希前几位。
  2. 若客户端界面没有暴露这个信息，可以进入配置目录直接查看 Country.mmdb、geosite.dat 文件的修改日期，安卓端一般在应用私有目录下的 data 或 geo 子目录。
  3. 对照上游仓库的发布日期（GeoIP 库和 GeoSite 库通常按周或按双周更新一次），如果本地文件的时间落后超过一个月，基本可以确定需要手动刷新。

另一个更直接的验证方法：临时在配置里加一条明确的域名或 IP 规则，指向一个你怀疑分流出错的目标，观察是否命中兜底策略而不是预期分组——如果精确规则生效但 Geo 规则不生效，问题基本锁定在数据库本身。

手动更新数据库的步骤

手动更新的核心思路是：从可信的规则集仓库下载最新编译好的数据库文件，替换掉客户端配置目录下的旧文件，再重启内核或重新加载配置。

  1. 确认客户端使用的内核版本：Clash 原版、Clash Meta、mihomo 三者对数据库文件的格式要求不完全一致，mihomo 在部分版本上支持更细粒度的规则集格式，替换前先确认当前内核能读取的文件类型（.mmdb / .dat / .db）。
  2. 获取最新数据库文件：从对应上游规则集项目的发布页面下载最新版本，文件名与客户端配置中 geodata-url、geoip-url 或本地路径要保持一致，避免下载后文件名不匹配导致客户端仍读取旧文件。
  3. 替换本地文件：将下载好的文件放入客户端配置目录中原文件所在位置，建议先备份旧文件再覆盖，防止新文件本身损坏时无法回退。
  4. 重启内核或重新加载配置：多数客户端在替换文件后需要重启代理服务才能重新加载数据库，仅刷新订阅或切换节点通常不会触发数据库重新读取。
  5. 验证生效：重启后访问此前判定错误的站点，或查看客户端连接日志中该请求命中的规则名称，确认已经落在预期分组下。
# 以 mihomo 内核命令行为例，手动替换后重新加载配置的典型操作
# 1. 停止正在运行的服务
systemctl stop mihomo
# 2. 用新文件覆盖旧的 GeoIP / GeoSite 数据库
cp Country.mmdb /etc/mihomo/Country.mmdb
cp geosite.dat /etc/mihomo/geosite.dat
# 3. 重新启动
systemctl start mihomo

配置自动更新，避免重复过期

手动更新能解决一次性问题，但过一段时间数据库又会重新过期。更可靠的做法是在配置文件里声明数据库的远程地址和更新周期，让客户端在启动或定时任务中自动拉取最新版本。

以支持该字段的内核为例，配置文件中通常会有类似结构：

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://example.com/Country.mmdb"
  geosite: "https://example.com/geosite.dat"
  • geo-auto-update：是否允许内核在后台自动检查并下载新版本数据库。
  • geo-update-interval：自动检查的间隔（单位小时），设置过短会增加不必要的网络请求，一般 24 小时一次已经足够跟上上游发布节奏。
  • geox-url：指定数据库的下载源地址，如果默认源在你的网络环境下访问缓慢，可以替换为镜像地址，但要确认镜像同步的时效性，否则等于换了个地方继续用旧数据。

不是所有客户端图形界面都暴露了这几个字段的设置入口，如果界面上没有对应开关，可以在"编辑配置文件"或"高级设置"里直接以文本方式添加上述字段，保存后重启服务生效。

更新后规则依旧不生效怎么排查

如果已经确认下载的是最新数据库，替换后问题依旧存在，按下面的顺序逐项排查，通常能定位到具体环节。

  1. 确认文件确实被替换了：查看文件的修改时间与体积是否发生变化，有些客户端会把数据库缓存在多个位置（如安装目录与用户配置目录并存），替换错了位置等于没替换。
  2. 确认内核真正重新加载了文件：部分客户端的"重启"按钮只重启界面进程，不会重启底层内核服务，需要在系统层面彻底停止再启动对应进程或服务。
  3. 检查规则顺序是否被更靠前的规则拦截：Clash 规则是自上而下按顺序匹配的，如果 GEOSITE,cn,DIRECT 之前存在一条覆盖面过宽的规则（比如某个宽泛的 DOMAIN-SUFFIX 或 IP-CIDR），会导致目标请求提前命中，根本走不到 Geo 规则那一步。
  4. 检查订阅是否覆盖了本地规则集配置：如果使用的是"订阅转换"服务生成的配置，某些转换规则会在生成阶段就写入了自己的 Geo 数据源地址，本地手动替换的文件可能根本没有被引用到。
  5. 查看连接日志确认实际匹配到的规则名：多数客户端提供实时日志或连接面板，能看到每条请求具体命中了哪一条规则，这是判断问题出在数据库还是规则顺序上最直接的方式。

建议：排查时优先打开连接日志逐条比对，比反复猜测规则写法效率高得多，大多数"分流不准"的问题都能在日志里直接看到命中的是哪一条规则。

建立长期维护习惯

Geo 数据库的过期是持续性问题，不是修一次就永久解决的。建议养成以下习惯，减少后续再次踩坑的概率：

  • 启用自动更新字段后，每隔一段时间人工确认一次数据库的实际更新时间，避免自动更新任务因网络问题静默失败而毫无察觉。
  • 更换订阅或规则集来源时，留意其中是否内置了自己的 Geo 数据源地址，防止和本地手动维护的配置产生冲突。
  • 规则文件改动较大时，先在测试环境或单独的配置分组里验证，再合并进日常使用的主配置，避免线上分流大范围异常。
  • 关注上游规则集项目的更新日志，尤其是国内常用服务大规模迁移 IP 段或域名结构调整的时期，及时手动刷新一次数据库比等待自动更新周期更稳妥。
下载客户端