Clash 进阶配置手册

配置分层与编辑入口

开始逐段调参之前,先弄清一份生效配置由哪些层组成。理解分层,才知道自己改的内容会不会被订阅更新覆盖,以及自定义内容应该写在哪一层。

四层配置的优先级

Clash Verge 的运行时配置由四层叠加,从低到高依次是:

• 订阅配置:从订阅链接拉取的原始 YAML,或手动导入的本地文件。这一层由服务商或自己维护,客户端每次更新订阅都会用新内容整体替换。
• 本地配置:客户端内置的基础片段,一般只提供端口、模式等字段,可编辑但用途有限。
• 覆写配置:对订阅配置做增量修改的 YAML,支持 prepend / append 合并指令。订阅更新后覆写仍然生效,是长期使用中最重要的自定义层。
• 脚本配置:一段 JavaScript,在合并完成后对最终配置做程序化修改,适合需要条件判断或批量生成的场景。

运行时最终配置 = 订阅 → 本地 → 覆写 → 脚本,后一层覆盖前一层的同名键。看到「改了没生效」时,先按这条链检查是不是有更高层把值盖回去了。

配置文件存放与备份

各平台默认路径:

• Windows:%APPDATA%\clash-verge\profiles\
• macOS:~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/profiles/
• Linux:~/.config/clash-verge/profiles/

每个订阅对应一个以 UUID 命名的目录,里面的 config.yaml 是拉取后的原始内容,merge.yaml 与 script.js 分别是覆写与脚本。备份时拷贝整个 profiles 目录即可。需要手工调整时,推荐在「配置」页选择对应订阅,点「编辑」进入覆写或脚本,而不是直接改拉取下来的 config.yaml——下次更新订阅会把直接修改冲掉。

通用字段速查

以下字段由 mihomo 内核直接读取,写在配置顶层,任何订阅都会用到:

配置示例 · 顶层通用字段

port: 7890              # HTTP 代理端口
socks-port: 7891        # SOCKS5 代理端口
allow-lan: false        # 是否允许局域网设备连接
mode: rule              # rule / global / direct
log-level: info         # silent / error / warning / info / debug
ipv6: false             # 是否处理 IPv6 流量
external-controller: 127.0.0.1:9090
secret: ""              # 控制 API 访问令牌

• mode: rule 按规则分流;global 全部走代理;direct 全部直连。日常保持 rule。
• log-level 调成 debug 时,日志会显示每条连接命中的规则,排错很有用,排完记得改回 info。
• allow-lan 打开后,同一局域网的手机、平板可以手动设置代理指向这台电脑,前提是系统防火墙放行对应端口。

编辑与校验

编辑完 YAML 后,先点「配置」页的调试按钮,或直接看日志窗口有没有解析错误。常见错误三类:缩进用了 Tab(必须用空格)、冒号后少了空格、引号没有闭合。mihomo 的报错会精确到行号,按行号回查即可。整份配置的逐段结构,可以对照《Clash 配置文件 YAML 结构逐段解析》阅读。

策略组类型与实战

策略组(proxy-groups)决定一组节点以什么逻辑被选中。规则最终指向的往往不是单个节点,而是一个策略组;把组配好,规则层就简单了。

五种内置类型

select:手动选择,面板里点哪个用哪个,适合「主力节点」这类需要随时切换的组。

配置示例 · select 组

- name: 主力
  type: select
  proxies:
    - 香港 01
    - 日本 01
    - 直连

url-test:自动测速,定时对所有成员发起测试请求,选中延迟最低的节点。interval 是测速间隔(秒),tolerance 是容差(毫秒)——两个节点延迟差小于容差时保持当前节点,避免来回横跳。

fallback:按列表顺序使用,当前节点不可用时自动切到下一个。适合「首选某条线路,挂了才换」的场景。

load-balance:负载均衡,把连接分散到多个节点。strategy 支持 consistent-hashing(同一域名固定到同一节点,兼容性最好)、round-robin(轮流)、sticky(会话保持)。下载、大流量场景用这个组可以跑满多线。

relay:链路代理,流量按组内顺序经过每一站,常用于「落地」组合。relay 对协议支持有限,部分机场节点不支持链式转发,启用前先在面板里逐站验证。

特殊组与嵌套

DIRECT 与 REJECT 不是策略组,但可以出现在 proxies 列表里,分别表示直连与拒绝。策略组可以嵌套:外层组引用内层组,规则只需指向最外层。mihomo 还支持 include-all: true 自动包含配置里所有节点,以及 include-other-group 引用其他组的成员。订阅节点经常变动时,用这两个参数可以少维护很多。

