Clash 配置文件参考大全

一、YAML 结构总览:一份配置由哪几块组成

Clash 的配置文件是一份标准 YAML 文档,默认文件名 config.yaml。YAML 有三条铁律,先记住再往下读:第一,层级完全靠缩进表达,约定两个空格一级,禁止使用 Tab;第二,冒号后面必须跟一个空格,port:7890 是语法错误,port: 7890 才合法;第三,值里含有冒号、井号、花括号等特殊字符时要用引号包裹,尤其是密码和 URL。井号 # 之后到行尾是注释,内核加载时忽略。

一份完整配置从上到下大致分四层:入站与运行参数(端口、模式、日志)、DNS 段、出站资源(proxies 节点列表、proxy-groups 策略组、两类 provider),最后是 rules 规则列表。内核按"规则命中 → 策略组决策 → 节点出站"的顺序处理每一个连接,配置文件的组织顺序与这条数据通路一一对应。下表是常用顶层字段速查:

下面是一份能直接跑起来的最小配置,五个部分齐全,后续每章都在这个骨架上扩展:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: "节点A"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - 节点A
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

二、通用字段:端口、模式与控制接口

入站端口:mixed-port 一个顶三个

早期配置习惯分开写 port: 7890(HTTP)与 socks-port: 7891(SOCKS5),现在推荐直接写 mixed-port: 7890——同一个端口自动识别两种协议,系统代理与各类应用的代理设置都指向它,省去区分协议的麻烦。7890 只是社区惯例,不是保留值;如果启动日志出现 "address already in use",说明端口被其他进程占用,换一个未占用端口即可。

allow-lan 与 bind-address

allow-lan: true 会把入站端口暴露给同一局域网的其他设备,常见用途是让电视盒子、游戏机借用电脑上的 Clash。配合 bind-address 可以限定监听地址:默认 "*" 监听所有网卡,改成具体内网 IP 可以只对某个网段开放。开启前先确认所处网络可信——在公司或公共 Wi-Fi 里开放 allow-lan,等于把出站通道借给了同网段的任何人。

mode:三种运行模式的边界

mode: rule 是日常形态,每个连接逐条过规则表;global 跳过规则,所有流量交给全局策略组选定的节点,适合临时验证"到底是规则问题还是节点问题";direct 则全部直连,相当于代理逻辑整体旁路。三种模式可以在客户端界面即时切换,不需要改文件,但配置文件里写的值决定内核启动时的初始模式。

log-level 与 external-controller

log-level 从少到多依次是 silent / error / warning / info / debug。排查"某条规则为什么没生效"时切到 debug,日志会打印每个连接命中的具体规则与最终出口;确认无误后调回 info,debug 级别的日志量对长期运行并不友好。external-controller: 127.0.0.1:9090 打开 RESTful 控制接口,客户端面板的节点切换、延迟测试、连接列表全部通过它完成;secret 字段给接口加访问口令,示例一律写假值如 secret: "xxxx";external-ui 指向一个本地目录,可以挂载网页面板。若把控制接口监听到 0.0.0.0,必须同时设置 secret,否则局域网内任何人都能改动你的代理状态。

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "xxxx"

ipv6: false 表示内核不解析、不使用 IPv6 地址。所处网络的 IPv6 连通性不佳时,关掉它可以避免一部分"解析出 v6 地址却连不上"的超时;网络与节点都支持 v6 时再打开。这个开关与 DNS 段里的解析行为联动,改动后建议重启内核而不是热重载。

端口占用与配置目录:两类最常见的启动失败

通用字段引发的启动失败集中在两处,值得单独说清。第一处是端口占用:内核启动时会绑定 mixed-port、DNS 监听端口与控制接口端口,任何一个被占用都会导致启动中断。Windows 上用 netstat -ano | findstr 7890 找出占用端口的进程号,再到任务管理器按 PID 定位程序;macOS 与 Linux 用 lsof -i :7890 得到同样结果。最常见的占用来源其实是"上一个内核进程没退干净"——客户端异常关闭后残留后台进程,重启客户端前先确认进程列表里没有同名内核在跑。若确实与其他软件冲突,把端口改成 7893、10808 这类不常用值即可,记得同步修改系统代理与各应用里填的端口号。

第二处是配置目录与文件编码。客户端读取的并不是你随手放在桌面的 YAML,而是自身 profile 目录下的副本;直接编辑桌面文件后重载没有任何变化,十有八九是改错了对象。正确做法是在客户端的"配置"页找到当前订阅条目,用其自带的编辑入口打开,或者点"打开配置目录"再编辑目录里的文件。另外,配置文件必须保存为 UTF-8 无 BOM 编码:带 BOM 的文件在部分内核版本上会让第一行字段解析失败,报出令人费解的"line 1"错误;Windows 记事本另存时选择"UTF-8"而非"带 BOM 的 UTF-8",或者干脆用 VS Code 一类编辑器,可以彻底避开这个坑。

