ADVANCED CONFIG · 配置进阶

Clash 进阶配置手册

策略组、规则集、DNS、TUN、嗅探、覆写与外部控制——订阅之外的全部配置空间,七章讲透,逐章附可照抄的 YAML 示例。

七章 · 按需跳转 · 示例基于 mihomo 内核字段

本页是查阅手册,与使用教程分工不同:教程解决从零到能用——导入订阅、选择模式、验证代理;本页解决能用之后如何用好——策略组怎么搭、规则集怎么订阅化、DNS 怎么不拖后腿、TUN 何时开、嗅探补什么、多订阅怎么合、外部面板怎么安全地开。七章各自独立,按上面目录跳转即可,不必通读。

示例基于 mihomo(Clash Meta)内核的 YAML 字段,Clash Plus、Clash Verge Rev、FlClash 等主流客户端均按此内核解析;个别字段在已归档的旧 Clash 内核下不存在,文中另行注明。还没装客户端的,先到下载中心按平台领取;客户端之间的差异与选型见客户端对比

策略组类型与实战

策略组是 Clash 配置的中枢。所有流量最终都要回答一个问题:从哪个出口走。rules 负责把流量分进策略组,策略组负责在出口之间做选择。订阅自带的策略组往往只有「节点选择」和「自动选择」两档,够用但不顺手。把五种类型摸清,才能搭出「视频走香港、下载走日本、失败自动切备线」这种按业务分流的结构。

五种类型一张表

类型选择方式典型用途
select用户在前端手动选定主出口、分业务出口
url-test定时测速,取延迟最低者无人值守的自动出口
fallback按列表顺序取第一个可用者主力加备用的故障转移
load-balance按策略把连接摊到多个节点多线并行、摊薄单线压力
relay流量依次穿过组内全部节点前置中转加落地的链式代理

五种类型可以互相嵌套:一个策略组的 proxies 里可以写另一个策略组的名字。实战里最稳的结构是三层——业务策略组(如「流媒体」「下载」)指向出口策略组,出口策略组再指向节点或 url-test 组,rules 只引用业务组。这样换出口不动规则,换节点不动出口,维护成本最低。

select 与 url-test:手动拍板加自动择优

select 不做任何检测,前端点哪个用哪个,适合作为最终拍板层。url-test 按 interval 定时对组内节点发起延迟测试,把出口切到当前最快的一个。两个参数决定它是否好用:tolerance 是切换阈值,单位毫秒,候选节点只比当前节点快几十毫秒时不切换,避免出口在两条相近线路之间来回抖动;lazy 置 true 后,组内没有流量经过时暂停测速,省掉无意义的探测请求。

proxy-groups:
  - name: "最终出口"
    type: select
    proxies: ["自动择优", "手动指定", "DIRECT"]

  - name: "自动择优"
    type: url-test
    use: ["airport-a"]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80
    lazy: true

  - name: "手动指定"
    type: select
    include-all: true
    filter: "香港|HK"

use 引用 proxy-providers 里的订阅,include-all: true 把配置里全部节点收进来,filter 用正则再筛一层。三个字段可以叠加:先收全部,再按正则筛,再并入订阅。测速地址用 generate_204 这类返回体极小的探活地址即可;interval 不建议低于 120 秒——频繁测速本身就是可观的流量消耗,部分机场还会因此限速。

fallback 与 load-balance:主备与并行

fallback 把列表顺序当作优先级:健康检查从第一个开始,谁先用谁;主力挂了自动落到备用,主力恢复后切回。它适合「一条主力专线加一条保底线路」的场景,比 url-test 更尊重人为排序。load-balance 则相反,不追求单线最优,而是把连接摊到组内所有健康节点上。strategy 取 consistent-hashing 时,同一个目标域名固定哈希到同一节点,登录态与会话保持一致;取 round-robin 时逐连接轮转,吞吐最大但同站可能跳 IP;mihomo 另提供 sticky-sessions,让同一来源设备尽量粘在同一节点,是两者之间的折中。

  - name: "主备线路"
    type: fallback
    proxies: ["专线入口", "自动择优"]
    url: "https://www.gstatic.com/generate_204"
    interval: 180

  - name: "多线并行"
    type: load-balance
    use: ["airport-a"]
    strategy: sticky-sessions
    url: "https://www.gstatic.com/generate_204"
    interval: 300