一组实战模板

配置示例 · 流媒体 / 游戏 / 下载三组模板

proxy-groups:
  - name: 流媒体
    type: url-test
    proxies: [香港 01, 香港 02, 日本 01]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 游戏
    type: fallback
    proxies: [香港 01, 日本 01, 直连]
  - name: 下载
    type: load-balance
    proxies: [香港 01, 香港 02]
    strategy: consistent-hashing
  - name: 主力
    type: select
    proxies: [流媒体, 游戏, 下载, 直连]

• 流媒体组用 url-test 自动挑最快线路,tolerance 给 50ms,防止延迟差几毫秒就切换导致播放中断。
• 游戏组用 fallback:首选线路延迟升高但没断时 url-test 会切走,fallback 只在真正不可用时才切换,对长连接更友好。
• 测试 URL 用 http://www.gstatic.com/generate_204,它返回 204 不产生流量;访问不了就换成 http://cp.cloudflare.com/generate_204。

常见误区

• tolerance 设成 0:延迟差 1ms 就切换,短连接场景会频繁断线。
• select 组里堆几十个节点:面板选择列表会很长,建议用自动组承接节点,select 只引用组。
• 忽略默认开启的 lazy:首选项不会立刻测速,面板显示的延迟是占位;需要立即看数值就手动点测速。
• 组名大小写不一致:规则里引用组名是大小写敏感的,写错不报错,流量会掉进兜底策略。

规则集订阅化管理

规则(rules)是配置里最容易膨胀的部分。几百条规则写进主配置,既难读,又会跟着订阅更新被覆盖。规则集(rule-providers)把规则拆成独立文件,单独更新,主配置只保留引用。

规则集的三种行为

behavior 决定规则集如何被解析:

• domain:内容是域名列表,每行一个域名,+ 开头表示后缀匹配。适合自维护的网站清单。
• ipcidr:内容是 IP 或 CIDR 段,用于 IP 规则。
• classical:完整规则语法,每行一条 DOMAIN,xxx,策略 或 IP-CIDR,1.2.3.0/24,策略,最灵活。

远程与本地规则集

配置示例 · rule-providers 两种来源

rule-providers:
  geosite:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/geosite.yaml"
    path: ./rules/geosite.yaml
    interval: 86400
  my-custom:
    type: file
    behavior: classical
    format: text
    path: ./rules/custom.txt

• type: http 表示远程拉取,interval 是自动更新间隔(秒),86400 即每天一次。path 是本地缓存路径,拉取失败时内核会用缓存继续工作。
• type: file 表示本地文件,适合自己维护的规则,不参与远程更新。
• format: yaml 时内容要写成 YAML 列表;format: text 时每行一条,更接近纯文本习惯。

在 rules 中引用

配置示例 · RULE-SET 引用

rules:
  - RULE-SET,geosite,流媒体
  - RULE-SET,my-custom,直连
  - MATCH,主力

RULE-SET 第一个参数是规则集名,第二个参数是命中的策略组。规则集内部如果是 classical 行为且每条规则自带策略,第二个参数可以省略。

更新与维护

• 远程规则集在「订阅」页可以单独点更新,也可以等 interval 到期自动更新。
• 订阅更新不会触碰规则集:规则集是独立文件,这正是把规则从主配置拆出来的核心收益。
• 规则集文件里不要写列表之外的额外内容,format: yaml 模式下顶层必须是列表,写错格式会导致整个规则集加载失败,对应规则全部失效,流量掉进兜底策略。
• 判断规则集是否生效:日志窗口搜 rule-provider 能看到加载与更新记录;debug 日志能看到每条连接命中的规则。

分流思路

常见做法是「域名规则集 + IP 规则集 + 兜底」三层:先把广告、追踪域名 REJECT,再把流媒体域名指向流媒体组,接着把国内域名直连,最后 MATCH 走主力组。mihomo 按从上到下匹配,第一条命中的规则生效,所以 REJECT 与直连规则要放在前面。

DNS 配置优化

DNS 是分流质量的分水岭。域名解析结果直接决定连接走代理还是直连,配置不当会出现「该走代理的走了直连」「DNS 泄漏」和「解析超时」三类问题。

dns 段基础结构

配置示例 · 国内 DoH 主解析 + 国外 DoH 兜底

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  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://dns.google/dns-query
  fallback-filter:
    geoip: true
    geosite: geolocation-!cn

