Clash 进阶配置手册

01策略组类型与实战

策略组(proxy-groups)是整份配置的调度中枢。规则匹配的结果通常不直接指向某个节点,而是指向一个策略组;组再按自身类型决定流量的实际出口。理解每种组类型的行为差异,是搭建一份可长期维护的配置的第一步。Clash 内核支持的常用组类型有四种:select、url-test、fallback 与 load-balance,各自解决不同的调度问题。

select:手动选择组

select 是最基础的组类型,出口由用户在客户端界面手动指定。它不做任何测速与健康检查,选中哪个就一直使用哪个,直到手动更换或该节点从订阅中消失。这种"完全听指挥"的特性使它适合放在配置的最外层,充当总开关:把若干功能组、地区组连同 DIRECT 一起收进一个名为"节点选择"的 select 组,规则统一指向它,日常切换只需要在界面点一下。

select 组的必填字段只有 name、type 与 proxies 三项。proxies 列表里可以混排具体节点名、其他策略组名,以及两个内置策略:DIRECT 表示直连不走代理,REJECT 表示直接拒绝连接。组名之间引用时必须与定义完全一致,包括空格与大小写,写错会在启动时报"组不存在"的错误。

url-test 与 fallback:自动化调度

url-test 组周期性地对组内所有节点发起一次轻量 HTTP 请求,选出延迟最低的节点作为当前出口。三个关键参数需要理解清楚:url 是测速目标,惯例使用返回 204 状态码、响应体为空的地址,尽量减少测试本身消耗的流量;interval 是测试周期,单位为秒,常用值 300,设得太短会造成频繁的后台请求;tolerance 是切换容差,单位为毫秒——只有当新的最优节点比当前节点快出这个差值时才会真正切换。不设 tolerance 时,两个延迟接近的节点可能因为测量抖动来回切换,导致出口 IP 频繁变化。

fallback 组则按 proxies 列表的书写顺序做可用性检查,始终使用列表中第一个通过检查的节点;当它失效时顺延到下一个,恢复后自动切回。它与 url-test 的本质区别在于关注点不同:url-test 关心"谁的延迟最低",fallback 关心"谁排在最前且还活着"。因此 fallback 适合"主力线路 + 备用线路"的场景——把最稳定、最信任的节点写在第一位,把兜底线路依次排在后面,平时始终走主力,主力故障时无感切换。

load-balance:负载均衡

load-balance 组把连接分散到组内多个节点上。strategy 字段取 consistent-hashing 时,按目标域名做一致性哈希,同一个网站的请求固定落在同一个节点上,可以避免登录态因为出口 IP 反复变化而失效;取 round-robin 时逐连接轮换出口,流量分散得更均匀,但对会话敏感的站点不友好。实践中,负载均衡更适合大流量下载、批量抓取这类对出口 IP 不敏感的用途,不建议给需要稳定登录状态的服务使用。

组嵌套与结构设计

实战推荐"功能组引用地区组"的两层结构:先按地区建立若干 url-test 组(如"香港自动""日本自动"),再按用途建立若干 select 功能组(如"流媒体""AI 服务""兜底选择"),功能组的候选项写地区组的名字而不是具体节点。这样订阅节点增减、改名时只影响地区组一层,规则与功能组完全不需要动;换一家订阅,也只需重建地区组即可。唯一要注意的是避免组与组之间形成循环引用——A 组引用 B 组、B 组又引用 A 组,内核会在启动时报错拒绝加载。

proxy-groups:
  - name: 节点选择
    type: select
    proxies: [香港自动, 日本自动, 故障转移, DIRECT]

  - name: 香港自动
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 60
    proxies: [HK-01, HK-02, HK-03]

  - name: 故障转移
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, JP-01, SG-01]

  - name: 批量下载
    type: load-balance
    strategy: consistent-hashing
    proxies: [HK-01, HK-02, JP-01]

02规则集订阅化管理