relay:链式代理

relay 让流量依次穿过组内每一个节点再出站,典型用法是「前置中转加落地」:本地到前置走优化线路,前置到落地走普通国际出口,兼得稳定性与目标地区出口身份。链中每一跳都占用各自带宽,总延迟是各跳之和,节点不宜超过两个。mihomo 里更轻量的等价写法是在单个节点上声明 dialer-proxy,指定它经哪个前置出站,不必单独建组。

  - name: "中转落地"
    type: relay
    proxies: ["前置中转", "美国落地"]

提示

策略组改名后记得同步 rules 里的引用,名字对不上时该条规则静默落空,没有任何报错。健康检查地址全组统一即可,不必每组单独找。

规则集订阅化管理

从 rules 到 rule-providers

早期配置把成百上千条规则直接堆在 rules 字段里:难读、难改,订阅一更新整份文件被覆盖,自己加的规则跟着消失。rule-providers 把规则从配置里抽出来,变成独立的、可按 URL 订阅的规则集文件:内核启动时下载、本地缓存、按周期刷新,rules 里只留一行引用。配置从此分成两层——策略结构留在手写的 YAML 里,规则数据交给可自动更新的规则集。

拦截广告、分流流媒体、放行内网,这些成熟需求社区已有维护多年的规则集,直接订阅比自己逐条手写可靠得多。本地独有的规则(公司内网、自建服务)用 file 类型的 provider 放一份本地文件,同样走 RULE-SET 引用,管理方式统一。

声明格式与字段

rule-providers:
  adblock:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/adblock.yaml"
    path: ./ruleset/adblock.yaml
    interval: 86400

  lan-local:
    type: file
    behavior: classical
    path: ./ruleset/lan.yaml

type 取 http 时按 url 订阅,取 file 时读本地文件;path 是本地缓存位置,下载成功后规则集落盘,下次启动先读缓存;interval 是刷新周期,单位秒,86400 即每天一次。format 声明文件格式:yaml 是常见的列表式,text 是一行一条的纯文本,mrs 是 mihomo 专用的二进制格式,体积最小、加载最快,大型规则集优先选它。

三种 behavior 的区别

behavior内容形态匹配开销适用
domain仅域名集合极低,哈希匹配广告与追踪域名等纯域名清单
ipcidr仅 IP 段低,按前缀匹配地区 IP 段、运营商段
classical完整规则语法混合逐条求值域名、IP 段、端口混写的场景

behavior 决定内核怎么解析这份文件,写错会整集加载失败:domain 文件里出现 IP 段、ipcidr 文件里出现域名,都会报错。订阅第三方规则集时先看发布页标注的类型,再照抄 behavior 与 format,不要凭文件名猜。

在 rules 中引用与更新机制

rules:
  - RULE-SET,lan-local,DIRECT
  - RULE-SET,adblock,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,最终出口

RULE-SET 的两个参数依次是 provider 名和去向(策略组或 DIRECT、REJECT)。rules 自上而下逐条匹配,第一条命中即生效,顺序就是优先级:本地与拦截类靠前,分流类居中,GEOSITE、GEOIP 与 MATCH 兜底压阵。放错位置是规则不生效的首要原因——排在 MATCH 之后的规则永远不会被看见。

