Advanced Manual

Clash 进阶配置手册

面向已完成基础安装的用户,按七大主题整理策略组、规则分流、DNS、TUN 与 Fake-IP、域名嗅探、覆写合并与控制面板的字段含义、参数取舍与可复用配置示例。

本页与安装教程是两条互补的路径:教程页解决「从下载到连通」的主线操作,适合第一次接触 Clash 的用户按步骤完成;本页则是系统化的查阅手册,当你需要改写某个字段、排查某类分流异常,或者想理解一段配置背后的机制时,按目录跳到对应章节即可。文中所有示例基于当前主流客户端普遍采用的 mihomo 内核语法,下载页列出的 Clash Plus、Clash Verge Rev、FlClash 等客户端均可直接使用;个别字段在旧版原版内核中不存在,涉及处会单独标注。术语拿不准时,可随时对照概念速查。

配置文件骨架与阅读约定

Clash 的全部行为都由一份 YAML 配置文件驱动。客户端界面上的每一个开关——代理模式、局域网共享、TUN、面板端口——最终都会落到这份文件的某个字段上。理解顶层字段的分工,是读懂后续所有章节的前提:入站部分决定流量从哪里进来(端口、TUN 网卡),出站部分决定流量从哪里出去(节点、策略组),规则部分决定「哪些流量走哪个出口」,DNS 与嗅探部分则决定内核如何认出一条连接的真实目标。

顶层字段总览

字段作用域一句话说明
mixed-port入站HTTP 与 SOCKS5 合一的混合监听端口,系统代理指向它
allow-lan入站是否允许局域网内其他设备连入本机端口
tun入站虚拟网卡配置,接管系统代理覆盖不到的流量
mode调度rule / global / direct 三种运行模式
proxies出站节点定义列表,通常由订阅提供
proxy-groups出站策略组,把节点组织成可选择、可测速的集合
proxy-providers出站节点提供者,把多份订阅按 URL 外置化管理
rules调度分流规则,自上而下匹配,决定流量出口
rule-providers调度规则提供者,把大体量规则外置为可更新的规则集
dns解析内置 DNS 模块,含 Fake-IP、分流解析与防泄漏配置
sniffer解析域名嗅探,从流量中还原真实域名
external-controller管理RESTful API 监听地址,外部控制面板依赖它
log-level管理日志级别,排障时临时调为 debug

阅读约定

后续所有 YAML 示例遵循三条约定:缩进一律两个空格,不使用 Tab;布尔值一律小写 true / false;示例片段都可以直接粘贴到客户端的覆写区(见覆写章节)验证效果,不必修改订阅原文。字段名的完整清单与逐条释义收录在概念速查的配置文件字段分类,本页只展开进阶使用中真正需要动手改的部分。

关于内核差异

原版 Clash 内核仓库已归档,本页涉及的 sniffer、nameserver-policy 部分语法、format: mrs 等能力仅 mihomo 内核支持。两代内核的完整差异对照可读博客文章《mihomo 内核与原版 Clash 核心差异全览》。

策略组类型与实战

策略组(proxy-groups)是节点与规则之间的调度层。规则不直接指向某个具体节点,而是指向一个策略组;组内再决定当前实际使用哪个节点。这一层间接性带来两个好处:订阅节点增删改名时规则不需要跟着改,以及可以按「自动测速」「故障转移」「手动指定」等不同策略管理不同用途的流量。

四种常用类型

类型选择逻辑典型用途
select完全由用户手动选择,不自动切换顶层总开关组、需要固定出口的业务组
url-test周期性测延迟,自动选用最快节点日常浏览等对速度敏感的通用流量
fallback按列表顺序检测可用性,首个存活者生效主备结构:平时走主力节点,故障时自动落到备用
load-balance按哈希或轮询把连接分散到多个节点大量并发下载、避免单节点触发限速

此外还有 relay(链式中转)类型,mihomo 已不再推荐,链式需求建议改用节点级的 dialer-proxy 字段实现,行为更可控。理解这四种类型的差异,关键是想清楚「切换的决策权交给谁」:select 把决策权完全交给人,内核只忠实执行你手选的结果,适合放在最顶层做总开关,因为你永远知道当前流量的确切出口;url-test 与 fallback 把决策权交给延迟探测,区别在于前者追求「最快」、后者追求「可用」,前者会为了几十毫秒的优势频繁切换,后者只在当前节点彻底失联时才动;load-balance 则把决策权交给哈希算法,它不关心哪个节点更快,只关心把并发连接尽量摊开。选型时一句话概括:要稳定可预期用 select,要日常最快用 url-test,要容灾兜底用 fallback,要压榨多节点带宽用 load-balance。很多用户把所有组都设成 url-test,结果观看流媒体时因为节点被自动切走而反复卡顿——流媒体这类需要会话保持的场景,恰恰应该用 select 固定一个出口。

