自定义分流规则实战指南：DOMAIN、IP-CIDR、端口与进程级语法全解 (2026)

虽然网络上有许多开源维护的大陆直连规则集与广告过滤规则，但直接使用公开规则集往往无法满足开发者的专业需求。例如：公司内部测试域名的远程接入、私有私有云服务器的强制加速、局域网内特定设备（如仅仅让 Apple TV 走海外节点而让 NAS 保持直连），以及针对特定开发工具（如 Docker 镜像拉取加速）的定向引流。

掌握自定义分流规则语法，能够让你摆脱对第三方臃肿规则的盲目依赖，构建出一套轻量、严谨且零误伤的个性化路由策略。

本指南将带你从语法解析出发，结合生产环境配置范本，全面吃透各类高阶规则的生效机理。

独立第三方声明与客观中立原则

一、核心分流规则语法全景速查表

下表汇总了主流规则引擎（如 Clash Meta、Sing-box、Surge）中支持的 7 大核心规则类型与行为表现：

规则类型代码	匹配对象与维度	典型编写示例	匹配开销	核心应用场景
`DOMAIN`	完全精确的单个域名	`DOMAIN,openai.com,DIRECT`	极低	单一特定域名强制覆写
`DOMAIN-SUFFIX`	顶级域名或子域名后缀	`DOMAIN-SUFFIX,github.com,PROXY`	极低	某个服务旗下所有子域名的批量分流
`DOMAIN-KEYWORD`	域名字符串子串包含	`DOMAIN-KEYWORD,google,PROXY`	中等	包含特定品牌词的所有变体域名
`IP-CIDR`	目标服务器的三层 IP 段	`IP-CIDR,198.51.100.0/24,PROXY,no-resolve`	低	针对固定服务器 IP 块的直连或加速
`SRC-IP-CIDR`	发起请求的局域网内网 IP	`SRC-IP-CIDR,192.168.1.105/32,PROXY`	极低	局域网按设备分流（如指定电视走代理）
`DST-PORT`	传输层目标端口号或范围	`DST-PORT,22,DIRECT`	极低	SSH 远程登录或特定数据库端口直连
`PROCESS-NAME`	本地发起连接的程序名	`PROCESS-NAME,Telegram.exe,PROXY`	适中	绕过域名嗅探直接针对特定软件分流

二、生产级分流配置范本与实操对照

1. Clash 语法格式范例

在 Clash 配置文件的 rules 节点下，按照从上到下的顺序写入具体指令：

yaml

rules:
  # 1. 局域网私有地址无条件保持直连 (必须置顶)
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 2. 开发者常用生产力工具强制走香港优质节点
  - DOMAIN-SUFFIX,github.com,HK-Premium
  - DOMAIN-SUFFIX,githubusercontent.com,HK-Premium
  - DOMAIN-SUFFIX,docker.com,HK-Premium

  # 3. AI 生产力大模型走美国原生节点
  - DOMAIN-SUFFIX,openai.com,US-Node
  - DOMAIN-SUFFIX,claude.ai,US-Node
  - DOMAIN-SUFFIX,anthropic.com,US-Node

  # 4. 指定办公电脑内网 IP 全流量走审计代理
  - SRC-IP-CIDR,192.168.1.188/32,PROXY

  # 5. 国内知名网站与 GeoIP 保持千兆直连
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT
  - GEOIP,CN,DIRECT

  # 6. 最终兜底规则：其余未知境外流量一律走代理
  - MATCH,PROXY

三、关键技术进阶：参数 `no-resolve` 的致命重要性

在编写 IP-CIDR 或 GEOIP 规则时，很多新手会忽略末尾的 ,no-resolve 修饰符，从而掉进严重的DNS 解析死锁黑洞。

1. 未加 no-resolve 导致的灾难

当客户端访问 www.example.com 时：如果前面没有命中任何域名规则，数据流滑落到 - IP-CIDR,198.51.100.0/24,PROXY：客户端为了判断这个请求的目标 IP 是不是落在 198.51.100.0/24 范围内，被迫停下来立刻向系统 DNS 发起该域名的真实 IP 查询。

如果此时网络本身受阻或 DNS 存在污染，系统就会直接卡死在这一步，造成明显的网页打开转圈和 DNS 泄漏。

2. 正确使用规范

对于任何基于纯 IP 的匹配规则，只要你的上一级域名规则已经足够覆盖常用场景，在 IP 规则后务必追加 no-resolve：

yaml

- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

这明确告诉规则引擎：只有当应用层发起的本来就是纯 IP 请求时，才执行该规则比对；对于域名请求，绝不要为了这一行规则而强行触发额外的远端 DNS 预解析。

四、自定义规则编写三大禁忌清单

切忌滥用 DOMAIN-KEYWORD：编写 DOMAIN-KEYWORD,google,PROXY 会导致包含该词汇的正常网站（如 google-fonts.cn 或某些包含 google 字符的国内技术镜像）全部被误送往代理，极大增加规则误杀率。推荐优先使用精确的 DOMAIN-SUFFIX。
切忌颠倒规则优先顺序：规则引擎遵循「首次命中即刻终止」逻辑。如果将宽泛的 - GEOIP,CN,DIRECT 放在了 - DOMAIN-SUFFIX,github.com,PROXY 之前，一旦 GitHub 的某个 CDN 节点被分配了国内边缘 IP，流量就会立刻被误判为直连导致拉取代码失败。
保持规则总量克制：单条手工维护的规则建议控制在 200 行以内。海量的域名匹配应采用外部 rule-providers 规则集进行异步热更新与内存哈希索引，避免配置文件过大引起客户端解析卡顿。

自定义分流规则实战指南：DOMAIN、IP-CIDR、端口与进程级语法全解 (2026) ​

一、核心分流规则语法全景速查表 ​

二、生产级分流配置范本与实操对照 ​

1. Clash 语法格式范例 ​

三、关键技术进阶：参数 no-resolve 的致命重要性 ​

1. 未加 no-resolve 导致的灾难 ​

2. 正确使用规范 ​

四、自定义规则编写三大禁忌清单 ​