Clash 进阶配置手册

开始之前:手册定位与配置基础

先说明本页与教程页的分工。订阅配置入门是主线教程:导入订阅、选择模式、发起连接、验证生效,跟着做一遍就能把客户端用起来。本页不重复那条主线,而是把进阶主题拆成九章,哪一块要调就查哪一块,适合放在收藏夹里当手册用。还没完成首次连接的,建议先去教程页走一遍,或参考博客《Clash 首次连接教程:选择节点、测试延迟与验证代理生效》,再回来按主题查阅。

本页的配置对象是 mihomo 内核(原 Clash Meta)。客户端下载页列出的在维护客户端——Clash Plus、Clash Verge Rev、FlClash、Clash Meta for Android 等——全部基于这套内核,配置语法一致。本页所有 YAML 片段都是 mihomo 配置:桌面与移动端的图形客户端一般提供配置编辑或覆写入口,裸跑内核的用户则直接编辑配置目录下的 config.yaml。

动手之前先找到"当前生效的那份配置"。Clash Verge Rev 在「订阅」页面对某个配置右键即可编辑文件或编写全局扩展;Clash Plus 在配置管理里打开当前订阅;FlClash 在配置详情里编辑覆写段;裸内核默认读取配置目录下的 config.yaml。多份订阅并存时,改错文件是"改了不生效"的第一大原因。

YAML 语法有四条纪律,后续所有示例都遵守:缩进只用空格、不用 Tab,统一两格;键名后的冒号紧跟一个空格再写值;值里含冒号、#、通配符时整体加英文引号;同级键严格对齐。第九章附常见语法错误对照表。

# config.yaml 最小骨架(mihomo)
mixed-port: 7890        # HTTP 与 SOCKS 混合端口
allow-lan: false        # 是否允许局域网设备接入
mode: rule              # rule 规则 / global 全局 / direct 直连
log-level: info
dns: {}                 # 第四章展开
proxies: []             # 节点,通常由订阅或 proxy-providers 提供
proxy-groups: []        # 第二章展开
rules: []               # 第三章展开

策略组类型与实战

策略组是分流的中枢。rules 里每条规则的末尾写的不是具体节点,而是一个策略组名;流量命中规则后交给组,组按自己的类型逻辑挑出实际出口。把"选节点"这件事从规则里剥离,是 mihomo 配置的核心思想:规则只管分类,组只管挑选。除了引用真实节点,组里还可以放两个内置策略:DIRECT 表示直连,REJECT 表示直接拒绝(常用于广告与追踪域名)。

五种类型逐个看

select:手动选择。proxies 列表的第一项是默认出口,之后在面板里手动切换。最常用,一般作为顶层出口组。

url-test:自动测速选优。对组内节点按 url 发 HTTP 请求测延迟,每 interval 秒测一轮,选延迟最低的节点;tolerance 指定毫秒级容差,新旧节点差距在容差内不切换,避免节点抖动;lazy 设为 true 时,组内没有流量就不测速,省请求也省电。

fallback:故障转移。按 proxies 顺序取第一个健康检查通过的节点。适合主备场景——主力节点故障时自动落到备用,主力恢复后切回。

load-balance:负载均衡。strategy 取 consistent-hashing 时,同一目标域名固定哈希到同一节点,站点登录态不因出口 IP 跳变而掉线;取 round-robin 则逐请求轮换,适合多线程下载类场景。

relay:链式代理。proxies 按顺序串联,流量先经前置节点再到落地节点。可用于"先过入口再落地"的特殊链路,但每多一跳就多一倍延迟与故障面,日常分流用不上。

组的嵌套与 use 引用

proxies 里既可以写节点名,也可以写另一个组名——「节点选择」里放「自动选择」和各地区组,用户在一处切换即可。组还可以用 use 字段引用 proxy-providers 拉来的整个订阅节点集合(见第七章),订阅更新后组内节点自动跟着变,不需要手改组列表。

一套实战组合

proxy-groups:
  - name: "节点选择"
    type: select
    proxies: ["自动选择", "香港", "日本", "美国", "DIRECT"]

  - name: "自动选择"
    type: url-test
    use: ["airport-a"]        # 引用第七章的订阅集合
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80
    lazy: true

  - name: "流媒体"
    type: select
    proxies: ["香港", "日本", "节点选择"]

  - name: "下载"
    type: load-balance
    use: ["airport-a"]
    strategy: consistent-hashing
    url: "http://www.gstatic.com/generate_204"
    interval: 600

测速地址怎么选

url-test 与 fallback 的判断完全建立在测速地址的响应上,这个地址选得不合适,整套自动选优就会失真。标准做法是选返回 204 空响应的探测端点:http://www.gstatic.com/generate_204 与 http://cp.cloudflare.com/generate_204 都是专为连通性检测设计的,响应体为空、几乎不产生流量、全球都有接入点,组内几十个节点一轮测下来负担也很小。

