---
title: 什么是分流规则？为什么需要它
date: 2026-05-10
updated: 2026-05-10
categories:
  - 规则与分流
tags:
  - 分流
  - 规则
  - Clash
  - 路由
  - 配置
index_img: /images/posts/what-are-rules.jpg
excerpt: 分流规则决定哪些流量走代理、哪些直连。从零解释分流的概念、规则类型和基本配置方法。
---

> **摘要**：分流规则决定了哪些流量走代理、哪些直连、哪些走特定节点。它是代理客户端的核心能力之一，直接影响上网速度、稳定性和使用体验。本文从零解释分流的概念、工作原理和基本配置方法。

## 为什么不能"全部走代理"

很多刚接触科学上网的人会有一个直觉想法：**既然代理能让我访问被墙的网站，那我把所有流量都走代理不就完了？**

这个想法听起来合理，实际操作却会带来一系列问题。

**第一，国内网站会变慢。** 当你访问百度、淘宝、B站这些国内网站时，如果流量走代理，数据包的路径会变成这样：你的设备 → 境外代理服务器 → 国内目标网站 → 境外代理服务器 → 你的设备。本来一步直达的事情，现在绕了一大圈。延迟从几毫秒变成几十甚至上百毫秒，打开网页明显变慢。

**第二，浪费代理流量。** 大多数机场按流量计费。如果你看B站、刷抖音这些国内流量全部走代理，每月几十 GB 的流量消耗会非常快。这些流量本不需要代理，白白浪费了钱。

**第三，部分国内服务可能异常。** 一些网站和 App 会检查用户的 IP 地址。当它们发现你从一个境外 IP 访问时，可能触发安全验证、限制功能，甚至直接拒绝服务。比如微信支付、银行网银、政务服务网站等，使用境外 IP 访问可能导致账户异常或需要额外验证。

**第四，安全和隐私考虑。** 银行网站、政务网站等涉及敏感操作的服务，最好走直连。你不需要也不应该让这些流量经过第三方代理服务器。

所以，正确的做法不是"全部走代理"，而是**只代理需要代理的流量，其他一切直连**。这就是分流的核心目标。

## 分流的基本逻辑

理解分流的原理并不复杂。

你的设备发出的每一个网络请求，都有一个明确的目标——一个域名（比如 `google.com`）或一个 IP 地址（比如 `142.250.80.46`）。代理客户端会拦截这些请求，把目标信息和一系列规则逐条比对，找到第一条匹配的规则，然后按这条规则指定的方式处理这个请求。

处理方式通常有三种：

- **PROXY（代理）**：通过代理服务器转发这个请求。用于被墙的或需要境外 IP 的网站。
- **DIRECT（直连）**：不经过代理，直接连接目标。用于国内网站和不需要代理的服务。
- **REJECT（拒绝）**：直接丢弃这个请求。通常用于广告拦截和隐私保护。

规则的匹配顺序是**从上到下，逐条检查，命中即停**。这和你在餐厅菜单上从第一行往下看是一样的——看到想吃的就停下来点单，不会再往下翻了。

一个简化的例子：

```
规则1: DOMAIN-SUFFIX,google.com → Proxy     ← 访问 Google，走代理
规则2: DOMAIN-SUFFIX,baidu.com → Direct     ← 访问百度，直连
规则3: GEOIP,CN → Direct                    ← 目标 IP 属于中国，直连
规则4: MATCH → Proxy                        ← 以上都没匹配，走代理（兜底）
```


当你访问 `mail.google.com` 时，客户端从第一条规则开始检查：`google.com` 是不是 `mail.google.com` 的后缀？是的，匹配成功。于是这个请求走代理，后面的规则不再检查。

当你访问 `www.baidu.com` 时，第一条规则不匹配（后缀不是 `google.com`），继续检查第二条：`baidu.com` 是不是 `www.baidu.com` 的后缀？是的，匹配成功。这个请求走直连。

