GeoIP 与 GeoSite 在分流规则里到底做什么
Clash 的分流规则里经常能看到 GEOIP,CN,DIRECT 或 GEOSITE,google,PROXY 这类写法。这两条规则背后依赖的是两份数据文件:GeoIP 数据库把 IP 地址段映射到国家或地区代码,GeoSite 数据库把域名归类到预设的分组(比如 google、github、netflix)。规则引擎在匹配流量时,不需要逐条硬编码域名或 IP 段,只要引用数据库里的分组名,就能一次性覆盖成千上万条记录。
这种设计把"规则逻辑"和"规则数据"拆开了。规则逻辑写在 rules 字段里,基本不用改;规则数据放在独立的二进制文件里,可以单独下载、单独更新。数据库本身不含判断逻辑,只是一份索引表,类似于把域名和 IP 归档进不同的文件夹。当某个网站换了 IP 段,或者新增了一批域名,只要数据库更新及时,规则的判断结果就能跟着变化,不需要用户手动改配置文件里的规则条目。
反过来说,如果数据库长期不更新,规则的准确率会慢慢下降:新注册的域名可能落不到该落的分组里,某个 CDN 换用的新 IP 段也可能被误判到境外分组。这也是为什么数据库版本和更新频率值得单独关注,而不是配置文件写完就一劳永逸。
常见数据库发行版对比
市面上流传的数据库文件名和格式并不统一,容易混淆,先按客户端内核分两条线说清楚。
Clash 原版与 Clash Meta(mihomo)的差异
早期 Clash 原版内核使用的是 Country.mmdb,这是 MaxMind 格式的 GeoIP 数据库,只做 IP 到国家代码的映射,不含 GeoSite 域名分组功能,原版内核的 GEOSITE 规则支持也有限。Clash Meta 及其继续维护的分支 mihomo,则采用了自己的数据格式:GeoIP 部分是 geoip.dat 或更新的 geoip.metadb,GeoSite 部分是 geosite.dat。.metadb 是 mihomo 团队后续切换到的自有格式,体积更小、查询更快,和旧的 .dat 格式不能混用。
数据来源:V2Ray/Xray 系与 MaxMind 系
geoip.dat 与 geosite.dat 的命名和结构最初来自 V2Ray/Xray 生态,后来被 Clash Meta 直接借用,所以两边的数据文件格式高度兼容,分组名称(比如 cn、category-ads-all)也基本对齐。这类数据库通常由社区项目定期编译发布,常见的发行仓库会持续跟进 IP 段和域名列表的变化。MaxMind 的 GeoLite2-Country.mmdb 则是另一条线,数据结构更偏向传统 IP 地理位置库,主要给只认 .mmdb 格式的旧内核使用。
实际选择时记住一个原则:先确认自己用的内核是哪个分支(Clash 原版、Clash Meta 还是 mihomo),再确认它认哪种数据文件格式,两者对不上,替换了也不会生效,甚至会导致规则引擎报错启动失败。
手动替换文件的完整步骤
手动更新适合不想改配置文件、只想临时刷新一次数据的场景。核心思路是:下载新的数据库文件,放到客户端能读取到的目录,覆盖旧文件,重启内核。
-
确认客户端的数据目录
不同客户端存放 GeoIP/GeoSite 文件的目录不同,常见的是配置文件同级目录,或者客户端安装目录下的
data、resources子目录。可以先在客户端的配置管理界面里查看当前生效的配置文件路径,数据库文件通常就在同一目录或其父目录下。 -
确认内核认的文件格式
打开客户端的内核版本信息,确认是 Clash 原版、Clash Meta 还是 mihomo。mihomo 较新版本默认认
geoip.metadb,较旧版本和 Clash Meta 认geoip.dat与geosite.dat。下载前先核对文件名后缀,避免下错格式。 -
从对应发行源下载最新文件
选定一个维护活跃的社区发行源,下载与自己内核匹配的文件版本。下载完成后不要直接覆盖,先在原文件所在目录做一份备份,方便替换后出问题时快速回滚。
-
停止内核后再替换文件
数据库文件通常在内核启动时被加载进内存,运行中直接覆盖文件可能不会立即生效,甚至在某些系统上会因为文件被占用而替换失败。建议先在客户端里停止代理服务或退出客户端,再进行文件替换。
-
重启内核并检查日志
替换完成后重新启动客户端或代理服务,查看内核日志里是否有数据库加载失败、格式不匹配之类的报错。如果日志正常且没有报错,说明新数据库已经生效,可以用一个已知归属明确的域名或 IP 测试分流结果做二次确认。
替换文件前务必确认文件名与配置里 geodata-mode、geo-auto-update 等字段引用的路径一致,文件名或路径写错,内核会静默回退到旧数据或直接报错找不到文件。
在配置文件里开启定时自动更新
手动替换需要人工介入,长期来看容易忘更新。Clash Meta 与 mihomo 支持在配置文件里声明数据库来源和更新周期,由内核自己定时拉取新版本,不需要人工干预。核心字段集中在配置文件顶层的 geox-url 与更新周期相关设置里,典型写法如下:
geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
geoip: "https://example.com/geoip.metadb"
geosite: "https://example.com/geosite.dat"
mmdb: "https://example.com/Country.mmdb"几个字段的作用分别是:geodata-mode 打开后,GEOSITE 规则才会真正按域名分组匹配,而不是被内核忽略;geo-auto-update 决定是否启用自动更新;geo-update-interval 以小时为单位设置更新间隔,示例里的 24 表示每天检查一次;geox-url 下的三个键分别指定 GeoIP、GeoSite 与 MaxMind 格式数据库的下载地址,内核会按这个地址周期性拉取。不同版本的内核对字段名的支持略有出入,升级客户端后建议对照当前版本的更新日志核实字段名是否有变化,避免用了旧字段导致自动更新静默失效。
如果订阅本身由机场提供,机场的订阅转换服务有时会自带一份预置的 geox-url,这种情况下自己手写的字段可能会被订阅内容覆盖。遇到自动更新不生效,先检查最终生效的配置文件里这几个字段是不是被订阅内容重写过。
更新后常见问题排查
数据库更新之后规则表现异常,大多集中在以下几类原因。
- 格式不匹配:下载了
.dat格式却让只认.metadb的新版内核加载,内核通常会在日志里报解析失败,规则引擎会回退到"未匹配"状态,大量流量落入默认策略组。 - 分组名称对不上:不同发行源对同一类网站的分组命名可能有差异,比如有的叫
netflix,有的拆分成更细的子分组。规则里写的分组名要和数据库实际收录的分组名完全一致,大小写和拼写都要核对。 - 自动更新地址不可达:
geox-url指向的地址如果访问不稳定或需要代理才能访问,而更新动作发生在代理链路建立之前,就会出现更新总是失败的情况。这类地址建议选用访问链路简单、稳定的发行源。 - 缓存未刷新:少数客户端在图形界面上会对规则做额外缓存,数据库文件已经更新但界面显示的匹配结果没变化,重启一次客户端通常能解决。
排查思路建议按"文件是否放对目录 → 格式是否匹配内核 → 配置字段是否被覆盖 → 网络能否访问更新地址"的顺序逐项确认,大部分数据库相关的分流异常都能在这几步里定位到原因。