选地址时注意两点。第一,测速请求是从被测节点发出去的,拿国内站点当测速地址,量出来的是节点回国内的链路质量,和它访问境外服务的能力没有关系,自动选优会因此挑错节点。第二,204 端点量出的是一次握手往返的延迟,不等于实际业务体验——延迟低但带宽小的节点并不少见,看视频、下大文件照样卡。对带宽敏感的场景,与其迷信延迟数字,不如单独建一个 load-balance 组把请求分摊出去;延迟数字真正可靠的用途,是识别"彻底不通"和"明显劣化"的节点。

规则集订阅化管理

规则决定"什么流量走什么出口"。把几十上百条规则写死在 config.yaml 里有两个麻烦:规则会过时,域名清单天天在变;订阅更新会整份覆盖手改内容。规则集(rule-providers)把规则拆成独立的远程文件,内核按 interval 定时拉新,主配置里只留一行引用。

字段逐项说明

type:http 表示从 URL 拉取,local 表示读本地文件。behavior:规则集内容形态——domain 是纯域名后缀列表,ipcidr 是纯 IP 段列表,classical 是经典规则(文件里每行是 DOMAIN-SUFFIX,example.com 这类带类型前缀的完整规则)。format:文件格式,支持 yaml、text 与 mrs(mrs 是二进制格式,体积最小,超大列表优先用它)。url / path:远程地址与本地缓存路径,拉取失败时用 path 处的缓存兜底。interval:更新间隔,单位秒。

引用方式与顺序原则

rules 里用 RULE-SET,规则集名,策略组 完成引用。规则匹配自上而下、首条命中即停,所以顺序就是优先级:广告拒绝集放最前,局域网与国内直连放中间,FINAL 兜底在最后。RULE-SET 的位置写错了,排在它后面的规则永远轮不到。另外,GEOSITE 规则(如 GEOSITE,cn)由内核内置的 geosite 数据库提供,与 RULE-SET 的外部文件是两套来源,可以混用。

rule-providers:
  reject:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/reject.yaml"
    path: ./ruleset/reject.yaml
    interval: 86400
  lan:
    type: http
    behavior: classical
    format: text
    url: "https://example.com/rules/lan.txt"
    path: ./ruleset/lan.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,lan,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

GEO 数据库:来源与自动更新

GEOIP、GEOSITE 两类规则背后是内核自带的两个数据文件:geoip 按 IP 段标注国家归属,geosite 按域名归类站点集合。它们和规则集一样会过时,但更新走的是另一套机制,在主配置顶层声明:

geodata-mode: true        # geoip 用 dat 完整数据(false 则用精简 mmdb)
geo-auto-update: true     # 自动更新开关
geo-update-interval: 168  # 单位小时,一周一次足够
geox-url:
  geoip: "https://example-mirror.com/geoip.dat"
  geosite: "https://example-mirror.com/geosite.dat"

geox-url 用来改数据文件的下载源,默认源直连拉不动时换成镜像地址即可。geodata-mode 的取舍是体积换精度:dat 完整数据分类更细,配合 geosite 的子类(如 geosite:cn 下还能再分)用起来更顺手;精简 mmdb 体积小、加载快,路由器等内存紧张的设备更合适。要注意 GEO 数据更新失败不会报致命错误,内核只是继续用旧数据,所以它出问题往往是无声的:明明是国内域名却走了代理、GEOIP,CN 命中不准,这类"分流突然变笨"的现象,先怀疑 GEO 数据陈旧,在客户端设置里手动触发一次 GEO 更新再观察。另外 GEO 数据更新后需要重启内核才生效,这一点与规则集"拉新即用"不同,别在这里空等。

DNS 配置优化

DNS 是分流质量的分水岭。三个典型问题:运营商 DNS 返回被污染的结果;系统或浏览器绕过代理直接问运营商,造成 DNS 泄漏;境外域名用国内 DNS 解析,拿到不优的 CDN 节点。mihomo 的 dns 段就是用来接管这三件事的。

推荐结构

打开内核 DNS(enable 加 listen),enhanced-mode 选 fake-ip(原理见第五章);nameserver 填国内公共 DNS 保底;nameserver-policy 按 geosite 把国内域名钉在国内 DNS;fallback 填 DoH 给境外域名;fallback-filter 用 geoip 过滤——解析结果落在 CN 段以外的才采信 fallback,污染结果进不来。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.msftconnecttest.com"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - "https://1.1.1.1/dns-query"
    - "https://dns.google/dns-query"
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
      - 119.29.29.29

DNS 泄漏是什么