三、DNS 配置:fake-ip、分流解析与防污染

DNS 段决定"域名如何变成 IP",直接影响分流准确性和连接成败。enable: true 启用内置 DNS 模块;listen 指定模块自身的监听地址,TUN 模式下配合 dns-hijack 使用。真正需要理解的是 enhanced-mode 的两种取值。

fake-ip 与 redir-host 的取舍

fake-ip 模式下,内核给每个域名先返回一个 fake-ip-range(默认 198.18.0.1/16)里的假地址,应用拿假地址发起连接,内核凭"假 IP ↔ 域名"映射还原出原始域名再做规则匹配——好处是域名规则百分之百命中、省去一次本地解析等待;代价是少数依赖真实 IP 的程序(局域网发现、部分游戏联机)会被假地址干扰,这类域名要加进 fake-ip-filter 白名单,让它们拿到真实解析结果。redir-host 则老老实实先解析再匹配,行为直观,但域名类规则可能因为"先拿到 IP"而漏判。桌面与移动端日常用 fake-ip,兼容性问题多的环境退回 redir-host。

nameserver、fallback 与 fallback-filter

nameserver 是主解析组,建议填运营商可达、延迟低的国内服务,支持 udp、tls://(DoT)与 https://(DoH)三种写法;fallback 是备用组,填可信的境外 DoH。两组并发查询后,fallback-filter 决定采信哪边:geoip: true 且 geoip-code: CN 的含义是——主组解析结果若是中国大陆 IP 则采信,否则改用 fallback 的结果,以此规避污染的答案。mihomo 内核额外支持 nameserver-policy,按域名后缀把特定域名指到特定 DNS,颗粒度更细。

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"
  nameserver:
    - https://223.5.5.5/dns-query
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

四、代理节点字段:proxies 逐协议拆解

proxies 是一个数组,每个元素描述一个出站节点。四个字段是所有协议共有的:name(节点名,全文件唯一,策略组靠它引用)、type(协议类型)、server(服务器地址,域名或 IP)、port(端口)。udp: true 声明该节点转发 UDP 流量,语音通话与游戏依赖它。名字里带中文、空格或特殊符号时用引号包住,避免解析歧义。

Shadowsocks(ss)

字段最少的协议:cipher 指定加密方法(常见 aes-128-gcm、chacha20-ietf-poly1305),password 是预共享密钥。cipher 拼写必须与服务端完全一致,写错的表现不是报错而是"连上了但数据全是乱码级失败",延迟测试永远超时。

VMess

核心是 uuid(用户身份标识)与 alterId(现代部署一律为 0)。cipher: auto 让两端协商加密;传输层通过 network 选择,裸 TCP 之外最常见的是 ws(WebSocket),此时用 ws-opts 补充路径与 Host 头,再配 tls: true 走 HTTPS 伪装。ws 路径、Host、TLS 三者任何一项与服务端不一致都会握手失败。

Trojan

设计上就长得像 HTTPS:password 鉴权,sni 指定 TLS 握手时声明的域名(缺省时用 server 值)。skip-cert-verify: true 会跳过证书校验——只应在明确知道服务端用自签证书时临时使用,长期开启等于放弃了对中间人攻击的防御。

mihomo 扩展协议

mihomo(Clash Meta)内核在原版之上增加了 vless(含 reality 传输)、hysteria2、tuic 等类型,字段结构同样是"通用四件套 + 协议专有段"。订阅里含这些节点时,必须使用 mihomo 内核的客户端(安装包页列出的 Clash Plus、Clash Verge Rev、FlClash 均是),原版内核会因无法识别 type 而拒绝加载整份配置。两代内核的完整差异对照见《mihomo 内核与原版 Clash 差异对照》。

proxies:
  - name: "SS-香港"
    type: ss
    server: hk.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "VMess-日本"
    type: vmess
    server: jp.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws
      headers:
        Host: jp.example.com

  - name: "Trojan-新加坡"
    type: trojan
    server: sg.example.com
    port: 443
    password: "your-password"
    sni: sg.example.com
    udp: true

五、策略组字段:proxy-groups 五种类型

策略组是节点之上的调度层:规则不直接指向某个节点,而是指向一个组,组再按自己的类型决定用哪个节点。组内成员写在 proxies 数组里,可以是节点名、其他组名,也可以是两个内置策略——DIRECT(直连)与 REJECT(拒绝连接,常用来屏蔽域名)。组套组是常规操作,例如"手动选择"组里放一个"自动测速"组,兼得手动与自动。

