tech/network · 集群 B · 隧道与排障原理 · 2/6
分流原理:域名、IP 与进程规则如何决定流量走向
规则型代理对每条连接按规则列表自上而下匹配,命中第一条即停止,并把流量交给该规则指定的策略(代理、直连或拒绝)。域名规则在拿到域名时即可判断,IP 规则需要先知道目标 IP,可能触发 DNS 解析。如果你遇到“该走代理的走了直连”,通常是规则顺序、解析时机或接管方式三者之一出了问题。
分流要解决什么问题
分流要解决的问题是:不是所有流量都需要走代理。境内网站走代理会绕远路变慢,局域网设备走代理会直接不通,而部分境外服务又需要代理才能访问。分流就是让客户端对每一条连接做出判断,把它送往合适的出口。
┌──▶ 代理(策略组 → 节点)
[连接] ─▶ [规则引擎] ─┼──▶ 直连(本地出口)
└──▶ 拒绝(丢弃,如广告)
理解分流原理有两个实际好处:一是遇到“该走代理的没走”时能快速定位原因;二是看懂订阅配置里的规则,知道哪些可以按需调整。具体的客户端操作请参考 桌面客户端 专题,本文聚焦原理。
常见的规则类型
规则型代理内核(例如 Clash 系内核)支持多种规则类型,按匹配依据可以分为四大类。不同内核的规则名称和支持范围可能不同,以所用内核的文档为准。
| 类别 | 常见规则 | 匹配依据 | 是否需要 IP |
|---|---|---|---|
| 域名类 | 完整域名、域名后缀、域名关键字 | 连接请求中的域名 | 否 |
| IP 类 | IP 网段、地理位置数据库 | 目标 IP 地址 | 是 |
| 进程类 | 进程名、进程路径 | 发起连接的程序 | 否 |
| 其他 | 端口、协议、规则集、兜底 | 端口号、规则集合、默认 | 视情况 |
规则集是把一批同类规则打包成一个外部文件,客户端定期更新。它让配置更简洁,也方便维护大量域名和网段,但需要注意规则集文件的来源与更新是否可靠。
自上而下、命中即停
规则匹配的基本逻辑是:从第一条开始依次比较,命中第一条符合条件的规则后立即停止,后面的规则不再检查。这意味着规则的顺序就是优先级。
规则列表(示意):
1. 域名后缀 局域网相关 → 直连
2. 域名后缀 广告相关 → 拒绝
3. 域名后缀 某境外服务 → 代理
4. IP 网段 私有地址 → 直连
5. 地理位置 境内 → 直连
6. 兜底 → 代理
连接 a.example 到来:
第1条?否 → 第2条?否 → 第3条?是 → 走代理,停止
由此可以推出几条实用原则:
- 越具体的规则越靠前:精确域名放在宽泛关键字前面,避免被提前“截胡”;
- 局域网与私有地址优先直连:放在最前,防止内网访问被送进代理;
- 兜底规则必须在最后:它会匹配所有流量,放在前面会让后续规则全部失效;
- 自定义规则插在订阅规则之前:否则可能永远轮不到。
域名规则与 IP 规则的触发时机
域名规则和 IP 规则最大的区别在于何时能做出判断,这直接关系到 DNS 解析与分流结果是否一致。
当应用通过系统代理或 Fake-IP 方式把连接交给内核时,内核往往先拿到的是域名。此时域名规则可以直接比较;但当匹配进行到 IP 类规则时,内核需要知道目标 IP,于是会先解析域名。
连接(只有域名)
│
├─ 遇到域名规则 → 直接比较 → 命中/不命中
│
└─ 遇到 IP 规则 → 需要 IP → 触发 DNS 解析
│
├─ 本地解析被污染 → 拿到错误 IP → 误判
└─ 解析正常 → 正确比较
这就是为什么分流问题经常和 DNS 问题纠缠在一起。如果解析结果不可靠,按 IP 判断就会出错;如果解析走了本地 DNS,还可能造成泄漏。DNS 原理与 Fake-IP 机制详见 DNS 污染是什么。部分内核提供“IP 规则不触发解析”的选项,代价是这类连接可能匹配不到 IP 规则而落到兜底。
策略组:规则指向哪里
规则决定“去哪类出口”,策略组决定“具体用哪个节点”。规则的目标通常不是单个节点,而是一个策略组,组内可以有多个节点,按选择方式工作。
| 策略组类型 | 选择方式 | 适合场景 |
|---|---|---|
| 手动选择 | 用户指定 | 需要固定地区或固定节点 |
| 自动测速 | 定期测延迟选最低 | 追求低延迟、可接受切换 |
| 故障转移 | 按顺序选第一个可用 | 优先使用某节点,失败才切换 |
| 负载均衡 | 分散到多个节点 | 多连接下载等场景 |
需要注意,自动测速依据的延迟测试只反映到测试地址的一段,并不等同于实际访问质量;频繁切换节点还可能导致部分网站因出口 IP 变化而要求重新验证。这类与 IP 相关的问题可参考 节点与 IP 专题。
进程规则与接管方式的关系
进程规则按“哪个程序发起的连接”来分流,非常适合“让某个软件全部走代理或全部直连”的需求。但它有一个前提:客户端必须能识别出连接来自哪个进程。
在系统代理模式下,只有主动使用代理的程序才会进入内核,未进入的程序再怎么写进程规则也无效;在 TUN 模式下,内核能看到更多连接,进程识别的覆盖面更广。不同操作系统对进程识别的支持程度不同,部分平台可能需要额外权限。TUN 的原理见 TUN 虚拟网卡原理。
常见分流误判与原因
分流出错时,几乎总能归到以下几类原因之一:
| 现象 | 可能原因 | 检查方法 |
|---|---|---|
| 该走代理的走了直连 | 被前面更宽泛的直连规则截胡 | 看日志中命中的规则 |
| 同一网站时而代理时而直连 | IP 规则依赖的解析结果不稳定 | 看解析来源与 Fake-IP 设置 |
| 自定义规则不生效 | 位置在订阅规则之后,或订阅更新覆盖 | 检查规则顺序与覆写方式 |
| 某软件完全不受规则控制 | 软件不走系统代理 | 改用 TUN 或检查软件代理设置 |
| 局域网设备无法访问 | 私有地址被送进代理 | 在最前面添加私有地址直连 |
排查分流问题最有效的工具是客户端日志或连接面板,它会显示每条连接命中了哪条规则、走了哪个策略组。系统性的排查流程见 分层排障法。
小结
分流的本质是“对每条连接做一次有序的条件判断”。记住三点:规则自上而下、命中即停;域名规则立即判断、IP 规则可能触发解析;规则能否生效取决于流量是否被接管。掌握这三点,大部分分流问题都能自己定位。
如果你在选择服务时关心客户端对规则分流的支持,可以在 机场品牌库 查看各品牌的客户端资料,或使用 对比工具 对照。资料数据本站未实测,请以实际使用为准。
常见问题
规则匹配为什么是“命中第一条就停止”?
这是为了让决策确定且高效。规则从上到下逐条比较,第一条符合条件的规则决定流量去向,后面的规则不再检查,所以越具体的规则应该越靠前。
IP 规则为什么会导致额外的 DNS 查询?
当连接只携带域名而遇到 IP 类规则时,内核需要先把域名解析成 IP 才能比较。如果解析走了本地 DNS,就可能出现泄漏或因污染而误判。部分内核允许为 IP 规则设置不触发解析的选项。
最后一条 MATCH 规则是做什么的?
它是兜底规则,所有前面都没命中的流量都按它处理。兜底走代理还是直连,决定了“未知流量”的默认去向,是分流策略的基础选择。
进程规则在什么情况下有用?
当你希望某个特定软件全部走代理或全部直连,而它访问的域名又难以穷举时,进程规则很方便。它通常需要客户端能识别发起连接的进程,部分平台或模式下可能不可用。
信息来源与更新时间
- 信息来源
- 品牌清单资料(品牌公开信息整理)
- 测试范围
- 本站未进行测速与解锁实测,所有能力描述均为资料声明或未测试状态。
- 发布时间
- 待核实
- 核实日期
- 待核实
- 最近更新
- 待核实