把几千条分流规则直接写进主配置文件,有两个长期问题:一是主配置臃肿难以维护,想调整一条规则要在几千行里翻找;二是规则数据(广告域名、地区 IP 段)本身在持续更新,写死在配置里就永远停在写入那一天。rule-providers(规则提供器)把规则拆成独立文件,按周期自动拉取更新,主配置里只留一行引用,是规则管理的标准做法。

rule-providers 的字段含义

每个提供器是一个命名条目,核心字段逐个说明。type 取 http 表示从远程地址周期拉取,取 file 表示读取本地文件、不做自动更新;url 是远程规则文件地址;path 指定本地缓存路径,省略时内核会按 url 的哈希自动命名缓存文件;interval 是更新周期,单位秒,86400 即一天,规则数据更新频率不高,没有必要设得更短。

behavior 决定文件内容的解释方式,是最容易配错的字段:domain 表示文件是纯域名列表,每行一个域名(支持 +. 通配前缀);ipcidr 表示文件是 IP 网段列表;classical 表示文件按行书写完整规则,可以混合 DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME 等多种类型。behavior 与文件实际内容不匹配时,轻则规则全部失配,重则加载报错。format 声明文件格式:yaml 与 text 通用性最好;mrs 是 mihomo 内核的二进制格式,体积小、加载快,但只支持 domain 与 ipcidr 两种 behavior。

在 rules 中引用

提供器定义好后,在 rules 段用 RULE-SET,提供器名,策略组名 的格式引用。ipcidr 类规则集建议在末尾追加 no-resolve 参数:IP 类规则要拿到目标 IP 才能匹配,如果连接目标是域名,内核会先发起一次 DNS 解析再比对——no-resolve 告诉内核跳过这次解析,域名型连接直接视为不匹配、继续往下走。这既避免了不必要的解析开销,也防止在 fake-ip 模式下产生多余的真实解析请求。

rule-providers:
  ad-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rulesets/ad-domains.yaml
    path: ./ruleset/ad-domains.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: mrs
    url: https://example.com/rulesets/cn-ip.mrs
    path: ./ruleset/cn-ip.mrs
    interval: 86400

rules:
  - RULE-SET,ad-domains,REJECT
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - MATCH,节点选择

匹配顺序与更新排查

规则自上而下逐条匹配,第一条命中即停止,后面的规则不再参与——因此规则集的排列顺序就是优先级:拒绝类(广告)放最前,精确的域名类规则在前,宽泛的 IP 类规则在后,最后必须有一条 MATCH 兜底,否则未命中的流量行为不可预期。想确认某个网站到底命中了哪条规则,最直接的办法是打开第七章介绍的控制面板,在连接页查看该连接的规则列。

规则集更新失败是常见问题。排查思路:规则文件的拉取本身也要经过网络,如果拉取地址在当前网络环境下无法直连,冷启动(还没有任何可用代理)时就会拉取失败——解决办法是选择可以直连的镜像地址,或确保首次启动前缓存文件已经存在;其次查看内核日志中 provider 相关的报错,常见原因是 behavior 与文件内容不符、format 声明错误;最后可以手动删除 path 指向的缓存文件,重启内核强制重新下载。

03DNS 配置优化

Clash 的内建 DNS 不是可有可无的附属功能:域名类规则的匹配、fake-ip 映射的生成、DNS 请求是否绕开本地污染,都取决于这一段配置。默认配置在多数场景能用,但要做到"直连域名解析快、代理域名结果准、全程不泄漏",需要理解每个字段的分工。

基础字段