• default-nameserver 只用于解析 DNS 服务器自身的域名,必须写 IP 地址,否则启动时会先卡在 DNS 解析。
• nameserver 是主解析通道,国内 DoH(阿里、腾讯)速度快,国内域名解析准确。
• fallback 是备用通道,当主通道返回的结果被 fallback-filter 判定为异常时使用。geoip: true 配 geosite: geolocation-!cn 的含义是:nameserver 返回的 IP 属于国外、而域名不是国内域名时,改用 fallback 重新解析,这是防止国内 DNS 污染国外域名解析的标准做法。
• ipv6: false 时,即使系统有 IPv6,mihomo 也只请求 A 记录;需要 IPv6 出口再打开。

enhanced-mode 怎么选

fake-ip:域名不真实解析,直接映射到 fake-ip-range(默认 198.18.0.1/16)里的虚拟 IP。应用连接虚拟 IP,内核在转发时还原域名做规则匹配。速度快、防 DNS 泄漏,是 TUN 模式下的推荐选择。

redir-host:真实解析后返回结果,规则匹配用真实 IP。兼容性更稳,但每次连接都要等解析完成,且结果可能被污染。

劫持与缓存

dns-hijack 在 tun 段配置,把发往 53 端口的 DNS 请求劫持到内核自己的 DNS 服务:

配置示例 · DNS 劫持与缓存

tun:
  dns-hijack:
    - any:53

cache:
  enabled: true
  size: 4096
  ttl: 300

cache 段缓存解析结果,减少重复查询。ttl 是缓存秒数:太短缓存没意义,太长域名换 IP 后延迟会变大,300 秒是常用值。

排错分支

• 打开网页经常等几秒才加载:检查 nameserver 是否用了 DoH,以及网络能否直连 DoH 服务器;某些网络环境访问国外 DoH 不稳定,把备选 DoH 放进 nameserver 列表。
• 国内网站解析成国外 IP:fallback-filter 的 geosite 规则没生效,确认内核能拉到 geosite 数据源,或手动指定 geox-url。
• 订阅自带的 dns 段与覆写冲突:在覆写里整段覆盖 dns 键,不要逐字段合并。

TUN 模式与 Fake-IP

系统代理只接管「主动读取代理设置」的应用,命令行工具、游戏、UDP 流量常常绕开它。TUN 模式在系统里创建一张虚拟网卡,把全部 IP 流量拉进内核,是「全局接管」的正解;Fake-IP 则是 TUN 模式下 DNS 与规则匹配的搭档。

系统代理与 TUN 的差异

系统代理通过修改系统设置告诉应用「把流量发到 127.0.0.1:7890」,应用不读这个设置就失效。TUN 模式工作在 IP 层,虚拟网卡收到所有出站 IP 包,不依赖应用配合。差异直接体现在:

• 命令行工具、curl、git 默认不读系统代理,TUN 模式下无需逐个 export。
• 游戏与 UDP 应用,系统代理基本无能为力,TUN 可以接管。
• TUN 接管的是 IP 包,应用先发 DNS 查询再建 TCP 连接,所以 TUN 必须配合 DNS 劫持,否则域名解析仍走系统 DNS,规则匹配拿不到域名。

tun 段完整配置

配置示例 · tun 段

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

• stack:数据包处理栈。system 兼容性最好但性能一般;gvisor 性能好、资源占用低,但部分老系统不兼容;mixed 让内核按平台自动选择,新版推荐先用它。
• auto-route:自动添加路由,让虚拟网卡接管默认路由,必须开着。
• auto-detect-interface:自动检测出口网卡,多网卡(有线 + 无线 + 虚拟机)环境建议开启,否则可能选错出口导致断网。
• strict-route:Windows 上开启后严格接管路由表,能防止「部分流量漏出」,但也更容易与 VPN、虚拟网卡冲突,排错时可先关掉试。

Fake-IP 工作机制

开启 enhanced-mode: fake-ip 后,内核收到域名解析请求,不向真实 DNS 查询,而是从 fake-ip-range(默认 198.18.0.1/16)里返回一个虚拟 IP,并把「域名 ↔ 虚拟 IP」的映射记在内存里。应用连接虚拟 IP 时,内核根据映射还原域名,再走规则匹配。收益有两个:解析不再等待真实 DNS 往返,建连更快;规则匹配始终基于域名,不会被 IP 污染带偏。

