将 本人的历史对话 整理到此
- geosite.db: clash 源码里未发现读取的地方, 猜测 clash 不支持此格式
- geosite.dat: 源码 path.GeoSite, 存放域名的地方, 这些域名会按照一定规则分组称为 域名类别, 比如
domain:ip.cn属于cn;domain:git.io domain:githubusercontent.com属于github. 这个文件可以通过 metacubex/geo 解压查看. - country.mmdb: 格式是 maxmind 定义的 IP geolocation databases，用途是根据 ip 地址查询国家/城市/时区等信息，而名称的 country 是指只包含到国家的信息，而没有城市/时区，具体可容纳的信息见它的 pdf 说明 GeoLite2-IP-MetaData-Databases-Comparison-Chart. 而这个仓库的此文件来自 Loyalsoldier/geoip, 其在 maxmind 提供的标准基础上新增了域名类别(cloudflare/google...) 等等, 具体见其说明 与官方版 GeoIP 的区别
- geoip.db/geoip.metadb: 根据源码 path.MMDB 来看 Country.mmdb/geoip.db/geoip.metadb 只会取一个用来比较 ip 归属国家的 (geoip.Match), 所以对于 clash 来说这三者可看作同一份数据, 以下简称为 Country.mmdb 系列
- geoip.dat: 根据源码大量 C.GeodataMode (update_geo.UpdateGeoDatabases) 的判断来看, Country.mmdb 系列 和 geoip.dat 是二选一的. 而此仓库的来自 Loyalsoldier/geoip 所以其实这四种都是同一份数据的不同格式.
总结:
- Country.mmdb/geoip.db/geoip.metadb 和 geoip.dat 是二选一的, 四者内部都是同一份数据, 通过配置 GEOIP 数据模式 来决定.
- geosite.db 不支持
- geosite.dat 按照地区(cn...)/服务商(如 google/github...)等分组的域名(2024/07/20 补充: 一个组对应一个文件, 通过 rule 里 GEOSITE 引用, 按需加载--只会加载引用的)
- xxx-lite 就是 xxx 的精简版
2024/04/17 geosite.dat 数据概览:
geo unpack site ./geosite.dat -d sites ls sites -1 | wc -l # >>> 1257 dust sites # 16K ┌── meta │█ │ 0% # 16K ├── microsoft │█ │ 0% # 16K ├── tld-!cn │█ │ 0% # 16K ├── win-extra │█ │ 0% # 16K ├── win-update │█ │ 0% # 20K ├── beats │█ │ 0% # 20K ├── category-ads │█ │ 0% # 20K ├── category-ecommerce │█ │ 0% # 20K ├── category-games │█ │ 0% # 24K ├── category-ads-all │█ │ 0% # 28K ├── google │█ │ 0% # 32K ├── category-media │█ │ 0% # 36K ├── category-entertainment│█ │ 0% # 48K ├── apple │█ │ 1% # 96K ├── geolocation-cn │█ │ 1% # 124K ├── gfw │█ │ 2% # 140K ├── category-porn │█ │ 2% # 148K ├── category-companies │█ │ 2% # 520K ├── geolocation-!cn │███ │ 7% # 1.4M ├── cn │████████ │ 18% # 7.8M ┌─┴ sites │███████████████████████████████████████ │ 100%
@potoo0 请问一下, 使用这些数据格式配置分流规则, 和直接使用类似rule-providers这种yaml文件有什么区别啊? 我看好像数据源都差不多, 我用的blackmatrix7/ios_rule_script@master的classical数据, 而且都有No_Resolve版本.
rule-provider 一般是把目标地址按照一些规律分组（规律自己随意）, 比如我把 谷歌相关的域名全部收集起来，例如:
########## 注意这里的规则不写代理出口，下面三条是举例乱写的
DOMAIN-KEYWORD,google
DOMAIN-SUFFIX,google0000001.com
IP-CIDR6,22:22:22:22::7/32
然后配置 rule-provider 起名 gg, format=text, behavior=classical 指向我这段文件地址,
那么在 rule 下面就可以配置 RULE-SET,gg,出口-美国，这样满足上面三条条件的目标地址就会使用出口“出口-美国”。
rule-provider 支持两种 format: yaml 和 text, 以及 三种 behavior: domain / ipcidr / classical
简单总结三种 behavior:
- domain: 只能写域名
- ipcidr: 只能写 ip 的 cidr
- classical: 支持 rule 配置下面的所有, 例如:
SRC-PORT,9999
no-resolve: 如果访问域名例如 google.com 然后遇到了 IP-CIDR 的规则时，MetaCubeX 会尝试将 google.com dns解析成 ip 地址，然后拿解析的 ip 地址去判断是否命中 IP-CIDR 规则。而 no-resolve 就是告诉 MetaCubeX 这条 IP-CIDR 不要 dns 解析，那访问 google.com 就会永远不命中也就是会跳过这条 IP-CIDR 的规则。
- rule-provider 用途上和 geosite 类似：按照一些规律挑选出部分目标地址（相当于分组，从不计其数的目标地址中按照域名/地域/服务提供商等等分组），然后在 rule 里来指定此分组的代理出口，如
RULE-SET,gg,出口-美国GEOSITE,google,出口-美国。 而 rule-provider 比 geosite 更灵活功能更多，只要 rule 下面支持的这里都可以支持，比如 ipcidr / 应用程序名等等:IP-CIDR6,2620:0:2d0:200::7/32,PROCESS-NAME,aria2如果把 geosite 的内容的文件名作为 rule-provider 名称，对应文件内容作为 rule-provider 内容时，二者作用完全等价。
- rule-provider 的 behavior=classical 时支持配置 "rule配置" 下面的规则，即相比 domain 和 ipcidr 额外支持
DOMAIN-SUFFIX,SRC-PORT,PROCESS-NAME等等 - no-resolve: 遇到 ip 地址的规则时，跳过域名的 dns 解析。目标地址是域名的话就会跳过此 ip 规则，作用是可以防止墙内 dns 污染
粗略看了源码，匹配效率没差，都需要展开一行行逐个判断是否命中。
不同的是:
- geosite 是在启动时按需加载，按需就是说只有 rule 里引用的才会实际加载。比如 geosite 有 100 个文件（分组）只使用了其中一个组如 google，那就只会加载 google 这一个组。
- rule-provider 启动时全部加载，不管 rule 里有没有引用，考虑实际中乱加不使用的 rule-provider 人应该不多，浪费不了多少内存。
相关源码位置:
- geosite 按需加载:
- rule-provider 加载:
测试入口: rules_test.txt