![Clash Verge 规则界面](/images/inline/clash-rules-tab.webp)
*图片来源：[Clash Verge](https://clashverge.net/)*

当你访问一个规则里没有明确列出的境外网站时，前面的域名规则都不匹配。客户端查到第三条 `GEOIP,CN`，检查目标 IP 的所属国家——如果不是中国，继续往下。最终命中第四条 `MATCH`（匹配一切），走代理。

这就是分流的全部核心逻辑。

## 规则类型详解

不同的代理客户端支持的规则类型略有差异，但以下几类是几乎所有主流客户端（如 [mihomo](https://github.com/MetaCubeX/mihomo) 等）都支持的。

### 域名规则

域名规则是最常用、最精准的规则类型。它通过匹配请求的目标域名来决定路由。

**DOMAIN（精确匹配）**

只匹配完全相同的域名，不包含子域名。

```
DOMAIN,www.google.com,Proxy
```

这条规则只匹配 `www.google.com`，不会匹配 `mail.google.com` 或 `google.com`。适用于你需要精确控制某一个具体域名的场景。

**DOMAIN-SUFFIX（后缀匹配）**

匹配指定域名及其所有子域名。这是实际使用中最常见的规则类型。

```
DOMAIN-SUFFIX,google.com,Proxy
```

这条规则会匹配 `google.com`、`www.google.com`、`mail.google.com`、`drive.google.com` 等所有以 `google.com` 结尾的域名。绝大多数情况下，你想代理一个网站时，用 `DOMAIN-SUFFIX` 就够了。

**DOMAIN-KEYWORD（关键词匹配）**

只要域名中包含指定的关键词，就匹配。

```
DOMAIN-KEYWORD,google,Proxy
```

这条规则会匹配所有域名中包含 `google` 这个词的请求——`www.google.com`、`googleapis.com`、`googleusercontent.com` 都会命中。它的覆盖范围很广，但也可能产生误伤。比如，如果一个国内网站的域名碰巧包含这个关键词，也会被代理。使用时需要注意。

### IP 规则

有些网络请求的目标不是域名，而是直接的 IP 地址（某些应用或服务就是这样工作的）。或者，你想根据目标服务器所在的国家来决定路由。这时候需要 IP 规则。

**IP-CIDR（IP 段匹配）**

匹配一个特定的 IP 地址范围。CIDR 是一种标准的 IP 段表示方法。

```
IP-CIDR,91.108.0.0/16,Proxy
```

这条规则匹配所有以 `91.108` 开头的 IP 地址（`91.108.0.0` 到 `91.108.255.255`）。上面这个例子是 Telegram 的 IP 段——Telegram 的服务器用的就是这个 IP 范围，把它走代理可以确保 Telegram 正常连接。

**GEOIP（地理位置匹配）**

根据目标 IP 地址对应的国家或地区代码来匹配。

```
GEOIP,CN,Direct
```

这条规则的含义是：如果目标 IP 属于中国，就直连。这是一条非常实用的兜底规则——即使某个国内网站没有被其他规则命中，只要它的服务器在中国，就会被这条规则捞住并直连。

客户端内置了 IP 地理位置数据库（通常是 MaxMind 的 GeoIP 数据库或 GeoLite2），通过查询数据库来判断 IP 的所属国家。更多规则类型的说明可以参考 [Clash Wiki](https://wiki.metacubex.one/)。

### 进程规则

进程规则不看你访问的目标是什么，而是看是**哪个应用程序**发出的请求。

```
PROCESS-NAME,telegram.exe,Proxy
PROCESS-NAME,wechat.exe,Direct
```

第一条规则的意思是：只要是 Telegram 这个程序发出的网络请求，不管它连接的是什么地址，全部走代理。第二条则让微信的所有流量直连。

进程规则在某些场景下很有用。比如你有一个程序，它连接的地址不固定或者很难通过域名/IP 规则覆盖全，用进程规则可以一刀切地解决。

需要注意的是，进程规则需要客户端具备读取进程信息的权限，在移动设备上的支持可能受限。在 Windows 和 macOS 上通常都能正常工作。

### 其他规则

**RULE-SET / Rule Provider（规则集）**

规则集是将大量规则打包成一个外部文件或在线列表。客户端定期从 URL 下载并更新这些规则。

```
RULE-SET,https://example.com/proxy-list.yaml,Proxy
```

规则集的好处是：你不需要自己维护成百上千条规则。社区维护的规则集会持续更新，新的被墙网站或广告域名会被及时加入。这是目前最推荐的规则管理方式。关于规则集的详细使用方法，会在单独的文章中介绍。

**MATCH（兜底规则）**

`MATCH` 匹配一切请求，不做任何条件判断。它的作用是作为最后一条规则，处理前面所有规则都没有命中的流量。

```
MATCH,Proxy
```

这意味着"如果前面的规则都没匹配上，那就走代理"。你也可以设置成 `MATCH,Direct`，让默认行为变成直连——这取决于你的使用习惯和需求。

把 `MATCH` 设为代理意味着"宁可多代理，也不漏掉需要代理的"。设为直连意味着"宁可多直连，也不浪费代理流量"。两种策略各有取舍。

**DST-PORT / SRC-PORT（端口匹配）**

按目标端口或源端口来匹配。使用场景不多，一般用于特殊用途。

```
DST-PORT,22,Direct
```

这条规则表示所有目标端口为 22（SSH）的流量走直连。

## 代理策略组（Proxy Groups）

到目前为止我们讨论的规则，最终都指向一个"策略"——Proxy、Direct 或 Reject。但在实际使用中，"走代理"这件事还可以更细致：你可能有多个代理节点，该选哪一个？

这就是策略组（Proxy Group）解决的问题。策略组是一组代理节点的集合，加上一个选择策略。规则不直接指向某个具体节点，而是指向一个策略组，由策略组来决定最终使用哪个节点。

### select（手动选择）

最直观的策略组。你自己从列表中选一个节点。

```yaml
- name: "Overseas"
  type: select
  proxies: [HK-01, HK-02, JP-01, US-01, SG-01]
```

适合对节点有明确偏好的用户。比如你知道某个香港节点速度最好，就手动选它。

### url-test（自动选最快）

客户端定期测试组内所有节点到指定 URL 的延迟，自动选择延迟最低的节点。

```yaml
- name: "Auto-Fast"
  type: url-test
  proxies: [HK-01, HK-02, JP-01, US-01]
  url: http://www.gstatic.com/generate_204
  interval: 300
```

`interval: 300` 表示每 300 秒（5 分钟）测试一次。如果当前节点变慢了，客户端会自动切换到更快的节点。这是懒人首选——设置好之后基本不用管。

### fallback（故障转移）

按列表顺序优先使用第一个可用的节点。如果第一个节点挂了，自动切换到第二个，依此类推。

```yaml
- name: "Reliable"
  type: fallback
  proxies: [HK-01, HK-02, JP-01]
  url: http://www.gstatic.com/generate_204
  interval: 300
```

和 url-test 的区别是：fallback 不追求最快，只追求可用。只有当前节点不可用时才切换。适合追求稳定性的用户。

### load-balance（负载均衡）

将流量分散到组内多个节点上，避免单个节点负载过高。

```yaml
- name: "Balance"
  type: load-balance
  proxies: [HK-01, HK-02, HK-03]
  strategy: consistent-hashing
```

一般用户用到 load-balance 的场景不多。它更适合有大量并发连接需求的用户。

### 策略组的嵌套

在实际配置中，策略组是可以嵌套的。一个策略组的成员可以是另一个策略组：

```
规则                    → 策略组              → 实际节点
google.com              → "Overseas" (select)  → [Auto-HK, Auto-JP, Auto-US, Direct]
netflix.com             → "Streaming" (select) → [US-Netflix, SG-Netflix]
openai.com / claude.ai  → "AI-Services" (select) → [US-01, JP-01]
baidu.com               → DIRECT
```

这个结构的逻辑是：

- 访问 Google 时，流量进入"Overseas"策略组。你可以在"Auto-HK"（自动选最快的香港节点）、"Auto-JP"（自动选最快的日本节点）等子组之间手动切换。
- 访问 Netflix 时，流量进入"Streaming"策略组。因为 Netflix 对 IP 有严格限制，这里放的是专门能解锁 Netflix 的节点。
- 访问 OpenAI 或 Claude 时，进入"AI-Services"策略组。这些 AI 服务对 IP 地区有要求，需要特定地区的节点。
- 访问百度等国内网站时，直连。

这种分层设计让你可以对不同类型的流量使用不同的节点策略，灵活且清晰。

## 一个典型的分流方案

把前面讲的所有内容组合起来，一个实际的分流配置看起来是这样的：

```yaml
rules:
  # 第一层：广告拦截（优先级最高）
  - RULE-SET,reject-list,REJECT

  # 第二层：国内直连
  - RULE-SET,cn-direct,DIRECT
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-SUFFIX,com.cn,DIRECT

  # 第三层：流媒体（需要特定地区节点）
  - RULE-SET,netflix,Streaming
  - RULE-SET,disney,Streaming
  - RULE-SET,youtube,Overseas

  # 第四层：AI 服务（需要特定节点）
  - RULE-SET,openai,AI-Services
  - RULE-SET,claude,AI-Services

  # 第五层：其他常见代理需求
  - RULE-SET,telegram,Overseas
  - RULE-SET,twitter,Overseas
  - RULE-SET,google,Overseas

  # 第六层：兜底
  - GEOIP,CN,DIRECT
  - MATCH,Overseas
```

这个方案的逻辑层次非常清晰：

1. **最先处理广告**。已知的广告域名和追踪器直接拒绝，不浪费任何带宽。
2. **然后处理国内流量**。已知的国内域名直连，不走代理。
3. **接着处理特殊需求的境外流量**。流媒体和 AI 服务需要特定地区的节点，分别指向专门的策略组。
4. **再处理其他常见的境外流量**。Google、Telegram、Twitter 等常用服务走通用的"Overseas"策略组。
5. **最后兜底**。通过 GEOIP 确保所有中国 IP 直连，其余所有未命中的流量走代理。


## 分流规则从哪来

作为普通用户，你不需要也不应该自己一条条手写几千条规则。规则的来源通常有以下几种：

**机场订阅自带规则。** 很多机场的订阅链接里已经包含了基本的分流规则。你导入订阅后，客户端会自动应用这些规则。对于大多数用户来说，这些自带的规则已经够用了。

**社区维护的规则集（Rule Providers）。** 开源社区维护着大量高质量的规则集，覆盖各种常见网站和服务。知名的规则集项目包括：

- **[Loyalsoldier clash-rules](https://github.com/Loyalsoldier/clash-rules)**：基于 v2ray/Clash 的规则集，分类清晰，更新及时。
- **[ACL4SSR](https://github.com/ACL4SSR/ACL4SSR)**：老牌规则集项目，适用于 Clash 系列客户端，提供多种预配置方案。
- **blackmatrix7**：覆盖面很广的规则集合，按应用和服务分类。

这些规则集通常以在线 URL 的形式提供，你只需要在客户端配置中引用它们的地址，客户端会自动下载和定期更新。

**自定义规则。** 当你发现某个特定网站没有被现有规则覆盖时，可以自己添加规则。比如一个小众网站被墙了但不在任何规则集里，你可以手动加一条 `DOMAIN-SUFFIX` 规则来解决。

**客户端内置规则。** 一些客户端软件自带默认的分流规则或规则模板。比如 Clash Verge Rev 提供了内置的规则配置模板，新手可以直接使用。

## 常见问题

### 规则越多越好吗？

不是。规则的数量直接影响匹配速度。每一个网络请求都需要从第一条规则开始逐条检查，规则越多，检查的时间越长。虽然现代设备的性能足以应对几千条规则，但组织良好的规则集远比杂乱无章的大量规则更高效。质量比数量重要。

好的做法是使用规则集（Rule Provider）而不是把所有规则直接写在配置文件里。规则集在加载时会被优化为高效的数据结构，匹配速度远快于逐条检查。

### 规则顺序重要吗？

非常重要。分流规则是"先到先得"的——第一条匹配的规则决定了流量的去向，后面的规则不会再被检查。

举个例子：

```
规则1: DOMAIN-KEYWORD,google,Proxy
规则2: DOMAIN-SUFFIX,google.cn,Direct
```

如果你访问 `google.cn`（谷歌中国），规则1会先匹配成功（因为域名包含"google"这个关键词），导致 `google.cn` 走了代理。但实际上 `google.cn` 是可以直连访问的国内服务，走代理反而变慢了。正确的做法是把更具体的规则放在更通用的规则前面：

```
规则1: DOMAIN-SUFFIX,google.cn,Direct    ← 具体规则在前
规则2: DOMAIN-KEYWORD,google,Proxy       ← 通用规则在后
```

记住两个原则：**具体规则在前，通用规则在后**；**`MATCH` 永远放最后一条**。

### 怎么知道某个网站走了代理还是直连？

大多数代理客户端都提供了连接日志功能，可以实时查看每一个网络请求匹配了哪条规则、最终走了代理还是直连。

以 Clash Verge Rev 为例，在"连接"（Connections）标签页中，你可以看到所有活跃的网络连接。每条连接会显示目标地址、匹配的规则、使用的策略组和具体节点。如果某个网站的路由不符合你的预期，在这里可以快速定位原因。

其他客户端也有类似功能：v2rayN 有日志面板，Surge 有请求查看器，Shadowrocket 有日志页面。

### 我的机场订阅已经有规则了，还需要自己配吗？

对于大多数用户来说，机场自带的规则已经足够覆盖日常使用。它们通常已经包含了常见国内网站直连、常见国外网站代理的规则。

你需要自定义规则的场景通常是：

- 某个特定网站路由不正确（应该直连的走了代理，或者应该代理的直连了）
- 你想对特定服务使用特定地区的节点（比如 Netflix 走美国节点）
- 你想添加广告拦截规则
- 你有一些小众需求，机场默认规则没有覆盖

遇到这些情况时，在现有规则的基础上添加几条自定义规则就够了，不需要从头配置整套规则。

### 不同客户端的规则语法一样吗？

大致相同，但有细微差异。`DOMAIN-SUFFIX`、`DOMAIN`、`IP-CIDR`、`GEOIP`、`MATCH` 这些基本规则类型在 Clash、Surge、Shadowrocket、Quantumult X 等主流客户端中都通用。差异主要在配置文件格式（YAML vs JSON vs 自有格式）和一些高级规则类型上。

如果你使用机场提供的订阅链接，客户端通常会自动转换为适合自己的格式，你不需要手动处理这些差异。