泄漏指应用不经过内核、直接向运营商 DNS 发查询,访问记录对运营商完全透明。对策是让内核接管全部 DNS 查询:TUN 模式用 dns-hijack 拦下整机 53 端口(第五章),非 TUN 场景把系统 DNS 指到 127.0.0.1 并确认 listen 监听了 53 端口。泄漏的症状与验证方法见疑难解答页的 DNS 条目。

TUN 模式与 Fake-IP

系统代理只管"听话"的应用——浏览器和遵循系统代理设置的软件。游戏、部分命令行工具、UWP 应用不走系统代理,UDP 与 ICMP 流量也管不到。TUN 模式虚拟出一张网卡接管整机流量,是覆盖面最大的接管方式。日常浏览用系统代理就够,遇到不服从代理设置的应用再开 TUN。

关键字段

stack:协议栈实现,差异见下表。dns-hijack:DNS 劫持,any:53 把整机 53 端口的查询全拦给内核 DNS,与第四章的配置联动。auto-route:自动配置路由表,把流量引进虚拟网卡。auto-detect-interface:自动识别出口网卡,防止流量回环。mtu:默认即可,个别校园网或专线环境需要调小。

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

Fake-IP 与 redir-host 的区别

redir-host 模式下,应用先真实解析域名拿到 IP 再发起连接,内核按 IP 反查域名匹配规则——多一次真实解析的等待,还可能拿到被污染的 IP。fake-ip 模式在 DNS 阶段直接返回 198.18.0.1/16 段里的假地址,应用拿着假地址来连,内核按假地址反查域名再匹配规则——省掉真实解析,规则匹配直接拿到域名,分流更准、首次连接更快。

代价是有些服务不能拿假地址:局域网域名、NTP 校时、部分国内直连服务。这些写进 fake-ip-filter,内核对这些域名返回真实解析结果。第四章的示例里带了一份基础名单,按需往里补。

域名嗅探

理想情况下,内核从连接里直接拿到目标域名。但不少应用自己做了 DNS——内置 DoH、硬编码 IP——到内核这一层只剩一个 IP 地址,域名规则全部落空,只能指望 IP 规则兜底,分流精度明显下降。域名嗅探(sniffer)就是把这个丢掉的域名找回来。

工作原理

内核检查连接的首个握手包:TLS 的 ClientHello 里有 SNI 字段,HTTP 请求里有 Host 头,两者都写着目标域名。嗅探把域名提取出来替换掉连接目标,重新走一遍规则匹配——原本只能命中 IP 规则的流量,现在能命中域名规则,面板里按裸 IP 显示的连接也会明显变少。

配置示例

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

override-destination 表示用嗅探出的域名覆盖连接目标,fake-ip 与 TUN 场景建议开启;纯 redir-host 且规则以 IP 段为主的配置可以不开。skip-domain 放嗅探会出问题的服务:苹果推送、米家这类证书绑定严格的服务,嗅探改写会导致握手失败,直接跳过最省事。

本地覆写与多订阅合并

订阅是整份下发的:机场更新配置,客户端一拉新,手改的策略组和规则全被覆盖。正确姿势是订阅归订阅、本地改动归本地,两者在加载时合并,不落进同一个文件。

Clash Verge Rev:Merge 覆写

在「订阅」页进入全局扩展配置,选 Merge(合并)方式,用固定键名描述改动:prepend-rules 与 append-rules 在规则头部或尾部插入;prepend-proxies 与 append-proxies 追加节点;prepend-proxy-groups 与 append-proxy-groups 追加策略组。处理时机在订阅加载之后,订阅怎么更新,覆写都会重新套上去。熟悉 JavaScript 的用户也可以选 Script 方式写处理函数,自由度更高,但多数需求用 Merge 键名就够。

# Clash Verge Rev 全局扩展配置(Merge)
prepend-rules:
  - "DOMAIN-SUFFIX,internal.example.com,DIRECT"
append-proxy-groups:
  - name: "下载"
    type: select
    proxies: ["节点选择", "DIRECT"]

其他客户端的入口

Clash Plus 在配置管理里对当前订阅做覆写;FlClash 在配置详情里编辑覆写段;裸内核用户没有覆写层,建议把主配置握在自己手里,订阅只走 proxy-providers 提供节点。

多订阅合并:proxy-providers