关键参数取舍

自动型策略组的行为由四个参数决定。url 是健康检查的目标地址,应选一个轻量且稳定的探测端点,常用 https://www.gstatic.com/generate_204;interval 是检查周期(秒),设得太短会频繁发起探测浪费流量,设得太长又会让故障切换迟钝,日常 300 秒是均衡值;tolerance 只对 url-test 生效,表示新旧节点延迟差超过该毫秒数才切换,设为 50~100 可以避免两个延迟接近的节点来回抖动;lazy 设为 true 时,未被使用的组不发起健康检查,能显著减少后台探测量。

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

  - name: 自动测速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 60
    lazy: true
    proxies:
      - 香港节点
      - 日本节点

  - name: 香港节点
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    include-all: true
    filter: "(?i)hk|hong|港"

嵌套分组实战

规模化管理的常见做法是两层结构:底层按地区建自动组(香港、日本、新加坡各一个 url-test 组,用 filter 正则从全部节点中筛选),上层按用途建手动组(流媒体、开发工具、总出口各一个 select 组,候选项是地区组而不是零散节点)。这样订阅换节点时地区组自动重新收纳,用户日常只在上层组之间切换,面板列表也不会被上百个节点名淹没。include-all: true 配合 filter 是 mihomo 提供的筛选语法,正则不区分大小写建议加 (?i) 前缀。写完分组后,记得让 rules 里的出口名与组名逐字一致,YAML 中组名含空格或特殊字符时用引号包裹更稳妥。

规则分流基础与匹配顺序

规则(rules)是 Clash 的核心调度表,只有 mode: rule 时才会生效。每条规则由「类型,匹配值,出口」三段组成,内核对每一条新连接自上而下逐条比对,命中第一条即停止,后面的规则不再参与。这个「首条命中」原则意味着规则顺序本身就是优先级:同一个域名如果同时能被第 10 条和第 200 条匹配,生效的永远是第 10 条。排查「某网站为什么走错出口」时,第一步永远是在日志或面板的连接页里看它命中了哪一条。

常用规则类型

  • DOMAIN:完整域名精确匹配,仅命中一模一样的主机名。
  • DOMAIN-SUFFIX:后缀匹配,example.com 同时命中自身与全部子域,是最常用的类型。
  • DOMAIN-KEYWORD:关键字匹配,域名中任意位置包含即命中,误伤面大,慎用。
  • IP-CIDR / IP-CIDR6:按目标 IP 网段匹配,常用于内网直连与特定服务的 IP 段。
  • GEOIP:按 IP 地理数据库匹配,GEOIP,CN,DIRECT 是国内 IP 直连的标准写法。
  • GEOSITE:按内置域名分类库匹配(mihomo 特性),一条规则覆盖一整类站点。
  • PROCESS-NAME:按发起连接的进程名匹配,适合让某个应用整体直连或整体走代理,桌面端与 TUN 模式下可用。
  • RULE-SET:引用一个外置规则集,见下一章。
  • MATCH:兜底规则,匹配一切剩余流量,必须且只能放在最后一条。

no-resolve 与排序建议

IP 类规则(IP-CIDR、GEOIP)有一个隐蔽的副作用:当连接目标是域名时,内核必须先把域名解析成 IP 才能比对,这次解析可能走本地 DNS,既拖慢匹配又可能造成不必要的解析请求。在 IP 规则末尾追加 no-resolve 参数,可以让该条规则跳过纯域名连接、只比对本身就是 IP 的目标。实践中的排序建议是:进程规则与精确域名规则放最前,域名后缀与规则集居中,GEOIP,CN 这类 IP 规则放在所有域名规则之后,MATCH 收尾。这样绝大多数连接在域名阶段就完成分流,不触发解析。

rules:
  - PROCESS-NAME,Telegram,节点选择
  - DOMAIN,dl.google.com,节点选择
  - DOMAIN-SUFFIX,openai.com,节点选择
  - RULE-SET,ads-block,REJECT
  - RULE-SET,cn-sites,DIRECT
  - GEOSITE,category-games,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择
注意

MATCH 之后的任何规则都是死代码;缺少 MATCH 则未命中流量的去向取决于内核默认行为,排障时容易困惑。写完规则务必确认最后一条是 MATCH,且出口指向一个真实存在的策略组。自定义规则的更多组织思路可参考教程页的模式选择一节。

