2026-07-18 进阶技巧 预计阅读 9 分钟

Clash 配置文件结构逐段拆解:从 port、dns 到 rules 每个区块都在做什么

按配置文件从上到下的顺序逐段解析通用字段、proxies、proxy-groups 与 rules 的职责边界,配最小可用示例说明各区块之间如何协作。

配置文件整体结构概览

一份 Clash 配置文件本质是一份 YAML 文档,自上而下大致分成四类内容:全局运行参数、节点定义、策略组定义、分流规则。这四类内容彼此独立又相互引用——节点被策略组引用,策略组被规则引用,规则决定流量最终走哪条路径。理解这条引用链,比死记某个字段的取值范围更有用,因为遇到配置报错或分流不生效时,排查思路都是沿着这条链往回找。

Clash Meta(即 mihomo)在原版 Clash 的字段基础上做了扩展,增加了 TUN 模式、DNS 嗅探、地理位置数据库路径等配置项,但核心四段结构没有变化。本文以 Meta 内核的字段范围为准,原版字段是其子集,直接读也不会遇到理解障碍。

通用字段:port、mode、log-level、dns

文件最上方通常是一组独立的键值对,负责客户端本身的运行方式,不涉及任何具体节点。

  • port / socks-port:分别开启 HTTP 代理端口和 SOCKS5 代理端口,系统或应用软件按需选择其中一个连接。
  • mixed-port:单个端口同时接受 HTTP 与 SOCKS5 请求,大多数客户端默认只暴露这一个端口,减少配置项。
  • allow-lan:是否允许局域网内其他设备通过本机代理,配合 bind-address 控制监听范围。
  • mode:取值 rule(按规则分流,常规使用方式)、global(全部走同一节点,排障时用)、direct(全部直连,临时关闭代理时用)。
  • log-level:控制日志详细程度,排查问题时常临时改成 debug,日常使用建议 info 或 warning,避免日志文件无限增长。

dns 区块单独成段,决定域名解析走什么路径。这是很多分流"看起来生效但实际没生效"问题的根源——如果 DNS 解析阶段就把域名解析成了错误的 IP,后面规则再怎么写都救不回来。一个基础可用的 dns 段大致如下:

config.yaml · dns 片段 
dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://doh.pub/dns-query
  fake-ip-range: 198.18.0.1/16
  use-hosts: true

fake-ip-range 是 Meta 内核的常见配置,配合 TUN 模式使用,给域名分配一个假的本地 IP 段,由内核在流量层面完成真正的解析与转发,避免直接依赖系统 DNS 造成的污染问题。这部分展开讲会牵扯 TUN 模式的完整链路,不是本文重点,这里只需要知道 dns 段和 rules 段是两条独立又互相影响的流水线。

proxies:节点定义

proxies 是一个列表,列表里每一项描述一个具体的代理节点。不同协议字段略有差异,但都遵循相同的结构:name 是节点在后续引用中使用的唯一标识,type 决定协议(如 ss、vmess、trojan、hysteria2),其余字段是该协议特有的连接参数。

config.yaml · proxies 片段 
proxies:
  - name: "HK-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
  - name: "SG-01"
    type: vmess
    server: sg01.example.com
    port: 443
    uuid: 0000-uuid-example
    alterId: 0
    cipher: auto

这里最容易忽略的一点是:name 只是字符串标识,客户端不会检查它和真实节点地理位置是否一致,写错标签不会报错,只会导致后续策略组里挑选节点时产生误解。机场提供的订阅链接本质上就是生成一份完整的 proxies 列表,订阅转换服务做的事情,就是把不同格式的节点信息统一转换成这种结构。

proxy-groups:策略组

proxy-groups 也是一个列表,但每一项定义的不是节点,而是"如何从若干节点或策略组里选出一个"。策略组的 proxies 字段里可以填节点名,也可以填另一个策略组的名字,这种嵌套是构建多层分流(比如"自动选择"套一层"手动选择")的基础。

  • select:手动选择,客户端界面上显示为一个可点击切换的列表,适合需要手动挑节点的场景。
  • url-test:按延迟自动选择,客户端定期用配置的 URL 测速,自动切到延迟最低的节点。
  • fallback:故障转移,按列表顺序依次尝试,当前节点不可用时自动切到下一个。
  • load-balance:多节点负载均衡,按策略(如一致性哈希)把不同连接分散到多个节点。
