Clash 进阶配置手册

配置基础:文件结构与生效方式

后面七章讲的所有内容,最终都会落到同一个 YAML 配置文件里。开始之前先花几分钟弄清楚:内核读取的配置到底从哪来、由哪几部分拼成、改完之后怎么确认已经生效。这一章是全篇的地基,跳过它直接改配置,很容易出现「改了没反应」或者「订阅一更新自定义全丢了」的情况。

配置文件的来源与层级

日常使用中,内核实际加载的配置通常不是某个单一文件,而是三层内容的合成结果:最底层是机场订阅拉取下来的原始 YAML(包含节点列表和机场预设的分组、规则);中间层是客户端(如 Clash Plus、Clash Verge Rev)提供的本地覆写(Merge/Script),用来在订阅之上追加或替换字段;最上层是客户端界面里的开关设置(端口、系统代理、TUN 等),部分客户端会把这些设置也合并进最终配置。理解这个层级的意义在于:凡是想长期保留的自定义,都应该写在覆写层,而不是直接编辑订阅文件——订阅一更新,直接改在订阅文件里的内容会被原样覆盖。覆写的具体做法见第七章。

几个绕不开的全局字段

下面这些字段出现在配置文件顶层,后续章节会反复引用,先建立印象:

mode 值得多说一句:日常应保持 rule(按规则分流);global 会把全部流量丢给一个策略,只适合临时排查「是不是规则出了问题」;direct 则等于临时停用代理。三种模式在客户端界面上都能一键切换,不需要改文件。

修改后如何确认生效

改完配置有两种生效方式:客户端界面里的「重载配置」按钮(推荐,不断开现有工作状态),或者重启内核。确认是否生效最可靠的办法是看日志页——内核启动或重载时会逐条打印监听端口、TUN 状态、规则条数等信息;如果配置有语法错误,重载会失败并在日志里给出行号。看不懂日志字段的话,可以对照这篇文章:Clash 运行日志怎么看。改动 YAML 时还有一个通用建议:缩进一律用空格,不要用 Tab,YAML 对缩进极其敏感,大量「配置加载失败」其实只是缩进错位。

策略组类型与实战

策略组(proxy-groups)是分流体系的中枢:规则命中后并不直接指向某个节点,而是指向一个策略组,由策略组再决定「此刻用哪个节点」。机场订阅通常自带一套分组,但理解各类型的行为差异之后,完全可以按自己的使用习惯重新设计。

四种常用类型的行为差异

注意 url-test 与 fallback 的本质区别:前者追求「最快」,节点排名变了就切;后者追求「稳定」,只要列表靠前的节点还活着就绝不切换。日常网页浏览用 url-test 体验好,而对连接持续性敏感的场景(在线会议、长时间登录态)更适合 fallback。

一份可参考的分组配置

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

  - name: 自动测速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: [香港-01, 香港-02, 日本-01]

  - name: 故障转移
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港-01, 日本-01, 新加坡-01]

  - name: 下载专用
    type: load-balance
    strategy: consistent-hashing
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港-01, 香港-02, 香港-03]

几个关键参数:url 是健康检查的目标地址,惯例用返回 204 状态码的轻量地址;interval 是检查间隔(秒),不宜低于 120,过于频繁的测速本身就会消耗节点流量;tolerance 只对 url-test 有效,表示新旧最优节点延迟差超过这个毫秒数才切换,能有效抑制两个延迟接近的节点来回横跳;load-balance 的 strategy 可选 consistent-hashing(同一目标站点固定走同一节点,登录态友好)或 round-robin(逐连接轮询,分散更彻底)。此外还可给组加 lazy: true,让组在未被使用时暂停测速,进一步省流量。

实战:入口—功能—地区的三层嵌套

策略组可以引用策略组,这是设计分流体系时最有用的特性。推荐的组织方式是三层:最上层一个 select 总入口(平时手动停在「自动测速」上);中间层按业务拆分功能组,如「流媒体」「AI 服务」「下载专用」,每个功能组都是 select,候选项里放地区组和总入口;最下层是按地区聚合的 url-test 组(香港自动、日本自动等)。这样日常无需任何操作,想临时把某项业务钉在特定地区时,只在对应功能组里点一下即可,不影响其他流量。规则如何指向这些功能组,见下一章。

规则集订阅化管理

直接把几千条 DOMAIN-SUFFIX 写在配置文件的 rules 段里,既难维护又难更新。规则集(rule-providers)把规则拆成独立文件、以订阅的方式引用:主配置里只留一行 RULE-SET,规则内容由内核定时从远端拉取并缓存到本地。规则更新与主配置解耦,是进阶配置里性价比最高的一步改造。