规则集订阅化管理

把几千条域名规则直接写进主配置,会带来两个长期成本:配置文件臃肿难读,以及规则库更新时必须整体替换配置。rule-providers(规则提供者)把规则外置成独立文件,内核按周期自动下载更新,主配置里只留一条 RULE-SET 引用——规则内容的维护从此与主配置解耦,这是社区维护的大型分流规则库的标准接入方式。

字段结构

rule-providers:
  cn-sites:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/cn-domains.yaml"
    path: ./rules/cn-sites.yaml
    interval: 86400
  ads-block:
    type: http
    behavior: domain
    format: mrs
    url: "https://example.com/rules/reject.mrs"
    path: ./rules/ads-block.mrs
    interval: 86400

type 取 http 表示远程下载(另有 file 引用本地文件);path 是本地缓存路径,下载失败时内核继续使用缓存,不会因为一次网络波动丢掉整套规则;interval 是自动更新周期(秒),规则库通常一天更新一次,86400 足够。format 支持 yaml、text 与 mihomo 特有的二进制格式 mrs,后者体积小、加载快,大型规则集优先选它。

behavior 三种取值

取值文件内容匹配语义
domain纯域名列表,+.example.com 表示含子域整个集合按域名后缀匹配,性能最好
ipcidr纯 IP 网段列表整个集合按 CIDR 匹配,引用时可加 no-resolve
classical完整规则行,类型混排等价于把规则逐条内联,灵活但开销最大

behavior 必须与文件实际内容一致,写错会导致规则集加载后全部不命中——这是规则集不生效最常见的原因,其次是 RULE-SET 引用名与 provider 键名不一致。另外注意:规则集本身的下载请求也是一条流量,如果规则库源站需要代理才能访问,可在 provider 里加 proxy: 节点选择 指定下载出口,避免初次启动时因为「规则没下载到所以没规则可用」的死锁。

DNS 配置优化与防泄漏

DNS 是进阶配置里投入产出比最高、也最容易被忽视的一块。默认情况下,操作系统的 DNS 查询并不经过代理:即使流量本身已经加密转发,域名解析请求仍可能以明文发往本地运营商的 DNS 服务器——这就是「Clash DNS 泄漏」的由来,解析记录会完整暴露访问了哪些站点。启用内核的 dns 模块并正确分层配置,才能把解析行为也纳入管控。

解析器的三个层次

mihomo 的 DNS 配置分三层。default-nameserver 只做一件事:解析后续 DoH/DoT 服务器自身的域名,因此必须填纯 IP 地址;nameserver 是主解析组,承担绝大多数查询,建议填写支持加密传输的 DoH 地址;fallback 是可选的备用组,配合 fallback-filter 使用——当主组返回的结果命中过滤条件(例如解析结果落在 GEOIP CN 之外)时,改用备用组的结果。这套机制的目的,是让境内域名由响应快的国内解析器处理、境外域名由不受污染的加密解析器处理,兼顾速度与准确性。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/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 精细分流

如果 fallback 的「按结果二选一」还不够精细,nameserver-policy 允许按查询的域名直接指定解析器:键可以是域名后缀、geosite: 分类甚至 rule-set: 引用,值是解析器列表。典型用法是让 geosite:cn 走国内 DoH、其余走境外 DoH,从查询入口就完成分道,而不是等拿到结果再补救。

dns:
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
    "+.internal.corp":
      - 10.0.0.53

初次配置 DNS 模块时,有几个反直觉的坑值得提前知道。其一是 enhanced-mode: fake-ip 下 fallback-filter 的意义会弱化:因为返回给应用的本就是假 IP,真正的解析发生在连接建立、内核反查域名之后,此时分流已经由域名规则接管,fallback 的「按结果国别二选一」更多服务于那些绕过 Fake-IP 直接用真实 IP 的连接。其二是 respect-rules 字段:开启后,DNS 查询本身也会按 rules 走分流,让境外解析器的查询走代理出口,进一步降低解析被污染或被观测的概率,但代价是解析链路变长,首次建连略慢,是否开启取决于你对隐私与速度的权衡。其三是不要在 nameserver 里混填国内外解析器却不做任何策略——那样每次查询会向所有解析器并发请求、采信最先返回者,境内域名很可能被境外解析器抢答到一个次优 IP,反而拖慢访问。正确姿势始终是用 nameserver-policy 或 fallback 机制把境内外解析明确分开。最后,ipv6: false 在多数纯 IPv4 代理环境下是省心的默认值,若你的网络与节点都完整支持 IPv6,再开启并同步补齐 IPv6 的规则与 DNS,否则容易出现「AAAA 记录解析成功但连接超时」的间歇性故障。