enable: true 打开内建 DNS;listen 指定监听地址与端口,TUN 模式的 DNS 劫持会把系统查询转发到这里;enhanced-mode 在 fake-ip 与 redir-host 之间二选一,两者的取舍在下一章展开。default-nameserver 是一个容易被忽略的字段:后面 nameserver 列表里如果填的是 DoH 地址(形如 https://…/dns-query),这些地址本身也是域名,需要先被解析出来——default-nameserver 就负责这一步,因此它只能填纯 IP 地址,不能再填域名,否则形成解析死循环。

nameserver 是主解析组,承担大部分域名的解析。建议填写当前网络环境下可稳定直连的加密 DNS 地址,保证直连流量的解析速度与准确性;明文 53 端口的传统 DNS 也可以用,但在部分网络下明文查询可能被中间设备篡改,优先选 DoH 或 DoT。

fallback 与 fallback-filter

fallback 组面向"主解析组结果可能被污染"的域名。当 nameserver 与 fallback 同时存在时,内核会向两组并发发起查询,再由 fallback-filter 决定采信哪边的结果:geoip: true 且 geoip-code: CN 表示——如果 nameserver 返回的 IP 属于中国大陆,就认为这是一个国内域名、结果可信,采用 nameserver 的答案;否则认为该域名应当走境外解析,采用 fallback 的答案。ipcidr 子字段则列出已知的污染结果网段(如保留段 240.0.0.0/4),nameserver 返回的 IP 落在这些网段里时直接判定为污染、改用 fallback 结果。

这套机制的效果是:国内域名由就近的国内 DNS 解析,拿到 CDN 优选 IP;境外域名的解析结果经由 fallback 组的加密通道获得,不受本地污染影响。需要注意 fallback 里的加密 DNS 地址应当是在代理可用时能正常访问的,否则并发查询中 fallback 一侧长期超时,会拖慢整体解析。

nameserver-policy:定向解析

nameserver-policy 允许把特定域名指派给特定上游,优先级高于 nameserver 与 fallback 的通用逻辑。典型用法有两类:公司内网域名必须交给内网 DNS 服务器解析,否则解析不出结果;某些对 CDN 调度敏感的国内大站,固定交给某一家国内 DoH,避免并发机制引入的不确定性。键支持 +. 通配前缀,匹配自身与全部子域名。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  nameserver-policy:
    "+.corp.example.com": 10.0.0.53

泄漏验证

配置完成后应当实际验证一次:连接代理后访问 DNS 泄漏检测类网站,观察检测出的解析服务器归属地——如果境外域名的解析请求仍显示由本地运营商 DNS 发出,说明存在泄漏,常见原因是系统里残留了手工指定的 DNS、或浏览器自带的 DoH 设置绕开了 Clash。也可以把日志级别调到 debug,直接观察每个域名实际走了哪个上游。完整的验证步骤与两种 DNS 模式的取舍分析,见博客文章《Clash DNS 配置与防泄漏设置实操指南》。

04TUN 模式与 Fake-IP

两种接管方式的差异

系统代理的本质,是向操作系统声明一个 HTTP/SOCKS 端口,声明之后是否使用完全取决于应用自己:浏览器和多数图形应用会遵循,而大量命令行工具、部分游戏客户端与系统服务根本不读取这个设置,它们的流量会原样直连。TUN 模式走的是另一条路:内核创建一块虚拟网卡,把系统默认路由指向它,所有应用的流量在网络层就被截获,不依赖任何应用配合。一句话概括:系统代理是"邀请制",TUN 是"全量接管"。两种方式的完整原理对比见《Clash TUN 模式与系统代理的工作原理对比》。

tun 段字段说明

stack 选择协议栈实现:system 复用操作系统协议栈,性能最好;gvisor 是用户态协议栈,兼容性更好、对系统侵入更小;mixed 混合两者,TCP 走 system、UDP 走 gvisor,是多数场景的合理默认。auto-route 自动写入路由表,把默认流量导向虚拟网卡;auto-detect-interface 自动识别真实的物理出口网卡——这项非常关键,它保证代理节点自身的流量从物理网卡发出而不是再次进入虚拟网卡,缺失或识别错误会造成流量回环、表现为开启 TUN 后立即断网。strict-route 收紧路由规则,防止部分流量绕开虚拟网卡。dns-hijack 劫持发往任意地址 53 端口的查询并转交内建 DNS,常写 any:53,确保系统与应用的 DNS 查询全部纳入第三章的解析体系。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

Fake-IP 原理与 fake-ip-filter

fake-ip 模式下,内建 DNS 收到查询时并不做真实解析,而是从 fake-ip-range(默认 198.18.0.1/16 保留段)中分配一个虚假 IP 返回给应用,并在内部记录"虚假 IP ↔ 域名"的映射。应用拿着虚假 IP 发起连接,连接到达内核时反查映射立即得到原始域名,直接按域名匹配规则——省去了一次真实解析的往返,建立连接更快,域名规则的命中也更可靠。真实解析只在确定要直连、或由代理服务器远端完成时才发生。

副作用在于:少数场景依赖拿到真实 IP 才能工作。局域网设备发现、NTP 时间同步、某些游戏登录器、Windows 的网络连通性探测,拿到 198.18 段的虚假地址会直接异常。fake-ip-filter 就是为此准备的白名单:列在其中的域名回退为真实解析,不参与 fake-ip 映射。

dns:
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - time.windows.com
    - "+.ntp.org"
    - "+.msftconnecttest.com"

各平台的权限差异

05域名嗅探

为什么需要嗅探

有两类流量到达内核时是拿不到域名的:一类是应用自行完成 DNS 解析后直接对 IP 发起连接(部分浏览器开了自带 DoH、不少移动端 App 内置解析逻辑,都属于这种);另一类是 redir-host 链路上域名信息在中途丢失的转发场景。没有域名,所有基于域名的规则全部落空,这些连接只能靠 IP 规则或 MATCH 兜底,分流精度明显下降。域名嗅探(sniffer)从流量本身把域名"读"回来:TLS 握手中的 SNI 字段、HTTP 请求的 Host 头、QUIC 握手信息里都携带目标域名,内核在转发前解析这些协议头,还原出域名再参与规则匹配。

配置字段

sniffer.enable 打开嗅探;sniff 下按协议逐个配置:ports 限定嗅探的目标端口(TLS 常见 443,HTTP 常见 80,支持端口区间写法),override-destination 为 true 时用嗅探到的域名覆盖连接目标参与规则匹配。force-domain 列出强制嗅探的域名,即使连接已带域名也重新嗅探确认;skip-domain 列出跳过嗅探的域名——最常见的用途是排除移动推送服务的长连接,嗅探介入可能干扰这类连接的保活,导致推送延迟。

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080-8880]
      override-destination: true
    QUIC:
      ports: [443]
  skip-domain:
    - "+.push.apple.com"

