机场分流规则入门：规则、全局、直连和规则集

从一条请求看分流发生了什么

你的设备每发出一个网络请求，在离开设备之前，客户端都会按一张规则表逐条比对，然后给它贴上一个出口标签：走某个代理分组，还是直连，还是直接丢弃。这张表就是分流规则。理解这一点之后，很多”为什么这个网站走了那里”的问题就不再神秘了。

以打开一个视频网站为例。浏览器先要解析域名，请求会带着域名（或者 IP）进入客户端；客户端看到域名后依次比对，比如先看是不是局域网地址，再看是不是广告域名，然后看是不是国内服务。命中某一条，就按那一条的出口走，后面的规则不再看。所以规则的顺序和规则的内容同样重要。

客户端的”连接”页面，就是把这个判断结果展示出来的地方。每一条连接通常会显示域名、命中的规则和最终出口。你排查问题时，不需要猜，直接看这一行就行。

三种模式的成本与代价

三个模式的差别，不只是”开关在哪里”，而是决定哪些流量会计入机场额度。下表是通用说明，你可以代入自己的数字。

模式	请求去向	对机场流量的影响	典型用途
规则	按规则逐条判断	只有需要代理的请求计入	日常使用
全局	全部走同一个节点	所有请求计入	临时排查、测试节点
直连	全部不走代理	不计入	判断问题是否来自机场

假设你每天在国内视频站看 2 小时，每小时按 1.5GB 估算，一个月约 90GB。全局模式下这 90GB 会全部计入机场额度；规则模式下，只要国内域名命中直连规则，这部分就不计入。如果你选的是二猫云 ¥20 / 130GB 的月付档，这 90GB 大约占去总额度的七成，省不省差别很大。具体估算方法见 机场流量多少够用。

全局模式并非不能用。它适合三类情况：一是要确认某个节点本身能不能用，全局可以排除规则干扰；二是某个应用不认系统代理，规则匹配不到它；三是在陌生网络里，先用全局确认节点可用，再切回规则。用完就切回规则，长期开着全局等于放弃分流。

分流规则顺序：命中即停的含义

规则是从上到下依次匹配，命中就停。假设你的配置里有两条规则：

1. DOMAIN-SUFFIX,example.com,DIRECT
2. DOMAIN-SUFFIX,video.example.com,PROXY

访问 video.example.com 时，第一条已经按 example.com 的后缀命中，于是直连，第二条永远不会执行。这就是”我加了规则但没生效”的常见原因之一。修复方法不是删掉前面的规则，而是把更具体的那条放到前面。

这个原则也解释了为什么内置规则集通常排在前面：它们覆盖面广，如果自定义规则放在后面，很可能被提前截走。改规则之后，建议用日志确认一次，而不是凭感觉判断。

兜底规则的取舍

兜底规则决定了”没有任何规则命中的请求”去哪里。Clash 系通常写作 MATCH，部分配置写作 FINAL。它是分流里最容易被忽视、却影响最大的一条。

兜底选择	好处	代价	适合
走代理	冷门的海外站点不容易打不开	未识别的国内小站也会计入流量	新手、刚开始使用
直连	流量最省，国内小站稳定	冷门海外站点可能需要补规则	已熟悉规则之后

对大多数新手，我们的建议是兜底走代理，先把国内直连规则补齐。等日志里看清楚哪些国内站点被误走代理，再考虑切到直连。切换的代价只是多维护几条规则，不会有不可逆的影响。

自定义分流规则的写法

自定义规则的结构可以拆成三段：类型、内容、出口。

类型	含义	示例
DOMAIN-SUFFIX	域名后缀，含子域名	DOMAIN-SUFFIX,example.com,PROXY
DOMAIN	完整域名，只匹配这一个	DOMAIN,www.example.com,DIRECT
DOMAIN-KEYWORD	域名包含某个关键词	DOMAIN-KEYWORD,example,PROXY
IP-CIDR	IP 段	IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