泄漏自查

配置完成后应实际验证:在浏览器访问任一 DNS 泄漏检测站,观察列出的解析服务器是否还包含本地运营商地址。若使用系统代理模式,注意浏览器自身的安全 DNS(DoH)设置可能绕开 Clash 直连解析器,测试时先关闭浏览器内置 DoH 再判断。TUN 模式下配合 dns-hijack 可以强制劫持全部明文解析,见下一章。

TUN 模式与 Fake-IP 机制

系统代理的本质是「告知」:操作系统把代理地址写进环境配置,遵守约定的应用(浏览器、多数桌面软件)主动把流量交给 Clash。但命令行工具、部分游戏客户端以及几乎所有 UDP 流量并不理会这份约定,它们的连接会直接绕过代理。TUN 模式换了一种思路——在系统里创建一块虚拟网卡并接管默认路由,所有流量在网络层就被截获,应用无从绕过。两种机制的完整对比与场景选择,可读博客文章《Clash TUN 模式和系统代理有什么区别》。

tun 字段配置

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

stack 决定 TUN 数据包的处理协议栈:system 直接复用操作系统网络栈,性能好但对系统环境敏感;gvisor 是用户态实现,兼容性最稳;mixed 取两者之长(TCP 走 system、UDP 走 gvisor),是当前多数场景的推荐值。auto-route 自动写入路由表让流量导向虚拟网卡,auto-detect-interface 自动识别物理出口网卡防止回环;这两项一般保持开启,除非你在路由器等复杂网络拓扑下需要手动控制路由。dns-hijack 把发往任意地址 53 端口的明文 DNS 查询强制劫持给内核解析,是 TUN 模式下堵死 DNS 泄漏的关键一环。桌面端启用 TUN 需要管理员权限或已安装的系统服务,Clash Plus 与 Clash Verge Rev 首次开启时都会引导授权。

Fake-IP:为什么解析结果是 198.18 开头

enhanced-mode: fake-ip 是与 TUN 配合最好的解析模式。它的机制是:应用发起域名查询时,内核不做真实解析,而是立刻从保留网段 198.18.0.0/16 里分配一个「假 IP」返回,并记住这个 IP 与域名的映射;当应用拿着假 IP 发起连接时,内核反查映射还原出域名,再按域名规则分流。好处有二:省掉一次真实解析的等待,建连更快;域名信息保留到了规则匹配阶段,分流精度不受解析影响。代价是个别依赖真实 IP 的程序会异常——局域网发现、NTP 时间同步、部分游戏登录器等,这类域名应加入 fake-ip-filter 白名单,让它们走真实解析:

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - "+.stun.*.*"

如果你的使用场景以浏览器为主、且经常需要把解析结果交给第三方程序使用,也可以退回 enhanced-mode: redir-host(真实 IP 模式),代价是每次连接都要等待真实解析完成。两种模式可随时切换,切换后建议清空一次 DNS 缓存再观察。

域名嗅探:把 IP 还原成域名

规则分流的理想输入是域名,但有两类流量到达内核时只剩下 IP:一是应用自带 DNS(比如浏览器内置 DoH)绕开了内核解析,连接目标直接是真实 IP;二是 Fake-IP 白名单之外仍有程序缓存了历史解析结果。目标只剩 IP 时,所有域名规则全部失效,流量只能落到 GEOIP 或 MATCH 兜底——分流精度大打折扣。域名嗅探(sniffer)就是补救手段:内核检查连接头部的明文特征(HTTP 请求的 Host 头、TLS 握手的 SNI 字段、QUIC 初始包),把真实域名「嗅」出来,再用它重新走一遍规则匹配。

配置示例

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

三个协议块分别声明在哪些端口上尝试嗅探;override-destination 为 true 时,用嗅探到的域名覆盖连接的目标地址,使后续规则与日志都以域名呈现。force-domain 列出的域名即使已经有解析结果也强制用嗅探值覆盖,适合处理 CDN 域名与解析结果对不上的站点;skip-domain 则相反,列出的目标跳过嗅探——苹果推送、部分厂商的长连接对连接头部被检查很敏感,列入跳过名单可避免莫名断连。嗅探只读取协议握手阶段本就明文的字段,不解密任何加密载荷;它的开销集中在每条新连接的首个数据包,日常使用几乎无感。TUN + Fake-IP + 嗅探三件套同时启用,是当前分流精度最高的组合。

本地覆写与多订阅合并

