Clash config.yaml 结构详解:端口、DNS、proxy-groups 与 rules 逐段读懂

1. 先确认配置来源、内核和 YAML 层级

config.yaml 是常见的配置文件名，不是所有客户端都固定使用这个文件。订阅下载后的配置、本地配置、客户端生成的运行配置，可能分别保存在不同位置。编辑之前，先到客户端的配置列表确认当前启用项，再查看实际运行配置；改动一个未启用的文件，不会改变当前连接。

Clash 是一套代理配置体系，Clash Meta 后续使用 mihomo 名称。许多基础字段可以沿用，但协议支持、DNS 选项与 TUN 参数会随内核和版本变化。本文先解释通用结构，再单独标出 mihomo 扩展。客户端界面名称不统一，不能仅凭软件图标判断当前内核。

读 YAML 时先看这三件事

缩进表示归属。本文统一使用 2 个空格，不使用 Tab。顶层的 dns、proxies、rules 左侧对齐。
冒号分隔键和值。写成 mode: rule，不要使用中文冒号。行首的 - 表示列表项。
名称是引用关系。规则写了哪个策略组，那个组就必须存在；组内引用的节点或其他组也必须能找到。

2. 端口与模式：先决定流量怎样进入内核

文件上方通常是监听端口、运行模式和日志级别。端口负责接收请求，模式负责决定请求进入后怎样选择出口。这是两个独立环节：即使规则正确，应用没有把流量交给客户端，也不会产生预期的代理连接。

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

字段	示例含义	检查重点
`mixed-port`	7890 同时接收 HTTP 和 SOCKS 代理请求	应用填写的端口必须一致，且未被其他进程占用
`allow-lan`	false 表示不允许其他局域网设备接入	共享时还要核对监听地址与防火墙
`mode`	rule 按规则列表匹配连接	全局模式不能用来验证 rules 的命中顺序
`log-level`	info 输出常规运行信息	临时排错可改 debug，完成后恢复
`ipv6`	false 关闭内核相应的 IPv6 支持	不等于关闭操作系统所有 IPv6 流量

mixed-port、port 和 socks-port 怎么选？

port 是 HTTP 代理端口，socks-port 是 SOCKS 代理端口；需要统一入口时可以使用 mixed-port。例如应用填写 HTTP 代理 127.0.0.1:7890，内核就应在 7890 接收对应请求。不同监听项不要占用相同的地址和端口。

mode: rule 使用规则分流；global 使用全局策略；direct 则直连。切换模式不会自动修改浏览器的系统代理设置。初次验证建议先使用系统代理，把 TUN 留到基础连通后再开启，避免同时排查多个入口。

如果看到 external-controller: 127.0.0.1:9090，它通常是控制 API 的监听地址，不是上网代理端口。不要把 9090 填进浏览器代理设置，也不要为图方便将控制接口暴露到公网。

3. dns：区分解析服务器、监听地址与 fake-ip

dns 决定内核如何处理交给它的域名解析请求。下面使用 redir-host 解释基础结构；两个 IP 是示例解析服务器，不代表适用于所有网络。使用前应确认所在网络能访问它们，并考虑 DNS 请求的隐私需求。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enable: true 启用内核 DNS 功能，但不会自动把整个系统的 DNS 请求全部导入内核。
listen 指定本地 DNS 监听地址。示例使用 1053，不是系统常用的 53；没有额外转发设置时，系统不会自动查询这个端口。
nameserver 是上游解析服务器列表。传统 DNS 通常使用 53 端口，DoH 和 DoT 则使用对应协议地址。
dns.ipv6: false 控制该 DNS 模块对 AAAA 查询的处理，不是操作系统级的 IPv6 防火墙。

fake-ip 为什么会返回 198.18 开头的地址？

enhanced-mode: fake-ip 会为域名分配映射地址，内核再把连接与原域名对应起来。配置中常见的 fake-ip-range: 198.18.0.1/16 属于这种映射用途，并不是网站服务器的实际公网地址。因此，看到这个网段不能直接判断 DNS 被污染。