更新是后台行为:启动时检查每个 http provider 缓存的龄期,超过 interval 就异步拉取;拉取失败沿用旧缓存,规则不会清空、不会断流。想立即刷新,在面板里点对应 provider 的更新按钮,或删掉 path 指向的缓存文件后重载配置。GEOSITE 与 GEOIP 走的是另一套数据库文件,更新方法见博客《Clash GeoIP 与 GeoSite 数据库更新方法与分流规则搭配》,与 RULE-SET 不要混为一谈。

提示

同一个 provider 可以被多条 rules 引用,指向不同策略组——例如把一份流媒体域名集按地区拆给不同出口,不必重复订阅。

DNS 配置优化

代理客户端为什么要接管 DNS

系统默认 DNS 走运营商的 UDP 53 端口,明文、可篡改。两个问题直接影响代理效果:一是污染,查询被中途注入错误结果,拿到的 IP 根本连不通;二是泄露,访问过什么域名运营商一览无余,分流随之失去意义。更隐蔽的是第三个问题:DNS 结果决定规则匹配——按域名写的规则,必须先有正确的解析路径,内核才拿得到域名。

Clash 内置 DNS 服务器就是为了把解析纳入分流体系:国内域名交给国内 DoH 直连解析,代理域名由远端节点代理解析,节点服务器自身的域名用专门的解析器,避免「要先连上代理才能解析代理地址」的死循环。dns 字段一开,整条解析链路都在内核掌控之中。

字段分工

字段职责
default-nameserver启动时解析 DoH、DoT 服务器自身的域名,必须写 IP
nameserver主解析器组,支持 UDP、DoH、DoT、DoQ
proxy-server-nameserver专管节点服务器域名解析
direct-nameserver命中直连规则的域名走这里
fallback传统字段,代理域名解析组(mihomo 推荐用 nameserver-policy 替代)
nameserver-policy按域名或 geosite 指定解析器,分流的核心

一份可照抄的 dns 配置

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - "+.stun.*.*"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://doh.pub/dns-query
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

这份配置的思路:default-nameserver 用纯 IP 兜底,负责把 doh.pub、dns.alidns.com 这些解析器自己的域名先解出来;nameserver-policy 按 geosite 把域名劈成两路,国内域名走国内 DoH,非国内域名走代理侧的 DoH,由节点远端完成解析;proxy-server-nameserver 单独处理节点域名,与业务解析互不干扰。listen 让内核在 1053 端口对外提供 DNS 服务,TUN 的 dns-hijack 会把系统查询引到这里。

enhanced-mode:redir-host 与 fake-ip

redir-host 做真实解析,把查询转发给上游再返回真实 IP,兼容性最好,代价是多一次 DNS 往返,且内核看到的是 IP,域名规则要靠缓存反查。fake-ip 直接返回 198.18.0.1/16 段内的假地址,应用拿到结果立刻发起连接,内核按此前记下的「假地址与域名」映射还原出域名再匹配规则——省掉真实往返,首连更快,规则按域名精确命中。绝大多数桌面与移动场景 fake-ip 是更优解,必须拿到真实 IP 的服务写进 fake-ip-filter 排除。ipv6 在宽带未分配 IPv6 的环境建议关闭,避免 AAAA 查询拖慢整体解析。

改完 dns 字段不生效是高频疑问:重载配置只是第一步,操作系统和浏览器各自缓存了旧解析,需要清理系统 DNS 缓存或重启浏览器,新链路才真正接管。

排错

开代理后个别网站打不开、关闭就正常,八成是 DNS 分流问题:先查 nameserver-policy 把该域名分到了哪一路,再查 fake-ip-filter 是否需要补条目。

TUN 与 Fake-IP

TUN 解决什么问题

系统代理的本质是「告诉应用代理地址」,应用愿意遵循才被接管。浏览器、大部分办公软件没问题,但游戏、命令行工具、不少桌面应用直接无视系统代理设置,流量裸奔在直连上。TUN 换了一条路:在内核里建一张虚拟网卡,通过路由表把整机 TCP、UDP 流量全部引进来,应用完全无感知——不需要它支持代理,也不需要逐个设置。

