首页/进阶配置

Clash 进阶配置手册

跑通基础连接之后，真正决定 Clash 好不好用的是规则引擎和代理组的组合方式。这一篇深入拆解匹配顺序、四种代理组的行为差异、DNS 与 Fake-IP 原理、TUN 模式底层机制，每一节都配真实可用的 YAML 片段。

🕒 阅读约 20 分钟 🧭 需要先完成安装教程 🔄 最近更新：2026 年 7 月

规则引擎是怎么匹配的

Clash 的规则是一个「自上而下、命中即停」的列表：每一条网络请求都会从 rules 配置的第一行开始逐条比对，一旦某条规则匹配成功，立刻执行该规则指定的动作，后面的规则完全不会再看。

这意味着规则的顺序本身就是一种优先级设计。常见的组织方式是：先写"必须直连"的规则（比如内网地址、国内网站），再写"必须代理"的特定规则，最后用一条 MATCH 兜底规则收尾，代表"以上都没命中时怎么办"。

config.yamlyaml
rules:
  # 1. 私有网段优先直连，避免代理绕路访问局域网设备
  - PRIVATE,DIRECT
  # 2. 国内 IP 直连（GEOIP 规则集会自动更新）
  - GEOIP,CN,DIRECT
  # 3. 特定域名强制走某个代理组
  - DOMAIN-SUFFIX,openai.com,美国节点
  - DOMAIN-KEYWORD,googlevideo,自动选择
  # 4. 兜底：前面都没命中的流量走自动选择
  - MATCH,自动选择
⚠️

常见误区：把 MATCH 规则写在中间。因为匹配是命中即停的，MATCH 之后的规则永远不会被执行到，所以它必须放在整个 rules 列表的最后一行。

规则类型详解

Clash 支持的规则类型大致分三类：按域名、按网络地址、按其他特征。下表列出最常用的几种：

规则类型示例说明
DOMAINDOMAIN,ad.example.com,REJECT精确匹配单个域名
DOMAIN-SUFFIXDOMAIN-SUFFIX,github.com,代理匹配该域名及其所有子域名，最常用
DOMAIN-KEYWORDDOMAIN-KEYWORD,youtube,代理域名中包含关键字即命中，注意可能误伤
IP-CIDR / IP-CIDR6IP-CIDR,192.168.0.0/16,DIRECT按 IPv4/IPv6 网段匹配
GEOIPGEOIP,CN,DIRECT按 IP 所属国家/地区的地理位置库匹配
DST-PORT / SRC-PORTDST-PORT,443,代理按目标/源端口匹配
PROCESS-NAMEPROCESS-NAME,WeChat.exe,DIRECT按发起连接的本机进程名匹配（桌面端）
RULE-SETRULE-SET,reject,REJECT引用一个 Rule Provider 规则集，见下一节
MATCHMATCH,自动选择兜底规则，必须放在最后一行

每条规则的最后一段是「动作」，可以是 DIRECT（直连）、REJECT（拦截，常用于去广告）、或某个代理组的名字（把流量交给该组按其策略选择节点）。

Rule Provider：规则集订阅

手写几百条域名规则不现实，Clash 提供了 rule-providers 机制：从远程 URL 下载一份规则集文件，并定时自动更新，配置里只需引用一次。

config.yamlyaml
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/rules/reject.txt"
    path: ./rules/reject.yaml
    interval: 86400

rules:
  - RULE-SET,reject,REJECT

behavior 决定了这份规则集里的内容如何解析，三种取值：

behavior规则集内容典型用途
domain逐行域名（支持通配前缀）广告过滤、按站点分流的域名列表
ipcidr逐行 IP 网段GEOIP 数据库之外的自定义 IP 段
classical与 rules 里写法一致的完整规则行混合多种规则类型的复杂集合

interval 单位为秒，表示自动重新拉取规则集的间隔，用来让"该拦截的新广告域名""该直连的新国内域名"保持更新，而不需要你手动维护。

代理组：四种调度策略

代理组（proxy-groups）是把多个具体节点包装成一个"策略单元"，规则里引用的是组名，而不是某个具体节点——这样才能实现"自动选最快节点""某个节点挂了自动切换"等效果。

select 手动选择

  • 完全由你手动指定当前使用哪个节点
  • 适合你很清楚该用哪条线路的场景
  • 不会自动测速、不会自动切换

url-test 自动测速

  • 定时对组内所有节点发起测速请求
  • 始终自动使用延迟最低的节点
  • 最适合"我不想管，只要最快就行"