behavior 与 format:先分清规则文件的三种「体质」

format 描述文件格式:yaml 与 text 是人类可读的文本;mrs 是 mihomo 的二进制格式,加载快、体积小,但仅支持 domain 与 ipcidr 两种 behavior,且无法直接用编辑器查看。引用别人维护的规则仓库时,behavior 和 format 必须与文件实际内容一致,写错会导致整个规则集加载失败。

声明与引用示例

rule-providers:
  streaming:
    type: http
    behavior: classical
    format: yaml
    url: https://example.com/rules/streaming.yaml
    path: ./rules/streaming.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: mrs
    url: https://example.com/rules/cn-ip.mrs
    path: ./rules/cn-ip.mrs
    interval: 86400

rules:
  - RULE-SET,streaming,流媒体
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

interval 是自动更新间隔(秒),规则列表变动不频繁,86400(一天)足够;path 是本地缓存路径,断网启动时内核会直接用缓存,不会因为拉不到远端而起不来。

匹配顺序与 no-resolve

rules 段自上而下逐条匹配,命中即停,顺序就是优先级。通用的排布原则:精确的、面向具体业务的规则放前面;GEOIP 这类 IP 规则放靠后——因为遇到 IP 规则时,如果目标还是域名,内核需要先做一次 DNS 解析才能判断归属,把它放前面会拖慢所有请求的匹配。给 IP 类规则加 no-resolve 后缀,表示「目标不是 IP 就跳过本条,不要为它触发解析」,是控制解析开销的常用手段。最后一条务必是 MATCH 兜底,否则未命中的流量行为不可预期。

DNS 配置优化

很多「规则明明写对了却分流不对」「打开网页第一下特别慢」的问题,根源都在 DNS。Clash 之所以要内置一套 DNS 模块,是因为分流决策强依赖域名解析的结果:解析被污染,IP 规则就会误判;解析走了慢速链路,所有请求都要为它排队。这一章讲清楚 DNS 各字段的分工,以及国内外域名分开解析的标准做法。

字段分工:default-nameserver 与 nameserver

最容易混淆的一对字段:default-nameserver 只干一件事——解析 nameserver 里那些 DoH/DoT 服务器自己的域名(比如 doh.pub 这个域名本身也需要先解析成 IP 才能连上),因此它必须填纯 IP 的传统 DNS;nameserver 才是日常查询真正使用的上游,推荐填加密 DNS(DoH/DoT),避免明文查询在链路上被篡改。enhanced-mode 决定解析结果的呈现方式(fake-ip 或 redir-host),与 TUN 关系密切,细节放在第四章展开。

按域名走不同上游:nameserver-policy

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://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
    "geosite:geolocation-!cn":
      - https://dns.cloudflare.com/dns-query
      - https://dns.google/dns-query

nameserver-policy 是现代配置里替代老式 fallback + fallback-filter 组合的推荐写法:按域名归属直接指定上游——国内域名交给国内公共 DoH,拿到就近 CDN 节点,速度最优;境外域名交给国际 DoH,从源头避开污染。geosite: 前缀引用的是内核附带的域名分类数据库,不需要自己维护域名列表。相比让所有查询先问一遍再对结果做过滤的 fallback 机制,policy 方式路径更短、行为更可预期。

常见误区与验证方法

误区一:把 nameserver 全部填成境外 DNS。境外上游解析国内域名会返回面向海外的 CDN 节点,国内直连流量反而变慢,这是「开了代理连国内网站也卡」的高频原因之一,排查思路可参考网速慢排查清单。误区二:忽视浏览器自带的 DoH——Chrome/Firefox 的「安全 DNS」开关会绕过客户端的 DNS 模块,导致 fake-ip 与域名规则双双失效,建议在浏览器设置里关闭,或依靠域名嗅探兜底。验证 DNS 配置是否按预期工作,最直接的方式是开 debug 日志观察每个域名实际使用的上游,更多解析类问题可查 FAQ 页的故障排查分类。

TUN 模式与 Fake-IP

系统代理模式下,只有「愿意遵守系统代理设置」的应用会把流量交给客户端——浏览器基本都遵守,但相当多的桌面程序、命令行工具、游戏客户端会无视这项设置直连出去。TUN 模式通过创建一块虚拟网卡在网络层接管全部流量,不管应用配不配合,统统纳入分流,这是它的核心价值。