订阅文件由服务端生成,每次更新都会整体覆盖本地内容——直接在订阅文件里手改 DNS、加规则,下次更新就全部丢失。正确的做法是把个人定制放进「覆写」层:客户端在每次加载订阅后,自动把你的覆写内容合并进最终配置,订阅归订阅、定制归定制,互不干扰。这是长期使用 Clash 最值得建立的习惯。

各客户端的覆写能力

下载页首推的 Clash Plus 内置覆写编辑器,支持以 YAML 片段的形式追加或替换字段,适合本页所有示例的落地;Clash Verge Rev 提供 Merge(声明式合并)与 Script(JavaScript 编程式修改)两种全局扩展,Merge 里 dns、tun 等键直接整块替换订阅同名字段,前缀写法可实现列表追加,复杂逻辑再用 Script;FlClash 也支持配置覆写,移动端上同样能保住自定义规则。从停更客户端迁移覆写配置的完整路径,见博客《Clash for Windows 停止更新后用什么》。一段典型的 Merge 覆写如下:

dns:
  enable: true
  enhanced-mode: fake-ip
prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
append-rules:
  - GEOIP,CN,DIRECT

proxy-providers 合并多份订阅

手上有多家机场订阅时,不必在客户端里来回切换配置。proxy-providers 允许把每份订阅声明为一个节点提供者,再在策略组里用 use 引用,多份订阅的节点汇入同一套分组体系统一测速、统一分流:

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/sub-a?token=xxxx"
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
  provider-b:
    type: http
    url: "https://example.net/sub-b?token=xxxx"
    path: ./providers/b.yaml
    interval: 3600

proxy-groups:
  - name: 全部节点
    type: url-test
    use:
      - provider-a
      - provider-b
    url: https://www.gstatic.com/generate_204
    interval: 300

provider 级的 health-check 让节点在被任何组使用前就有健康状态;filter、exclude-filter 字段可以在 provider 层先过滤掉到期提示、流量播报这类非节点条目。注意两家订阅出现同名节点会导致加载冲突,可用 override.additional-prefix 给每个 provider 的节点统一加前缀区分来源。多设备共享这套合并配置的局域网玩法,另见博客《Clash 混合端口与允许局域网连接设置》。

外部控制面板接入

内核在运行时暴露一套 RESTful API,策略组切换、延迟测试、连接查看、配置重载都可以通过它完成——桌面客户端的图形界面本质上就是这套 API 的封装。当 Clash 跑在路由器、NAS 或无头服务器上时(部署思路见博客《路由器直跑 Clash 内核方案概览》),外部控制面板就是唯一顺手的管理入口。

开启 API 与面板

external-controller: 127.0.0.1:9090
secret: "your-strong-secret"
external-ui: ./ui
external-ui-url: "https://example.com/dashboard/dist.zip"

external-controller 指定 API 监听地址,仅本机管理保持 127.0.0.1,需要局域网内其他设备访问才改 0.0.0.0;secret 是 API 访问令牌,面板连接时以 Authorization: Bearer 头携带。external-ui 指向本地静态面板目录,配合 external-ui-url 可以让内核自动下载面板发行包,之后浏览器访问 http://127.0.0.1:9090/ui 即可打开。社区常用面板有 metacubexd、zashboard 与 yacd 系列,均为纯静态页面,选一个顺眼的即可;桌面用户通常不需要单独部署,Clash Plus 与 Clash Verge Rev 已内嵌面板视图。

直接调用 API

# 查看内核版本
curl -H "Authorization: Bearer your-strong-secret" \
  http://127.0.0.1:9090/version

# 把「节点选择」组切换到「香港节点」
curl -X PUT -H "Authorization: Bearer your-strong-secret" \
  -d '{"name":"香港节点"}' \
  http://127.0.0.1:9090/proxies/节点选择

# 触发指定组延迟测试
curl -H "Authorization: Bearer your-strong-secret" \
  "http://127.0.0.1:9090/group/自动测速/delay?url=https://www.gstatic.com/generate_204&timeout=3000"
安全边界

API 拥有对内核的完全控制权。把 external-controller 暴露到 0.0.0.0 而不设 secret,等于把代理调度权交给局域网内任何设备;若设备本身有公网地址,风险进一步放大。原则:能 127.0.0.1 就不监听全网,监听全网就必须配强口令,并确认防火墙没有把 9090 端口放到公网。

至此,七大主题的进阶配置已经覆盖完毕。建议的实践路径是:先在教程页确认基础链路连通,再从 DNS 与策略组两章入手逐块套用示例,每改一块就用面板的连接视图验证效果;字段含义随时查概念速查,客户端选择与获取见下载页,站点定位与维护原则见项目介绍。