代价是权限。虚拟网卡和路由表都是系统级资源:Windows 需要安装内核服务,macOS 需要一次授权,Linux 需要 capabilities 或 root。Clash Plus、Clash Verge Rev 等客户端把这一步做成了设置里的一个开关,按提示完成一次授权即可;Android 客户端本身就是 VPNService 形态,天然工作在 TUN 层;iOS 由系统网络扩展接管,无需用户操作。各平台客户端在下载中心按系统领取。

tun 字段

tun:
  enable: true
  stack: mixed
  device: Meta
  mtu: 1500
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-detect-interface: true
字段取值说明
stacksystem / gvisor / mixedTCP/IP 协议栈实现,见下文
device网卡名默认 Meta,一般不改
dns-hijack监听地址列表把 53 端口查询劫持进内置 DNS
auto-routetrue / false自动下发路由,接管整机流量
auto-detect-interfacetrue / false自动识别物理出口网卡,防流量回环
mtu数值默认 1500,个别移动网络需降到 1428 一带

stack 三选一:system 直接借助操作系统协议栈转发,性能最好;gvisor 用用户态协议栈重建连接,兼容性最广,在个别严格网络环境下更稳;mixed 让 TCP 走 system、UDP 走 gvisor,兼顾两者,是多数客户端的默认。auto-route 与 auto-detect-interface 必须同时开:前者把流量引进来,后者保证内核自己的出站从物理网卡走,少了后者会形成回环,表现为开启 TUN 后全部断网。

Fake-IP 的工作原理

Fake-IP 与 TUN 是一对搭档。应用查询域名时,内置 DNS 不做真实解析,而是从 fake-ip-range(198.18.0.1/16)里分配一个假地址返回,并记下假地址与域名的映射;应用随即向假地址发起连接,TUN 截获后按映射还原域名,按域名匹配规则,再决定直连还是交给节点——交给节点时把域名直接发过去,由远端解析,本地全程不需要真实 DNS 结果。

这套机制带来两个直接收益:首连快,省掉一次真实 DNS 往返;分流准,规则匹配拿到的一定是域名而不是 IP。代价是「看到假地址」的副作用:局域网服务、NTP 授时、STUN 打洞、部分游戏反作弊与银行控件必须拿到真实 IP,这类域名要写进 fake-ip-filter。filter 支持通配:*.lan 匹配所有 .lan 结尾,+.example.com 匹配主域与全部子域。

各平台落地要点

Windows 下客户端的服务模式会把内核注册成系统服务,TUN 开关在设置页;macOS 首次开启增强模式时输入一次密码授权;Linux 桌面客户端同样提供开关,命令行直跑 mihomo 时需要 setcap 赋权:

sudo setcap 'cap_net_admin,cap_net_bind_service=+ep' /usr/local/bin/mihomo

赋权后普通用户即可启动 TUN,不必全程 root。服务器侧的完整部署流程见博客《Linux 部署 Clash:桌面客户端安装与 mihomo 命令行配置》

提示

TUN 与系统代理二选一即可,日常用 TUN 就不必再开系统代理。开启 TUN 后确认 dns-hijack 与 enhanced-mode 配套:fake-ip 模式下劫持 53 端口,整个解析闭环才成立。

域名嗅探

规则需要域名,连接未必带域名

Clash 的规则体系以域名为主轴,但到达内核的连接不一定带着域名。应用自己做了 DNS、内置了 DoH、缓存了旧解析结果,甚至直接硬编码 IP——这些连接进入内核时只有目标 IP。没有域名,DOMAIN、DOMAIN-SUFFIX、GEOSITE 全部落空,流量只能一路跌到 GEOIP 或 MATCH,分流精度大打折扣。