config.yaml · proxy-groups 片段 
proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies:
      - HK-01
      - SG-01
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "节点选择"
    type: select
    proxies:
      - 自动选择
      - HK-01
      - SG-01
      - DIRECT

注意最后一个策略组里出现的 DIRECT 和 REJECT,这是两个内置的特殊标识,不需要在 proxies 里定义:DIRECT 表示直连不走代理,REJECT 表示直接拒绝连接。它们可以出现在任何策略组的候选列表里,也可以直接出现在 rules 段作为目标策略,这是很多人容易忽略的一个细节。

rules:分流规则

rules 段决定每一条网络请求最终交给哪个策略组处理,是整份配置里逐行匹配、按顺序生效的部分——写在前面的规则优先级更高,一旦某条规则命中,后面的规则不再检查。规则的基本格式是"匹配类型,匹配内容,目标策略",常见匹配类型包括:

  • DOMAIN-SUFFIX:按域名后缀匹配,覆盖某个域名及其所有子域名。
  • DOMAIN-KEYWORD:域名包含指定关键词即匹配,匹配范围比后缀更宽,容易误伤。
  • IP-CIDR / IP-CIDR6:按 IP 段匹配,常用于国内 IP 段直连。
  • GEOIP:按 IP 所属地理位置匹配,依赖本地的 GeoIP 数据库。
  • MATCH:兜底规则,放在最后一条,匹配所有未被前面规则命中的流量。
config.yaml · rules 片段 
rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-KEYWORD,google,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

规则里的第三段填的是策略组名字(或 DIRECT/REJECT),不能直接填节点名——这是初学者最常踩的坑之一。如果在 rules 里写了一个只在 proxies 里存在、没有出现在任何策略组的名字,客户端加载配置时会直接报错。想快速定位某条规则是否生效,可以把 log-level 临时调到 debug,日志里会打印每条请求匹配到的具体规则。

规则数量越多,逐条匹配的开销越大。用 GEOIP,CN,DIRECT 或规则集(rule-providers)代替成百上千行手写域名规则,既方便维护也能减少配置文件体积。

最小可用示例:四段如何拼在一起

把前面四段按顺序拼接起来,就是一份可以直接运行的最小配置。它没有覆盖所有场景,但足够说明各区块的协作关系——dns 决定域名怎么解析,proxies 提供可用节点,proxy-groups 把节点组织成可切换的策略,rules 把具体流量分配给某个策略组。

config.yaml · 最小示例 
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  nameserver:
    - https://doh.pub/dns-query

proxies:
  - name: "HK-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - HK-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

把这份配置放进任意一个 Clash Meta 内核客户端,替换掉服务器地址和密码就能直接运行。绝大多数机场提供的完整配置或订阅链接,展开后本质上都是这四段内容的扩展版本——策略组数量更多、规则条数更长、可能额外接入了规则集和分组测速地址,但骨架不会变。

常见排查思路

配置文件报错或分流异常,基本可以按以下顺序检查:

  1. YAML 语法层面

    缩进是否统一(禁止混用 Tab 和空格),冒号后是否留了空格,含特殊字符的密码是否用引号包住。多数客户端加载失败时会在日志里指出具体行号。

  2. 引用是否存在

    检查 rules 里的目标策略组名字、proxy-groups 里引用的节点名字,是否在对应区块里真实存在,拼写要完全一致,包括大小写。

  3. 规则顺序是否合理

    确认没有把宽泛匹配的规则(如某个 DOMAIN-KEYWORD)放在精确规则前面,导致后面更具体的规则永远匹配不到。

  4. DNS 是否单独测试

    把 mode 临时切到 global,排除是分流规则的问题还是 DNS 解析阶段的问题,再逐段缩小排查范围。

获取 Clash 客户端

拿到配置文件结构之后,先安装一个支持 Meta 内核的客户端再动手改配置更省心。

前往下载页 配置教程
下载客户端