规则与路由 Intermediate

GeoIP 与 GeoSite 规则集优化:毫秒级精准分流配置

现代网络代理规则集深度优化指南:GeoIP/GeoSite 二进制规则与经典文本规则性能对比、忠诚卫士 Loyalsoldier 规则库实战与微秒级路由匹配调优。

本文解决什么问题?
01 传统上万行文本规则(Classic Rules)为什么会导致客户端内存膨胀与匹配卡顿
02 GeoIP (MaxMind 格式) 与 GeoSite (域名树形字典) 的二进制极速匹配底层原理
03 如何利用 Loyalsoldier / Meta 规则集构建‘国内极速直连 + AI/流媒体精准分流’的分层规则树
04 规则匹配顺序设计原则:为什么 MATCH 永远放在最后,IP-CIDR 必须带有 no-resolve

01. 代理规则分流的演进史:从文本黑白名单到二进制规则集

在科学上网与网络分流领域,分流规则(Routing Rules) 是客户端决定“某个网络数据包究竟应该走国内直连、海外代理节点还是直接拦截广告”的决策中枢。

早期的代理软件采用平铺式的纯文本规则列表(每条规则一行字符串,动辄 5000+ 行)。随着用户访问网站数量的激增,纯文本规则暴露了严重的性能瓶颈:启动时字符串逐行解析耗费大量 CPU、内存占用超过 200MB、每个数据包遍历匹配耗时高达数毫秒

┌────────────────────────────────────────────────────────────────────────┐
│                        现代代理规则分流技术代际演进                    │
├────────────────────────────────────────────────────────────────────────┤
│  第一代:经典纯文本规则 (Classic Rules) ──> 逐行线性比对,性能最差     │
│  第二代:GeoIP / GeoSite .dat 格式     ──> Protobuf 树形结构,查询提速 │
│  第三代:Mihomo MRS / Sing-box SRS 格式 ──> 预编译纯二进制,位运算微秒级│
└────────────────────────────────────────────────────────────────────────┘

现代内核(Mihomo 与 Sing-box)全面转向了 预编译二进制规则集(Rule-Set),将数万条域名和 IP 地址在编译期压缩为内存连续的字典树(Trie Tree),使得单次路由判断耗时骤降至 0.01 毫秒以内


02. 高效分流规则树的五层金字塔架构

一份设计优良的生产级分流配置,必须严格按照 从低开销到高开销、从高特异性到泛匹配 的五层金字塔顺序编写:

┌─────────────────────────────────────────────────────────────────────────┐
│                     生产级规则匹配优先级五层金字塔                      │
├─────────────────────────────────────────────────────────────────────────┤
│  第 1 层:系统局域网与回环地址(LAN / Private IP) ──> DIRECT (直连)   │
│  第 2 层:高频去广告与隐私拦截(AdBlock / Tracking)──> REJECT (丢弃)   │
│  第 3 层:特异性极高的场景服务(OpenAI / Netflix) ──> 专属策略组     │
│  第 4 层:国内大流量公共服务(GeoSite:cn / GeoIP:cn) ──> DIRECT (直连) │
│  第 5 层:最终未匹配泛流量(MATCH / Final)          ──> 兜底代理策略组│
└─────────────────────────────────────────────────────────────────────────┘

03. 生产级 Clash / Mihomo 规则集配置实战

以下为基于社区知名维护者 Loyalsoldier 规则库编写的高性能配置片段:

# 远程规则集引用(自动静默更新)
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

  direct:
    type: http
    behavior: domain
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

  proxy:
    type: http
    behavior: domain
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt"
    path: ./ruleset/proxy.yaml
    interval: 86400

rules:
  # 1. 局域网直连
  - GEOIP,private,DIRECT,no-resolve

  # 2. 广告拦截
  - RULE-SET,reject,REJECT

  # 3. AI 与流媒体专属分流
  - GEOSITE,openai,🤖 AI服务
  - GEOSITE,claude,🤖 AI服务
  - GEOSITE,netflix,🎬 流媒体
  - GEOSITE,youtube,🎬 流媒体

  # 4. 国内直连白名单
  - RULE-SET,direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,cn,DIRECT,no-resolve

  # 5. 海外通用代理与兜底
  - RULE-SET,proxy,🚀 主力代理
  - MATCH,🐟 漏网之鱼

更多特定场景的精准规则配置,请参阅 AI 工具专属分流规则配置Netflix/Disney+ 跨区解锁策略组设计

FAQ / 常见问题解答

Q1.

为什么在配置 GEOIP 规则时必须加上 `no-resolve` 参数?

如果不加 `no-resolve`,当一个域名访问请求匹配到 GEOIP 规则时,客户端内核会被迫立即对该域名发起 DNS 本地解析以获取 IP 地址。在 Fake-IP 模式下,这会导致提前触发不必要的 DNS 解析开销并引发潜在的 DNS 泄漏。

Q2.

规则列表的书写顺序对网络性能和命中率有什么决定性影响?

规则匹配遵循‘从上到下、首个命中即退出’原则。因此,匹配开销最低、命中频率最高的高频规则(如国内直连 GEOSITE,cn)应排在最前,而耗时的全量匹配与 MATCH 兜底规则必须严格排在最后。