启用 TUN 的最小配置

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

auto-route 自动配置系统路由表,把默认路由指向虚拟网卡;auto-detect-interface 自动识别真实物理网卡作为出口,避免流量在虚拟网卡里打转形成回环;dns-hijack 把发往任意地址 53 端口的明文 DNS 查询劫持到内核的 DNS 模块,保证解析统一入口——这一条对 fake-ip 正常工作至关重要。实际使用时通常不必手写这段:Clash Plus、Clash Verge Rev 等客户端都提供 TUN 开关,由客户端注入等效配置。

stack 的三种实现

没有特殊需求时选 mixed;遇到某类应用在 TUN 下异常,把 stack 换一种实现再试,是排查兼容性问题的常规步骤。

Fake-IP:原理与例外名单

enhanced-mode: fake-ip 的工作方式:应用发起域名查询时,DNS 模块不做真实解析,立即返回一个 198.18.0.0/16 保留段内的「假 IP」,并记住这个假 IP 与域名的对应关系;应用拿假 IP 发起连接,内核在连接进来时反查出域名,再按域名规则分流,真正需要解析时才由出口侧完成。好处非常直接:省掉了本地等待真实解析的一轮往返,规则匹配拿到的是可靠域名而非可能被污染的 IP。与之相对的 redir-host 模式返回真实 IP,兼容性更「传统」,但会带来解析等待与污染风险,现已不作为推荐默认。

fake-ip 的代价是:少数程序会把解析结果拿去做连接之外的用途(校时、局域网发现、把 IP 上报给服务器),假 IP 会让它们出错。fake-ip-filter 就是例外名单,名单内的域名返回真实解析:

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

典型需要加入名单的:NTP 校时域名、局域网 mDNS 域名、STUN/游戏对战类需要真实地址协商的服务。遇到某个应用只在开启 TUN + fake-ip 后异常,优先怀疑它需要进这个名单。

域名嗅探

分流规则大部分是围绕域名写的,但总有一些连接到达内核时只有 IP、没有域名:应用自己内置了 DNS(比如浏览器开了 DoH)绕过了客户端的解析,或者程序直接硬编码 IP 连接。这类连接只能退化到 GEOIP 和兜底规则,分流精度大打折扣。域名嗅探(sniffer)的作用就是把域名「找回来」:从 TLS 握手的 SNI 字段、HTTP 请求的 Host 头、QUIC 初始包这些明文元数据里读出目标域名,再用它重新参与规则匹配。

启用与端口范围

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

sniff 下按协议声明要嗅探的端口范围——嗅探需要读取连接的前几个数据包,限定在常见端口能把开销控制在可忽略的水平。需要说明的是,嗅探读取的只是协议握手阶段本就明文传输的元数据(SNI、Host),并不涉及解开加密内容。

override-destination、force-domain 与 skip-domain

override-destination 决定嗅探出域名后是否用它替换连接的目标地址:开启后,后续匹配与出站都以嗅探到的域名为准,能纠正「假 IP 映射过期」「应用拿旧 IP 连新服务」之类的错位,一般建议开启。force-domain 是强制嗅探名单,名单内的域名即使已有解析记录也重新嗅探核对,适合那些 CDN 域名与实际服务域名经常不一致的站点。skip-domain 则是跳过名单——个别设备云服务(如示例中的米家)会在 TLS 握手里放非标准标识,嗅探替换后反而连不上,把它们排除即可。这三个参数组合起来,可以把嗅探的介入范围控制得很精细。

什么时候应该开嗅探

两个信号说明你需要它:一是日志里出现大量目标为纯 IP 的连接、最终全靠 GEOIP 或 MATCH 收尾;二是明明写了域名规则,某些应用的流量却总是不命中。开启嗅探后,再回看日志会发现这些连接重新带上了域名,规则命中情况立刻改善。配合上一章的 fake-ip 使用时,嗅探还是浏览器 DoH 绕过客户端 DNS 后的最后一道兜底。顺带一提,若开启嗅探前后浏览器出现证书告警,两者通常无关,具体成因见这篇分析:开启 Clash 后 HTTPS 证书报错的原因。

本地覆写与多订阅合并

第一章提到过原则:自定义写在覆写层,不动订阅原文。这一章展开讲两件事——怎么用客户端的覆写机制持久化自己的修改,以及怎么把多家机场的订阅合并进同一套分组体系。

本地覆写:让自定义在订阅更新后存活