自动类型的组依赖三个参数:url 是测活地址,惯用返回 204 的轻量端点;interval 是测试周期(秒),300 是常见值,调太小会产生大量探测流量;tolerance(仅 url-test)是切换容差(毫秒)——新旧节点延迟差距超过这个值才切换,避免两个延迟接近的节点来回抖动。lazy: true 让组在被规则实际用到之前不发起测试,节点很多时能明显减少后台请求。load-balance 通过 strategy 选择分配方式,consistent-hashing 让同一目标站点固定走同一节点,对登录态友好;round-robin 则轮流分发。

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - 自动测速
      - SS-香港
      - VMess-日本
      - Trojan-新加坡
      - DIRECT

  - name: "自动测速"
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - SS-香港
      - VMess-日本
      - Trojan-新加坡

  - name: "故障转移"
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - SS-香港
      - VMess-日本

常见报错 "proxy not found" 几乎都出在引用一致性上:组里写的名字与 proxies 段的 name 差一个空格、一对引号或全半角字符,加载即失败。改名时记得全文搜索旧名,把所有引用处一起改掉。

六、providers:订阅节点与外部规则集合

proxy-providers:把节点来源externalize

把节点直接写进 proxies 的问题是:订阅更新一次,整份文件被覆盖一次,你的本地修改随之消失。proxy-providers 把"节点来源"抽出去:type: http 按 interval(秒)周期拉取 url 指向的订阅,缓存到 path;type: file 则读取本地文件。health-check 子段给这批节点配独立的存活检测。策略组通过 use 字段引用 provider,provider 里的全部节点自动注入该组,与 proxies 数组可以同时存在。

rule-providers:规则集合的三种 behavior

rule-providers 是规则版的同一思路,让 rules 段保持短小,大批量域名/IP 交给外部集合维护。关键字段 behavior 有三种取值,决定集合内容的解读方式:domain(纯域名列表)、ipcidr(纯 CIDR 列表)、classical(每行都是完整 Clash 规则)。format 声明文件格式(yaml 或 text),behavior 与集合实际内容不匹配时,规则会整组静默失效——这是"RULE-SET 明明写了却不生效"的头号原因。

proxy-providers:
  main:
    type: http
    url: "https://example.com/sub.yaml"
    path: ./providers/main.yaml
    interval: 86400
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 600

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

proxy-groups:
  - name: "订阅节点"
    type: select
    use:
      - main

订阅本身有多种发行形态——完整 YAML、Base64 节点列表、通用分享链接,并非都能直接喂给 provider。各格式的结构差异与互转方法见《Clash 订阅格式详解》;在客户端里导入订阅的操作步骤见使用文档。更新失败时先看 path 缓存文件是否生成、时间戳是否变化,再看日志里 provider 拉取的 HTTP 状态码,定位比盲目重试快得多。

七、规则语法:自上而下、首条命中

每条规则是逗号分隔的三段式:类型,匹配值,策略,策略可以是节点名、组名、DIRECT 或 REJECT。匹配引擎自上而下扫描,第一条命中即定案,后面的规则不再看——所以顺序就是优先级:精确规则(DOMAIN、PROCESS-NAME)放最前,大范围规则(GEOIP)靠后,MATCH 兜底必须是最后一条,且匹配值留空。

no-resolve 是 IP 类规则的可选第四段,含义是"目标还是域名、尚未解析时,跳过本条,不要为了匹配它专门发起一次 DNS 解析"。给内网网段、保留地址网段的规则统一加上 no-resolve,能避免大量无意义的解析请求。mihomo 内核额外提供 GEOSITE 类型,直接引用按站点分类维护的域名数据库(如 GEOSITE,category-ads-all,REJECT),粒度介于手写规则与 RULE-SET 之间。

rules:
  - PROCESS-NAME,Telegram.exe,手动选择
  - DOMAIN,ad.example.com,REJECT
  - DOMAIN-SUFFIX,github.com,手动选择
  - RULE-SET,cn-domains,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,手动选择

规则排序的四段式模板

规则表写乱最常见的后果是"改了半天没反应"——你新加的那条永远排在一条更宽泛的规则后面,根本轮不到它。稳妥办法是把规则表固定成四段结构:第一段放拦截类规则,广告域名、遥测域名统一 REJECT,放最前面才能保证不被后面的代理规则截走;第二段放本机与内网直连,包括 IP-CIDR,127.0.0.0/8、IP-CIDR,192.168.0.0/16、DOMAIN-SUFFIX,lan 这类条目,全部带 no-resolve;第三段放业务分流,按域名或进程把需要代理的服务指到对应策略组,同时把国内站点指到 DIRECT;第四段是兜底,先 GEOIP,CN,DIRECT 兜住漏网的国内 IP,最后一条 MATCH 把剩余流量交给主策略组。四段之间用注释行分隔,后续增删规则时明确知道该往哪一段插。