部分局域网服务、设备发现或依赖真实解析地址的程序可能需要例外。可以按实际问题设置 fake-ip-filter，不要一次添加大量宽泛域名。使用 redir-host 与 fake-ip 时的行为不同，切换后应新建连接再测试。

mihomo 的节点域名解析要单独留意

代理服务器本身也可能使用域名。mihomo 提供 proxy-server-nameserver 等字段，用来安排节点域名的解析；上游 DoH 地址本身是域名时，还可能涉及 default-nameserver 的引导解析。若解析节点域名依赖代理，而建立代理又依赖该域名，就会形成循环依赖。遇到启动后所有节点都超时，应先查日志中的域名解析错误，而不是只改规则。

4. proxies：节点参数不等于订阅链接

proxies 是节点定义列表。每个节点通常有 name、type、server、port，其余认证和传输参数取决于协议。节点名称供策略组引用；服务器端口则是远端服务端口，不要与本机的 7890 混淆。

本文不编造服务器地址与密码。理解结构时可以使用 proxies: [] 表示空节点列表，再让策略组暂时引用内置的 DIRECT。这个配置可以演示直连分流，却不会凭空提供代理服务。要实际代理，需要加入服务提供方交付、且当前内核支持的节点参数。

订阅地址应该放在哪里？

完整配置订阅：在客户端的订阅或配置页面导入。返回内容可能已经包含节点、策略组和规则。
节点集合订阅：可由支持的 proxy-providers 机制读取，再由策略组通过 use 引用。
单个节点分享链接：需要客户端识别或转换，不能当作 YAML 节点对象直接粘进 proxies。

普通网页、登录页、过期提示页都不是节点列表。如果导入后出现解析错误，应先确认响应内容，而不是反复调整缩进。还要区分完整配置与 provider 所需的节点集合格式：扩展名同为 YAML，不表示内部结构可以互换。

采用 proxy-providers 时，常见的 interval: 3600 表示每 3600 秒更新资源；策略组健康检查里的 interval: 300 表示每 300 秒检测一次。两者用途不同，都不是延迟阈值，也不能替代客户端对完整订阅的更新设置。

5. proxy-groups：把节点组织成可选择的出口

规则通常指向策略组，再由策略组选择节点或其他出口。这样更换节点时，不必逐条修改规则。下面的组名是“出站选择”，它只包含内置直连出口，适合检查引用关系。

proxies: []

proxy-groups:
  - name: 出站选择
    type: select
    proxies:
      - DIRECT

三类常见策略组的区别

类型	选择方式	使用注意
`select`	用户手动选择组内出口	适合先固定节点，排查规则和连通性
`url-test`	按测试结果自动选择低延迟出口	测试 URL 的响应时间不等于下载速度
`fallback`	按列表顺序选用可用出口	优先顺序来自列表，不是按最低延迟排序

url-test 和 fallback 通常还需要测试地址、检测间隔等参数。测试地址必须在当前环境可达；如果测试站点故障，多个正常节点也可能同时显示不可用。不要只凭一次延迟测试就删除节点。

组名和节点名要保持唯一、清楚。假设规则引用“出站选择”，改名为“代理出口”后就要同步修改规则。组与组可以形成层级，但不能 A 引用 B、B 又引用 A；循环引用会使出口选择无法正确完成。

6. rules：从上到下匹配，MATCH 放最后

在规则模式下，连接通常按列表顺序匹配，首条命中的规则决定策略。它不是“越具体的规则自动优先”：如果宽泛规则写在前面，后面的精确规则可能根本不会执行。先安排明确例外，再安排范围规则，最后放兜底，是较容易检查的顺序。

rules:
  - DOMAIN,example.com,出站选择
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,出站选择