手上有两个以上机场时,不需要把节点复制进主配置。proxy-providers 把每个订阅拉成独立的节点集合,各自定时更新、各自健康检查;策略组用 use 同时引用多个集合,节点并集进组,一处切换。

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: "http://www.gstatic.com/generate_204"
      interval: 300
  airport-b:
    type: http
    url: "https://example.com/sub-b.yaml"
    path: ./providers/airport-b.yaml
    interval: 86400
    health-check:
      enable: true
      url: "http://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: "自动选择"
    type: url-test
    use: ["airport-a", "airport-b"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

外部控制面板

mihomo 内置 RESTful API,桌面客户端的界面本质上都是它的前端。把 API 暴露出来,浏览器里就能挂一个控制面板——在服务器、路由器上裸跑内核时没有图形界面,这是标准的管理方式。

打开 API

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

external-controller 是监听地址;secret 是访问密钥;external-ui 指向面板静态文件目录,配好之后访问 http://127.0.0.1:9090/ui 直接打开面板。不想自己托管面板文件,就用在线面板——metacubexd、zashboard、yacd-meta 都在活跃维护,打开网页填 API 地址和密钥即可使用。

常用接口

# 查看所有策略组与节点
curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/proxies

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

常用接口还有 /connections(活动连接列表,可逐个关闭)、/traffic(实时速率)、/logs(日志流)。写脚本批量切节点、做健康巡检,都靠这几个接口。

配置校验与排错

改完配置先验证再重启。图形客户端的日志页会直接报出 YAML 错误的行号;裸内核用命令行做完整加载测试:

mihomo -t -d /etc/mihomo

-t 表示只测试不运行,-d 指定配置目录。语法错误、引用了不存在的策略组、规则集路径不存在,都会在这一步报出来,不会带病上线。

YAML 高频错误对照

缓存与状态文件

内核在配置目录下维护一份 cache.db,存两类运行状态:各 select 组上次选中的节点,以及 Fake-IP 的域名映射表。这份缓存由配置里的 profile 段控制:

profile:
  store-selected: true   # 重启后记住各组手选的节点
  store-fake-ip: true    # Fake-IP 映射持久化,重启后映射不变

store-selected 建议保持开启,否则每次重启内核,所有 select 组都会跳回列表第一项,之前手选的出口全部作废。store-fake-ip 决定 Fake-IP 映射是否跨重启保留,开启后可以避免重启瞬间旧映射失效造成的短暂断流。排错时这份缓存本身也是嫌疑对象——改过组结构、换过订阅之后如果行为诡异(组里出现早已删掉的节点名、切换选项不生效),直接删掉 cache.db 让内核重建一份,往往比逐项排查更快。删缓存的代价只是手选节点归位、Fake-IP 重新分配,没有其他副作用,可以放心当作常规排错手段。

排查顺序

"改了没生效"按四步走:一,确认编辑的是当前生效的那份配置,多订阅并存时最常踩这个坑;二,更新订阅后确认覆写仍然在位;三,查看运行时配置,确认合并结果符合预期;四,清规则集与节点缓存后重启核心。规则不命中时,在面板或日志里看该连接实际命中的规则链,多半是顺序问题——更具体的报错问答集中在疑难解答页,Windows 平台的安装坑见博客《Clash Windows 版安装配置全流程与高频问题避坑》。

如果问题出在客户端或内核本身,先确认用的是最新版本。客户端下载页汇总了五个平台的客户端与内核包,全平台首推 Clash Plus;订阅层面的更新失败排查见博客《Clash 订阅更新失败的常见原因与自动更新设置方法》。

把配置养好的几个习惯

手册类的内容看完容易忘,真正让配置长期稳定的是几个日常习惯。第一,任何改动前先备份当前能用的那份配置,哪怕只是复制一份重命名加上日期;改坏了能立刻回退,不用凭记忆反推。第二,一次只改一处,改完就验证——同时动策略组、规则和 DNS,出了问题根本分不清是哪一处引入的。第三,把常用的本地定制全部收进覆写入口,而不是直接编辑订阅下发的文件,这样订阅更新再频繁也不会冲掉自己的调整。第四,定期看一眼面板里的连接列表,留意那些长期命中 FINAL 兜底规则的域名,它们往往是该补规则的对象;也留意延迟长期偏高的策略组,考虑调整测速地址或容差。第五,内核与客户端保持更新,mihomo 仍在活跃维护,规则集语法、嗅探行为、TUN 实现都在持续改进,旧版本遇到的怪问题常常升级后就消失了。

最后提醒一个认知上的坑:Clash 系客户端的"系统代理""TUN""规则"是三层独立的东西。系统代理只是把应用的流量交给内核,TUN 是在网络层接管全部流量,规则才决定流量从哪个出口走。很多"开了代理但没走代理"的困惑,其实是三层里有一层没对上——应用没走系统代理、TUN 没开、或者规则把它分去了直连。排查时先确认流量确实进了内核(面板里能看到这条连接),再看它命中了哪条规则、落到了哪个出口,顺着这条链路查,比盲目改配置快得多。把这条链路想清楚了,本手册九章的内容就串成了一个整体:策略组与规则负责"往哪走",DNS 与嗅探负责"认出它是谁",TUN 与系统代理负责"把它接进来",覆写与校验负责"改得安全"。