出口名称（上例中的 PROXY、DIRECT）要和配置里实际存在的策略组名一致。很多人复制别人的规则，却忘了改名，结果配置加载失败。另外，DOMAIN-KEYWORD 很方便，但范围太宽，可能误伤无关域名，能用后缀匹配就不要用关键词。

用日志做一次完整检查

下面的步骤适用于任何 Clash 系客户端，不同版本名称略有差异。

1. 切换到规则模式，确认订阅已导入、节点可用，导入流程见 Clash 订阅导入。
2. 打开”连接”或”日志”页面，访问你最常用的五个国内站点，记录每个请求的出口，应当是直连。
3. 再访问五个需要代理的海外站点，记录出口，应当是某个代理分组或节点。
4. 对于出口不对的域名，记下它的完整名称，进入”规则”页添加自定义规则，放在靠前的位置。
5. 保存后重新载入配置，再访问一次，确认出口已经变化。

这一轮检查完成之后，你就得到了一份”最常用站点的出口表”。把它存下来，以后更新规则时可以直接对照，而不必每次从头排查。

与其他功能的配合

与 TUN 模式。 系统代理只影响遵守系统代理设置的应用，TUN 则在网卡层接管流量。两者不冲突：TUN 解决”流量进不进得来”，规则解决”进来之后去哪”。开 TUN 之前先确认规则已经调好，否则之前不走代理的软件会被接管，国内流量也可能一起计入。详见 TUN 模式教程。

与 AI 服务。 可以为 ChatGPT、Claude 这类域名单独指定一个稳定的策略组，避免被”自动选择”切到别的地区。具体做法见 ChatGPT 设置。

与流量消耗。 规则正确是控制流量最有效的办法。如果发现额度消耗异常，先检查模式和兜底规则，再看 流量异常消耗。

按现象倒查

现象	常见原因	处理办法
国内网站变慢	开了全局模式，或兜底走代理且国内规则缺失	切回规则模式，补国内直连规则
某个海外网站打不开	被规则判为直连	看日志确认出口，把代理规则放到前面
国内应用提示网络异常	国内域名走了海外节点	为该应用的域名加直连规则
配置加载失败	规则格式错误，或策略组名称不存在	核对类型、内容、出口三段
规则集更新失败	规则集托管地址无法访问	切换网络后重试，或更换规则集源
改了规则没有效果	新规则被前面的规则先命中	把新规则移到靠前位置，重新载入
局域网设备连不上	局域网地址被走了代理	添加局域网地址直连规则
视频会议卡顿	会议软件走了远端节点	国内会议设直连，见 远程办公教程

分流规则集：把名单交给别人维护

规则模式需要的规则从哪里来？如果让你自己逐条写”哪些域名走代理、哪些直连”，写成千上万条并不现实。于是出现了规则集（Rule Set）：由社区维护的一份域名或 IP 名单，客户端定期下载更新。你的配置里通常会引用若干规则集，比如国内域名清单指向直连，广告清单指向拒绝，国外常用服务清单指向代理。

规则集的好处是省事，代价是你不完全掌控它的内容。如果某个国内站点突然走错了路，先检查规则集是否已经更新，再考虑自己加规则。规则集更新失败时，常见原因是托管地址在当前网络下无法访问，此时可以切换网络后再试，或在客户端中更换规则集的来源地址。

维护习惯：少而精

绝大多数人用默认配置就够了。需要动手的情况通常只有四种：常用站点走错了路，公司或学校网络必须直连，某个应用要固定用某个地区的节点，或者要屏蔽特定广告域名。

维护规则的原则是少而精。每多一条规则，将来排查故障时就多一个变量。建议你在规则旁边记下添加日期和原因，并且每个月回看一次日志，把已经不再需要的规则删掉。规则集由社区更新，所以定期更新规则集本身，比手工堆叠自定义规则更省心。

最后给一个判断的捷径：打开日志，看你最常用的十个站点各走了什么出口。如果十个都符合预期，你的分流就已经合格，不必再折腾。