DOMAIN 精确匹配域名。示例只匹配 example.com，不自动涵盖它的全部子域名。
DOMAIN-SUFFIX 匹配该域名及其子域名。示例涵盖 example.org 和 www.example.org。
IP-CIDR 匹配目标 IP 网段。示例列出三个常见私有 IPv4 地址段，并非所有特殊用途地址的完整清单。
no-resolve 表示不要仅为了匹配这条 IP 规则而主动解析域名，不是关闭整条连接的 DNS。
MATCH 作为兜底接收此前未命中的连接，应放在列表末尾。

GEOIP、RULE-SET 与规则提供者

GEOIP,CN,DIRECT 根据 IP 地理数据库匹配，不是按域名文字判断归属。数据库缺失、更新失败或解析得到不同地区的 IP，都会影响结果。遇到数据库错误，可到疑难手册的 GEOIP 检查项继续排查。

RULE-SET 引用在 rule-providers 中定义的规则集合，与存放节点的 proxy-providers 不是一回事。使用前要核对规则集合的格式、行为类型与当前内核支持情况。导入某个集合后，也要在 rules 中添加引用，定义资源本身不代表它已经参与匹配。

7. 合成最小配置，再逐步加入 TUN 和订阅节点

下面把前面的基础字段组合成一个本地学习配置。它不包含代理服务器，所有出口最终都直连；用途是验证 YAML 层级、端口监听和策略引用。若客户端会自动覆写端口或 DNS，应以运行配置和日志为准。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

proxies: []

proxy-groups:
  - name: 出站选择
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN,example.com,出站选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出站选择

为什么没有直接加入 TUN？

TUN 是另一种流量入口，不是一个代理节点，也不是让规则自动变正确的开关。mihomo 常见的配置项包括 tun.enable、stack、auto-route 和 dns-hijack，但实际效果还依赖操作系统、服务权限、网卡及路由环境。不能把一段平台不明的 TUN 配置复制到所有设备上。

建议先完成“应用代理 → 7890 → 规则 → 出口”的验证，再通过客户端支持的方式开启 TUN。若开启后断网，优先核对路由、DNS 接管与其他 VPN 冲突，而不是立即重写 proxies。基础接管步骤可参考入门指南的 TUN 模式说明。

8. 保存后不生效：按语法、引用、运行状态排查

确认编辑的是启用项。查看配置列表中的当前项目和更新时间，再执行重新加载。客户端可能保存了多个同名文件。
检查语法报错行。遇到 yaml: line 相关提示，既要检查该行，也要检查上一行的冒号、引号、列表符号和缩进。含特殊字符的密码应按 YAML 字符串规则加引号。
检查同名顶层键。不要在文件末尾再追加第二个 dns: 或 rules:。重复键可能被拒绝，也可能发生覆盖，取决于解析方式。
检查出口引用。提示代理或策略不存在时，逐字对照组名、节点名和大小写。YAML 能解析，不代表引用关系正确。
检查监听与入口。出现 address already in use 时，排查 7890 或 DNS 监听端口的占用；不要把修改系统代理地址当作解决端口冲突。
检查实际命中。确认运行在 rule 模式，用新连接查看规则详情。若应用绕过系统代理，则先处理入口或按需使用 TUN。

可使用内核自带的配置测试

能够直接使用 mihomo 命令行时，可在配置所在目录执行以下命令。配置测试可能还需要读取外部资源与数据库，因此应使用与实际运行相同的工作目录和资源环境。

mihomo -t -f config.yaml

测试通过表示内核接受了这份配置，不表示节点凭据有效、所有上游都可访问或网站一定走了预期出口。下一步仍要检查连接日志。排障时只改一个环节，记录改动前后的错误信息，通常比同时切换 DNS、规则和 TUN 更容易定位。

读懂配置的关键，是沿着“入口端口 → 域名解析 → 规则命中 → 策略组 → 最终出口”逐层核对。需要补充规则排错方法时，可查看config.yaml 配置检查；准备更换客户端时，先确认新客户端采用的内核及其字段支持范围，再迁移配置。