主流客户端(Clash Plus、Clash Verge Rev 等)都提供「覆写/Override」能力,常见形态有两种:声明式的 Merge——写一段 YAML 片段,客户端在每次加载订阅后把它合并进去;程序式的 Script——写一小段脚本函数,接收解析后的配置对象,加工后返回。Merge 适合追加 DNS 段、前置几条自定义规则这类结构化修改;Script 适合「给所有分组批量插入一个节点」「按名字过滤节点」这类需要遍历逻辑的场景。一个典型的 Merge 片段:

dns:
  enable: true
  enhanced-mode: fake-ip

rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,Steam.exe,DIRECT

不同客户端对 Merge 的合并语义略有差别(整段替换还是逐项追加、规则是前置还是后置),第一次使用时务必在客户端里预览合并后的最终配置确认符合预期,再保存启用。各客户端覆写入口的位置,可参考博客的界面功能速览。

proxy-providers:多订阅合并的正确姿势

同时持有多家机场订阅时,不要在多个配置文件之间来回切换——用 proxy-providers 把每份订阅声明成一个节点提供者,再在策略组里用 use 字段引用,所有节点便汇入同一套分组与规则体系:

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

proxy-groups:
  - name: 全部节点
    type: select
    use: [airport-a, airport-b]
  - name: 香港自动
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    use: [airport-a, airport-b]
    filter: "(?i)香港|HK|Hong Kong"

filter 用正则按节点名筛选,是构建地区组的关键——两家机场的香港节点会被自动收进同一个「香港自动」组里测速竞争。use 与 proxies 可以在同一个组里并存,手动节点与订阅节点混编没有问题。

更新策略与容错

interval: 43200(12 小时)对订阅来说足够勤快;path 缓存保证拉取失败时沿用上一份节点列表,内核不会因为某家机场接口抽风而整体罢工。health-check 建议对每个 provider 都开启,否则 url-test 组拿不到延迟数据、无法完成自动选择。另外注意:provider 的 url 由内核直接发起请求,若订阅地址本身需要代理才能访问,需在 provider 上配置代理路径或先保证有可用的直连线路,避免「鸡生蛋」死锁。

外部控制与管理面板

内核自带一套 RESTful 控制接口(external controller),客户端图形界面本质上就是这套接口的消费者。理解它之后能解锁不少玩法:用浏览器面板管理跑在软路由/服务器上的裸内核、写脚本定时切换策略、把连接数据接进自己的监控。

开启接口与访问控制

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

external-controller 监听在 127.0.0.1 时只有本机能访问,这是桌面环境的安全默认;改成 0.0.0.0:9090 才能从局域网其他设备访问,此时 secret 必须设置且足够复杂——这个接口能读连接、改策略、重载配置,权限等同于完全控制客户端。请求方通过 Authorization: Bearer 头携带密钥。

几个常用 API

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

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

# 查看当前活动连接
curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/connections

# 触发指定节点的延迟测试
curl -H "Authorization: Bearer your-password" \
  "http://127.0.0.1:9090/proxies/香港-01/delay?timeout=5000&url=https://www.gstatic.com/generate_204"

此外 /logs 与 /traffic 是流式接口,持续推送日志与实时流量,面板里滚动的日志和速率曲线就来自它们;PATCH /configs 可以在不重启的情况下切换 mode、改端口。

实际动手调用这套接口时,有几个细节值得先记住。所有请求都需要在头部带上 Authorization: Bearer <secret>,漏掉或填错都会直接返回 401;流式接口(/logs、/traffic、/connections 的实时推送)走的是长连接,用普通的一次性请求工具会看起来「卡住不返回」,这属于正常现象,需要用支持流式读取的方式消费。写自动化脚本时,建议先用只读接口(如 GET /proxies、GET /rules)确认鉴权与地址无误,再动用会改状态的 PUT/PATCH 类调用,避免脚本逻辑没调通就把客户端切到意料之外的策略;调试完成后务必把临时放开的监听地址改回 127.0.0.1,不要让一个高权限接口长期裸露在局域网里。

Web 面板:给裸内核一张脸

external-ui 指向一个静态网页目录,内核会把它托管在控制端口的 /ui 路径下;external-ui-url 则让内核自动下载并解压面板资源包。社区常用的面板有 metacubexd、yacd 及其衍生版本,功能大同小异:分组切换、延迟测试、连接列表、规则与日志查看。这套玩法最适合「服务器或路由器上跑裸 mihomo 内核」的场景——内核安装包可在下载页的内核区获取;桌面用户则一般用不到,Clash Plus、Clash Verge Rev 等客户端已经把同样的能力做进了本地界面。