与两种 DNS 模式的配合

fake-ip 模式下,绝大多数域名已经通过映射反查拿到,嗅探是补充手段,专门覆盖"应用直连 IP"的漏网流量;redir-host 模式下域名丢失的概率高得多,嗅探几乎是必配项,否则规则命中率会大幅下滑。嗅探对每条新连接引入一次协议头解析的开销,量级很小,常规设备感知不到;若确有极端性能需求,可以收窄 ports 范围只嗅探标准端口。判断嗅探是否生效,同样借助第七章的面板连接页:连接目标显示为域名而非纯 IP,即说明嗅探完成了还原。

06本地覆写与多订阅合并

为什么需要覆写

订阅更新的本质是用远端最新配置整体替换本地文件——你在配置里手动加的规则、调好的 DNS、开好的 TUN,下一次更新全部被冲掉。覆写机制把"个人定制"与"订阅内容"分离开:订阅只负责提供节点,规则、DNS、TUN 这些本地策略写在覆写层,更新订阅时覆写自动重新套用,两边互不影响。下载页收录的主流图形客户端(首推的 Clash Plus,以及 Clash Verge Rev 等)都提供图形化的覆写入口,通常分为 Merge 与 Script 两种形式。

Merge 覆写:声明式合并

Merge 覆写是一段 YAML,按固定语义合并进订阅配置:字典类字段(如 dns、tun、sniffer)整段覆盖订阅中的同名字段;列表类字段通过 prepend- 与 append- 前缀控制插入位置——prepend-rules 把规则插到规则列表最前(优先级最高),append-rules 追加到最后。个人自用的直连例外、公司内网域名,放 prepend;自己的兜底策略放 append。这种方式声明式、直观,覆盖"加几条规则、改一段 DNS"的绝大多数需求。

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,ssh,DIRECT
append-rules:
  - MATCH,节点选择
dns:
  enable: true
  enhanced-mode: fake-ip
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

Script 覆写:程序化修改