fallback 故障转移

  • 按配置顺序使用第一个"健康"的节点
  • 当前节点测速失败才切到下一个
  • 适合有明确优先级、只在故障时切换的场景

load-balance 负载均衡

  • 把不同连接分散到多个节点上
  • strategy 可选一致性哈希或轮询
  • 适合多节点分摊压力、避免单节点限速
config.yamlyaml
proxy-groups:
  - name: 自动选择
    type: url-test
    proxies: [香港01, 香港02, 日本01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

  - name: 美国节点
    type: fallback
    proxies: [美西01, 美东01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

tolerance 是「容差」，单位毫秒：只要新测速结果与当前节点的延迟差距在容差范围内，就不会频繁切换节点，避免"两个节点延迟都差不多却反复跳来跳去"。

DNS 与 Fake-IP

DNS 解析是规则分流准确与否的关键一环——如果域名被解析成了错误的 IP，或者被运营商 DNS 污染，规则再准也没用。Clash 内置 DNS 模块正是为了解决这个问题。

核心是两种域名解析模式：

Fake-IP 模式

  • 给每个域名分配一个虚假的、仅本机可见的 IP
  • 真正的 DNS 解析延后到实际发起连接时才做
  • 规则匹配可以直接按域名进行，兼容性最好
  • 是桌面端 TUN 模式的默认推荐配置

Redir-Host 模式

  • 直接返回真实解析结果
  • 更贴近"传统"网络行为，兼容部分对 IP 敏感的程序
  • 规则里的 IP-CIDR/GEOIP 判断会更准确
  • 路由器/网关场景更常用
config.yamlyaml
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

思路是：nameserver 里放国内 DNS，优先用于解析国内域名；一旦 fallback-filter 判断结果不像是国内 IP（涉嫌被污染或该域名本就在境外），就改用 fallback 里的境外/加密 DNS 重新解析，兼顾速度与准确性。

TUN 模式底层原理

系统代理只能接管"知道要用代理"的应用（浏览器、大部分桌面软件），但很多程序（游戏、命令行工具、部分手机 App）不会读取系统代理设置，这时就需要 TUN 模式。

TUN 模式的本质是在操作系统里创建一张虚拟网卡，并把系统的默认路由指向这张网卡。这样一来，不管某个程序有没有"代理意识"，它发出的网络包都会先经过这张虚拟网卡，被 Clash 拦截、按规则处理，再决定直连还是转发给某个代理节点——相当于在网络层做了一次全局劫持，而不是在应用层"劝说"程序使用代理。

config.yamlyaml
tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

stack 通常可选 system 或 gvisor：system 使用系统原生网络栈，性能更好；gvisor 是纯用户态实现的网络栈，兼容性更强，在少数系统 TUN 驱动不稳定时可以切换尝试。

💡

正因为 TUN 模式工作在网络层，它需要创建虚拟网卡的系统权限（管理员/Root，或 macOS 的系统扩展授权），这也是安装教程里反复提到"以管理员身份运行"的原因。

脚本与 Logic 规则

当普通规则类型不够用时，Clash 的增强内核（如 mihomo）支持两种更灵活的写法：

  • Logic 规则：用 AND / OR / NOT 组合多个条件，比如"目标端口是 443 并且 属于某个 IP 段"才代理，写法为 AND,((DST-PORT,443),(IP-CIDR,10.0.0.0/8))。
  • Script Provider：允许写一小段脚本，在运行时动态返回该请求应该走哪个代理组，用于"按当前网络环境""按时间段"等普通规则无法描述的复杂判断，属于高级用法，建议先熟练掌握普通规则后再尝试。

性能与体验调优

  • 缩短 url-test 的 interval 会更快发现变慢的节点，但也会增加测速请求的频率与耗电，桌面端可以设 300 秒，移动端建议 600 秒以上。
  • 规则集数量不要贪多，每新增一个 rule-providers 都会占用内存并增加规则匹配的计算量，优先选择维护活跃、覆盖面广的规则集，而不是叠加十几个高度重叠的来源。
  • 合理排序 rules：把命中率最高的规则（例如 GEOIP,CN,DIRECT）尽量往前放，可以让大多数请求更快完成匹配，减少不必要的逐行比对。
  • 移动端优先用系统代理而非 TUN，除非确实需要接管非代理感知应用，因为 TUN 模式在部分手机上会带来更高的后台耗电。

把这几节内容和实际配置对照阅读一遍之后，建议接着查阅配置文件完整参考，把每个字段的默认值和取值范围都过一遍，构建出完整的知识地图。