域名嗅探从连接本身的握手数据里把域名读回来:TLS 连接的 ClientHello 里有 SNI 字段,明文 HTTP 请求里有 Host 头,两者都是未加密的声明。内核在转发前看一眼握手包,提取出域名,重新挂到这条连接上,后续规则匹配就按域名进行。TUN 接管整机流量之后,绕过系统 DNS 的连接全部暴露在内核面前,嗅探几乎成了 TUN 的标配搭档。

配置写法

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

parse-pure-ip 对纯 IP 连接也尝试嗅探,这是嗅探的主战场;override-destination 用嗅探到的域名替换连接的目标地址,让 redir-host 模式下的连接也能按域名分流;sniff 下按协议声明端口范围,QUIC 单列是因为它的 SNI 提取方式与 TCP 上的 TLS 不同。skip-domain 是豁免名单:已知嗅探后会异常的服务(如部分推送通道、智能家居云服务)写进来,内核对这些域名跳过嗅探。

边界情况与排错

嗅探不是万能的。启用 ECH(Encrypted Client Hello)的连接把 SNI 加密了,嗅探拿不到域名,只能回退到 IP 规则;个别环境的 QUIC 嗅探会导致视频站点加载异常,可以单独删掉 QUIC 一段验证;嗅探只在握手阶段读几个字段,不解密流量,性能开销可以忽略。

与 Fake-IP 的关系要说清:fake-ip 模式下,域名在 DNS 阶段就已经在内核手里,嗅探的用武之地只剩「应用绕过系统 DNS」的少数场景;redir-host 模式或纯 IP 直连场景,嗅探是分流精度的主要保障。开了嗅探之后某个服务连不上,先把它的域名加进 skip-domain 验证,再排查其他方向。

提示

嗅探与规则是互补不是替代。域名规则写得越完整,嗅探兜底的压力越小;反过来,依赖嗅探硬扛所有分流,遇到 ECH 就会集体失灵。

本地覆写与多订阅合并

一个绕不开的矛盾

机场订阅是整份 YAML,客户端按周期刷新,刷新即整体替换。手动加的节点、改过的策略组、调过的 DNS,下一次更新全部消失。把本地改动和订阅内容隔离开,是长期用好 Clash 的前提。手段分两层:多订阅用 proxy-providers 聚合,节点与订阅文件解耦;本地修改走客户端覆写机制,补丁与订阅文件解耦。有人用在线订阅转换服务把多订阅合成一份,代价是把订阅地址交给第三方;proxy-providers 在本地完成同样的事,地址不出本机。

proxy-providers:把多个订阅聚成节点池

proxy-providers:
  airport-a:
    type: http
    url: "https://example.com/sub-a.yaml"
    path: ./providers/airport-a.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300
    override:
      additional-prefix: "[A] "

  airport-b:
    type: http
    url: "https://example.com/sub-b.yaml"
    path: ./providers/airport-b.yaml
    interval: 86400
    override:
      additional-prefix: "[B] "

  self-hosted:
    type: file
    path: ./providers/self.yaml

每个 provider 独立下载、独立缓存、独立健康检查。override.additional-prefix 给该订阅的所有节点名前加前缀,两个机场撞名(「香港 01」家家都有)时不再互相覆盖,面板里也一眼分清归属。filter 字段用正则只收需要的节点,例如只取家宽线路。file 类型的 self-hosted 放本地手写的自建节点,与订阅平级进池。

聚合之后,策略组用 use 引用 provider,与 proxies 混排:

  - name: "自动择优"
    type: url-test
    use: ["airport-a", "airport-b", "self-hosted"]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

客户端覆写:给订阅打补丁

主流客户端都提供覆写层,原理一致:订阅 YAML 下载后先过一遍用户定义的补丁,再交给内核生效。Clash Plus 在订阅设置里提供覆写入口;Clash Verge Rev 提供 Merge(按 YAML 路径合并字段)与 Script(用脚本任意改写)两档;FlClash 在覆写配置里支持追加规则与策略组。补丁里能做的事:插入前置规则、追加策略组、改 dns、关 ipv6——订阅刷新一百次,补丁照旧生效。