Merge 处理不了"按条件批量改"的需求,这时用 Script 覆写:客户端把解析后的配置对象传给一个 JavaScript 函数,函数返回修改后的对象。典型场景:按节点名正则自动生成地区分组,订阅加了新地区节点也能自动归类;给所有 url-test 组统一补上 interval 与 tolerance;批量删除订阅里夹带的到期提醒类"假节点"。脚本里可以使用完整的 JS 语法,但要保证函数最终 return config,并且不破坏字段结构,否则内核加载会失败。

function main(config) {
  config["proxy-groups"]
    .filter((g) => g.type === "url-test")
    .forEach((g) => {
      g.interval = 300;
      g.tolerance = 60;
    });
  return config;
}

proxy-providers:多订阅合并

手里有多家订阅时,不必在客户端里来回切换配置。proxy-providers 与第二章的规则提供器同理:把每家订阅声明为一个节点提供器,策略组通过 use 字段引用一个或多个提供器,filter 用正则从合并后的节点池里筛选(比如只留名字含"香港"的节点)。这样一份配置调度多家订阅,任何一家故障都不影响整体;health-check 子字段让提供器自行做周期健康检查,失效节点会被自动跳过。

proxy-providers:
  provider-a:
    type: http
    url: https://example.com/sub-a
    path: ./providers/a.yaml
    interval: 43200
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 香港自动
    type: url-test
    use: [provider-a, provider-b]
    filter: "(?i)hk|hong ?kong|香港"

07外部控制接口与面板

开启外部控制

Clash 内核内置一套 RESTful 控制接口,几乎所有图形客户端的界面、所有网页控制面板,底层调用的都是它。external-controller 指定监听地址,只在本机使用时写 127.0.0.1:9090;secret 设置访问口令,所有请求需在 Authorization: Bearer 头里携带;external-ui 指向一个静态面板目录,内核会直接托管,浏览器访问监听地址即可打开。

external-controller: 127.0.0.1:9090
secret: "换成足够长的随机口令"
external-ui: ./ui

常用 API 一览

curl -H "Authorization: Bearer <secret>" \
  http://127.0.0.1:9090/proxies

curl -X PUT -H "Authorization: Bearer <secret>" \
  -d '{"name":"香港自动"}' \
  "http://127.0.0.1:9090/proxies/节点选择"

面板的日常用法

网页面板最有价值的是连接页与日志页。排查"某个网站为什么走错了出口",在连接页找到对应连接,查看它的规则列与代理链路列,命中了哪条规则、经过哪个组、最终从哪个节点出去,一目了然——比对着配置文件猜测高效得多。日志页把级别调到 debug,可以看到每个域名的 DNS 解析路径与规则匹配过程,是第三章 DNS 问题的直接观测手段。

另外要知道一个行为细节:通过面板或客户端切换代理模式(规则/全局/直连)后,已经建立的旧连接不会自动断开,仍按建立时的路径传输;如果切换后感觉"没生效",到连接页断开全部连接,或重启相关应用即可。三种模式的流量走向差异,见《Clash 规则模式与全局模式的区别及切换场景》。

08配置校验与问题速查

启动前校验

改完配置先校验再重载,能省下大量反复试错的时间。命令行内核提供语法与语义检查:mihomo -t -f config.yaml,通过则输出成功提示,不通过会给出出错的行号与原因。YAML 的几个高频坑:缩进必须用空格,混入制表符会解析失败;冒号后面必须有一个空格;节点名或组名包含 :、#、emoji 等特殊字符时要用引号包起来;列表项的 - 与内容之间也要有空格。图形客户端在保存配置时通常会自动做一次等效校验,报错信息同样值得逐字阅读。

mihomo -t -f config.yaml

常见问题对照

下一步

本页覆盖的是配置层面的系统知识。更口语化的高频问答整理在 FAQ,按基础认知、安装配置、使用技巧、故障排查四类组织;文中出现的代理协议、内核、规则类术语,可在术语表逐条查阅;针对单一主题的深度长文持续发布在博客。从零开始的完整操作路线,回到使用教程按步骤执行即可。