还有两个容易踩的细节。一是策略名拼写:规则第三段引用的组名必须与 proxy-groups 里的 name 完全一致,包括中英文标点与空格,写错会直接导致配置加载失败而不是"这条规则不生效"。二是规则数量与性能:纯域名规则的匹配成本极低,几万条也无所谓;真正拖慢连接建立的是需要解析后才能判断的 IP 类规则,把它们尽量往后放并加 no-resolve,再把大批量域名交给 RULE-SET 远程维护,规则表就能长期保持在可读的几十行规模。

八、TUN 模式:虚拟网卡接管全局流量

系统代理只对"尊重代理设置"的应用生效,命令行工具、游戏客户端、部分桌面软件会绕过它直接发包。TUN 模式的解法是创建一块虚拟网卡,把整台设备的出站流量在网络层截下来交给内核处理——应用无感知,规则照常生效。代价是需要更高的系统权限,以及对 DNS 的额外接管。

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

字段逐个说:stack 选择协议栈实现,system 用操作系统原生栈,吞吐好;gvisor 是用户态栈,兼容性场景备用;mixed 二者混合。auto-route 自动写入路由表,把默认路由指向虚拟网卡,关掉就得手工配路由,一般保持 true。auto-detect-interface 自动识别真实物理出口网卡,防止内核自己的出站流量也被虚拟网卡截住形成回环——TUN 开启后彻底断网,九成是这一环出了问题。dns-hijack 把发往任意地址 53 端口的查询劫持给内置 DNS 模块,保证 fake-ip 体系在 TUN 下依然成立。

macOS 的授权流程弯路最多:网络扩展批准入口藏得深,钥匙串弹窗处理不当会反复出现,逐步截图说明见《macOS 安装 Clash 提示权限问题?网络扩展与钥匙串授权全步骤》。另外,mihomo 内核还提供 sniffer 域名嗅探段,在 TUN 场景下从 TLS 握手中还原目标域名,弥补"只有 IP 没有域名"导致的规则漏判,进阶用户可按需开启。

九、覆写与合并:让修改在订阅更新后存活

直接编辑订阅生成的 config.yaml 是最常见的维护陷阱:下一次订阅更新,整份文件被服务端版本覆盖,手工加的规则、改的策略组全部归零。正确姿势是把"订阅原文"与"本地修改"分离,让客户端在加载时合并两者。

YAML 锚点:文件内部去重

先说 YAML 自带的复用语法。&name 定义锚点,*name 引用,<<: 合并键把整个映射展开进来。多个策略组共享同一套测活参数时,锚点能把重复段收敛成一处:

check-common: &check
  url: http://www.gstatic.com/generate_204
  interval: 300

proxy-groups:
  - name: "自动测速"
    type: url-test
    <<: *check
    tolerance: 50
    proxies:
      - SS-香港
      - VMess-日本

  - name: "故障转移"
    type: fallback
    <<: *check
    proxies:
      - SS-香港
      - VMess-日本

锚点只在同一份文件内生效,解决的是"重复",不是"覆盖"。跨文件的合并要靠客户端的覆写机制。

客户端覆写:订阅之上叠一层

主流客户端普遍提供覆写入口,思路一致:订阅原文保持只读,你的修改写在独立的覆写层,每次加载时先取订阅、再叠覆写,更新订阅不会冲掉修改。以 Clash Verge Rev 为例,提供 Merge(声明式合并,常见 prepend-rules / append-rules 语义,把自定义规则插到订阅规则之前或之后)与 Script(用脚本对配置对象做任意加工)两类方式;Clash Plus 等客户端也有各自的覆写编辑入口,操作路径见使用文档对应章节。声明式合并能满足九成需求且不易写坏,优先用它;脚本方式留给"按名称批量过滤节点、动态改组"这类复杂加工。

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,ssh,DIRECT

append-rules:
  - GEOIP,CN,DIRECT

推荐的长期维护结构是三层:订阅负责节点(通过 proxy-provider 或订阅链接引入),规则集合交给 rule-providers 远程维护,个人差异全部写进覆写层。任何一层更新都不影响另外两层,配置从"一次性产物"变成"可持续维护的工程"。做到这一步,本页前八章的字段就都有了各自的归宿。