覆写里最常用的是前置规则。客户端一般提供「追加到 rules 顶部」的槽位,写在最前的规则优先级最高,适合放「公司域名直连」「某站点强制走某出口」这类个人化条目。订阅自带规则保持原样,不读不改;出了问题把覆写关掉即可回到订阅原貌,排错路径非常短。基础的订阅导入与模式选择仍是前提,主线步骤见使用教程

合并冲突与维护纪律

多订阅合并的坑集中在三处。命名冲突:不同订阅的同名节点会被去重或后者覆盖前者,additional-prefix 是最稳的解法。策略组同名:覆写里追加的策略组若与订阅自带组同名,以覆写为准,订阅组被替换——有意为之是功能,无意撞名是事故。规则顺序:前置规则压过订阅规则,写一条过于宽泛的前置(如大段 IP 直连)会把订阅分流架空,前置条目务必精确。

维护上建议把本地改动收敛到一份覆写里,规则、策略组、DNS 集中管理,改动留注释。订阅更新失败时旧缓存仍在,节点不会突然消失;更新失败的排查顺序与自动更新设置见博客《Clash 订阅更新失败的常见原因与自动更新设置方法》

外部控制面板

external-controller 是什么

内核启动后会按 external-controller 的地址暴露一组 RESTful API 与 WebSocket 接口:查询代理、切换节点、读取规则、看活动连接、收实时日志,客户端图形界面本质上就是这组 API 的调用方。把它打开并配上 Web 面板,就能脱离具体客户端,用任意浏览器管理正在运行的内核——路由器上的 mihomo、服务器上的无人值守实例,都靠这条路管理。

开启方式

external-controller: 127.0.0.1:9090
external-ui: ui
secret: "your-password"

external-controller 是 API 监听地址;external-ui 指向面板静态文件目录,配好后访问 http://127.0.0.1:9090/ui 即是面板;secret 是访问令牌,面板登录与 API 请求都要带。面板文件用社区现成的发布包即可:metacubexd、zashboard、yacd 都是成熟选择,下载发布包解压到 ui 目录;也可以不部署本地文件,直接打开面板的在线页面,填入 API 地址与密钥,浏览器会直连本机 API。

常用 API 一览

端点方法作用
/proxiesGET全部代理与策略组状态
/proxies/{name}PUT切换 select 组选中项
/proxies/{name}/delayGET对指定节点测延迟
/rulesGET当前生效的规则列表
/connectionsGET / DELETE查看、清空活动连接
/configsGET / PATCH读取、热改运行配置
/traffic · /logs · /memoryGET(WebSocket)实时速率、日志、内存流
/versionGET内核版本信息

面板的所有功能都建立在这些端点上,自己写脚本也同样调用——定时测速切线、按连接数报警、把流量接进监控,都是常见玩法。命令行验证只需要一个请求头:

curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/proxies

安全边界

绑定地址先用 127.0.0.1,只允许本机访问,这是默认也是最稳的形态。确需局域网访问——比如用手机管理路由器上的内核——把绑定改成内网地址,同时必须设置 secret;没有令牌保护的 API 等于把代理控制权交给同网段任何人。任何情况下不要把 9090 端口映射到公网,也不要绑定 0.0.0.0 之后依赖防火墙自觉。

secret 用足够长的随机串,写进配置后重启内核生效;它通过请求头传递,面板会记住,日常使用无感。面板的在线版是浏览器直连你填的 API 地址,密钥不经过第三方服务器,但仍建议只在可信网络里操作,用完关闭标签页。

配套入口

客户端按平台在下载中心领取,首推 Clash Plus;上手主线见使用教程;选型差异见客户端对比;YAML 字段逐段解析见博客《Clash 配置文件详解》,首次连接的节点选择与代理验证见《Clash 首次连接指南》