fake-ip-filter 用于排除不需要虚拟 IP 的域名,常见的是本地服务、需要真实 IP 直连的站点:

配置示例 · fake-ip 范围与过滤

dns:
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "stun.*"

各平台注意点

• Windows:需要以服务模式运行,安装时勾选「安装服务」,或之后在设置里开启服务模式;系统防火墙要放行内核进程。
• macOS:开启 TUN 需要管理员授权,首次启用会弹密码框;系统更新后授权可能失效,重新开关一次 TUN 即可。
• Linux:需要 cap_net_admin 权限,以普通用户运行时确保二进制有对应 capability,或用 systemd 服务启动。
• Android:Clash Meta for Android 等客户端同样支持 TUN,需要系统 VPN 权限,与系统代理是互斥的两种工作方式。

排错分支

• 开启 TUN 后完全断网:先关 strict-route,再换 stack: system,检查 auto-detect-interface 是否选中了正确的网卡。
• 能上国内但国外超时:TUN 与 DNS 劫持配合出了问题,确认 tun 段有 dns-hijack: [any:53] 且 dns.enable 为 true。
• 某些应用连接被重置:应用可能校验了目标 IP,把该域名加入 fake-ip-filter 让它走真实解析。

域名嗅探

TUN 模式接管的是 IP 包,当应用直接连接 IP、或连接的是已被解析过的地址时,内核拿不到域名,规则匹配只能靠 IP。域名嗅探(sniffing)从连接内容里把域名「认」出来,补上这一环。

什么场景需要嗅探

• 应用自带 DNS 解析(部分游戏客户端、某些 App 直连 IP):流量到达 TUN 时只有 IP,没有域名。
• QUIC / HTTP3 连接:UDP 流量没有传统 DNS 查询可劫持。
• 连接复用:同一 TCP 连接上后续请求没有再发 DNS,规则只能按 IP 匹配。

配置示例

配置示例 · sniffing 段

sniffing:
  enable: true
  override-destination: false
  force-doman: true
  parse-pure-ip: true
  skip-dest-address:
    - 192.168.0.0/16
    - 198.18.0.1/16

• enable:总开关。
• override-destination:嗅探到域名后,是否把连接目标改写为域名。开启后规则匹配更准确,但部分协议(如 QUIC)不支持改写,建议保持 false,让内核只在能安全改写时才改。
• force-doman:强制规则匹配使用嗅探到的域名,即使配置里写的是 IP 规则。
• parse-pure-ip:对纯 IP 连接也尝试解析出域名(通过 TLS SNI 等字段)。
• skip-dest-address:跳过不需要嗅探的目标网段,通常把内网段与 fake-ip-range 排除,避免对虚拟 IP 做无意义的嗅探。

嗅探与规则匹配的顺序

连接进入后的匹配顺序是:先看连接是否命中 Fake-IP 映射(有域名直接用域名),再看是否被 skip 跳过,然后尝试嗅探,嗅探出域名后按「域名规则 → IP 规则 → 兜底」的顺序匹配。因此,DOMAIN 开头的规则在嗅探开启后覆盖范围会变广;IP 规则仍然有效,但排在域名规则之后。

注意事项

• 嗅探只读取连接前几个包,对性能影响很小;但 override-destination 开启后,部分应用会因目标地址被改写而报错,遇到「某个 App 开了 TUN 就连不上」时,优先关掉这一项。
• 非 TLS 的明文 HTTP 流量能嗅探 Host 头;TLS 流量读取 SNI;QUIC 流量读取 CHLO 中的 SNI,但 UDP 会话没有稳定的「连接」概念,部分实现会限制嗅探范围。
• 与 Fake-IP 的关系:Fake-IP 在 DNS 层已经拿到域名,嗅探主要补「没走 DNS 劫持」的流量。两者同时开启不是重复劳动,而是覆盖不同入口。

本地覆写与多订阅合并

直接改订阅拉下来的配置,更新一次就全部丢失。覆写(merge)是 Clash Verge 提供的增量修改层:订阅更新后,覆写里的改动自动重新应用。多订阅并存时,覆写还能把不同订阅的节点合并进同一个策略组。

覆写语法

覆写文件本身是 YAML,支持两类指令:

• 覆盖键:直接写目标键和值,替换订阅里的同名键。DNS、TUN 这类整段重写的场景用覆盖。
• 追加指令:prepend- 与 append- 前缀的键,把内容插到订阅对应列表的前面或后面。支持 prepend-proxies、append-proxies、prepend-proxy-groups、append-proxy-groups、prepend-rules、append-rules 等。

配置示例 · 追加指令

prepend-rules:
  - DOMAIN-SUFFIX,company.com,直连
append-rules:
  - GEOIP,CN,直连
  - MATCH,主力
prepend-proxy-groups:
  - name: 工作
    type: select
    proxies:
      - 公司专线
      - 主力

一个完整的覆写示例

配置示例 · 合并节点 + 自定义规则 + 固定 DNS

# 覆写:合并两个订阅的节点,追加自定义规则,固定 DNS
prepend-proxy-groups:
  - name: 全部节点
    type: select
    proxies:
      - 订阅A节点
      - 订阅B节点
      - 直连
prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,直连
  - RULE-SET,my-custom,主力
append-rules:
  - MATCH,全部节点
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query

注意:覆写里写 dns 键会整体替换订阅的 dns 段。想保留订阅的 DNS 又只改一处,要么把订阅的完整 dns 段拷过来改,要么用 prepend-dns/append-dns 对列表追加——但 dns 段的字段是嵌套对象,追加指令只对列表生效,最稳妥的做法是整段覆盖。

多订阅合并

• 在「配置」页添加多个订阅,每个订阅独立更新,互不干扰。
• 用「全部节点」这类策略组把多个订阅的节点收进来,通过 include-all 或覆写里的 proxies 引用组名。
• 切换订阅时,当前生效的 profile 整体切换,覆写与脚本始终叠加在「当前订阅」之上,所以覆写里引用节点名时,要保证每个订阅里都存在同名节点,否则策略组会引用空成员。
• 脚本模式(script.js)适合更复杂的合并逻辑:比如按订阅名称前缀自动分组、过滤掉关键词含「过期」的节点。脚本在覆写之后执行,接收 config 对象,返回修改后的对象。

维护建议

• 覆写内容按用途分区,用注释标出「规则」「策略组」「DNS」,半年后再看也一眼能懂。
• 每次更新订阅后,先看日志有没有 merge 失败类提示,确认覆写语法没被订阅内容冲突。
• 规则优先用规则集管理,覆写只放少量个性化规则,避免覆写本身膨胀成第二份主配置。

外部控制面板

日常切节点、看连接,客户端界面够用;但要批量操作、看规则命中、远程管理,就要用 mihomo 的外部控制 API。面板通过 HTTP 与内核对话,配置好 external-controller 就能用。

基础配置

配置示例 · 外部控制监听与令牌

external-controller: 127.0.0.1:9090
secret: "your-long-random-token"

• external-controller 格式是「地址:端口」。只在本机访问就写 127.0.0.1:9090;想从局域网访问,改成 0.0.0.0:9090 并配好防火墙,但不要直接暴露到公网——面板能切换代理、读取连接信息,裸奔的公网端口等于把代理控制权交给任何人。
• secret 是访问令牌,面板和 API 请求都要带。用足够长的随机字符串;Verge 的设置页也能生成并保存 secret。
• 修改 external-controller 或 secret 后需要重启内核才生效。

常用面板

mihomo 官方仓库提供 Yacd、MetaXD 等面板,构建后放在内核同目录的 ui 文件夹,浏览器访问 http://127.0.0.1:9090/ui 即可打开。面板首次打开会让你填后端地址与 secret。Verge 的「设置 → 外部控制」里也有面板入口,打开就能用。

REST API 常用端点

调用示例 · curl 读取与切换

curl -H "Authorization: Bearer your-long-random-token" \
  http://127.0.0.1:9090/proxies

curl -X PUT -H "Authorization: Bearer your-long-random-token" \
  -d '{"name":"香港 01"}' \
  http://127.0.0.1:9090/proxies/主力

• 用 GET /connections 排查「这条连接为什么走了直连」:返回里带 rule 与 rulePayload 字段,直接显示命中的规则。
• PUT /configs 适合快速切模式:{"mode":"global"} 临时全局代理,用完切回 rule。
• 所有接口都要求 Authorization 头,格式为 Bearer <secret>。

安全建议

• 面板与 API 只监听回环地址,或通过 SSH 隧道访问局域网外的机器。
• secret 不要写进会被同步的笔记,也不要在命令行历史里反复明文出现;用环境变量或客户端内置的 secret 管理。
• 定期用 GET /configs 检查 mode 是否被改过——如果发现 mode 被改成 global 且不是你改的,先怀疑端口暴露,再更换 secret。