Clash config.yaml 逐段拆解:从端口设置到 rules 的阅读顺序

先确认内核与配置来源

config.yaml 是交给代理内核读取的配置文本。内核负责建立连接与执行分流；客户端则提供导入、切换配置和查看日志的界面。同一款客户端可能在加载前合并端口、覆写规则等设置，所以编辑的文件不一定就是最终生效的全部内容。

本文以 mihomo，也就是原 Clash Meta 内核的常见字段为主。传统 Clash 与 mihomo 有共同语法，但并非所有功能都能互换，尤其是 TUN、DNS 和较新的代理协议。先在客户端的「关于」或内核信息页确认内核名称与版本，再对照对应文档，不要仅凭窗口上写着 Clash 就判断兼容性。

阅读时抓住三条线

• 入口：端口和 TUN 决定流量怎样进入内核。
• 出口：proxies 定义连接，proxy-groups 把连接组织成可选择的策略组。
• 分流：rules 根据域名、IP 等条件，把连接交给某个策略组或内置动作。

文件上下顺序主要是方便阅读。顶层的 rules 不必因为引用策略组就紧挨着策略组；真正重要的是名字匹配、字段层级正确，以及规则列表内部的先后顺序。

一份可检查结构的完整 config.yaml

下面是一份用于阅读和本地测试的 mihomo 配置。它没有远程代理节点，所有正常放行的连接都走直连，不能用来验证远程代理是否可用。这样安排，是为了先把端口、DNS、策略组和规则的关系看清楚，而不是混入无法连接的演示服务器。

# 本机代理入口
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1

# 工作方式与日志
mode: rule
log-level: info
ipv6: false

# 本地 DNS 服务
dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

# 暂不启用虚拟网卡接管
tun:
  enable: false

# 远程代理节点列表为空
proxies: []

# 策略组引用内置直连动作
proxy-groups:
  - name: "出口选择"
    type: select
    proxies:
      - DIRECT

# 从上到下匹配，最后一条兜底
rules:
  - DOMAIN-SUFFIX,example.com,出口选择
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口选择

example.com 是保留的示例域名，这里只用于展示域名规则。两台 DNS 服务器是具体的公共解析服务，不代表在每个网络里都能访问。加载前也要确认本机的 7890 和 1053 没有被其他程序占用。

YAML 先看缩进，再看字段

YAML 用缩进表示“属于谁”。示例统一用两个空格，避免使用 Tab。dns: 顶格写，enable: 比它多缩进一级，就表示后者属于 DNS 配置。列表中的 - 表示一项；[] 表示空列表。

• 冒号后通常要留一个空格，例如 mode: rule。
• 同一级字段保持相同缩进，不要把顶层的 rules: 缩到策略组里面。
• 字符串含 # 等特殊字符时应加引号，防止后半段被当作注释。
• 同一层不要重复定义 dns 或 rules；不同解析器可能拒绝重复键，或只保留其中一份。

端口与模式：先让应用接到正确入口

mixed-port: 7890 表示在同一个端口接受 HTTP 代理和 SOCKS5 代理连接。应用手动设置代理时，地址填写 127.0.0.1，端口填写 7890，协议则按应用提供的选项选择。这个数字是本文示例值，不是所有客户端的固定默认值。

mode: rule 才是本文讨论的规则模式。全局模式通常把流量交给全局策略，直连模式则直接连接；这两种模式下，修改普通规则不会得到预期效果。客户端界面如果覆写了模式，最终仍要以实际运行状态为准。

log-level: info 适合日常观察。需要定位问题时可以短暂使用 debug，复现后再改回去；详细日志可能包含访问域名等信息，分享之前应清理敏感内容。

DNS 与 TUN：解析域名和接管流量分开看

DNS 是把域名查成 IP 地址的过程。示例启用内核的 DNS 服务，并监听 127.0.0.1:1053；这不等于操作系统的所有 DNS 请求已经自动转交给它。系统设置、客户端集成方式和 TUN 接管都会影响实际路径。

nameserver 与解析模式

nameserver 是用于解析的上游服务器列表。示例中的裸 IP 使用普通 DNS，不提供加密传输；如果需要 DoH，也就是通过 HTTPS 传输 DNS 查询，应按当前内核支持的写法配置服务地址，并确认它的连接路径和启动解析需求。

enhanced-mode: redir-host 在解析时返回真实地址。另一种常见模式 fake-ip 会给应用返回映射用的虚拟地址，内核再将它关联回域名；两者不是“速度档位”。切换模式后，旧 DNS 缓存和存量连接可能影响观察，必要时清理缓存并重启相关应用。

TUN 不是另一份代理节点

TUN 是虚拟网络接口，用来接收系统路由导入的流量。示例仅写 tun.enable: false，因此没有开启这条接管路径。打开系统代理也不等于打开 TUN：前者主要影响遵循系统代理设置的应用，后者能在正确路由和权限条件下接收更多流量。

• 先用应用手动代理验证 127.0.0.1:7890，再测试系统代理，最后才考虑 TUN。
• 需要 TUN 时，按客户端与操作系统的要求处理管理员权限、虚拟接口和路由。
• dns-hijack 用于接管匹配的 DNS 流量，但不是对所有加密 DNS 都能生效；应用自带的 DoH 可能另走连接。
• 示例关闭 IPv6 是为了缩小排查范围，不应被当作适合所有网络的永久设置。

proxies 与策略组：沿名称追踪出口

proxies 是具体代理连接的列表。真实节点通常包含名称、协议类型、服务器、端口及认证参数，不同协议还会有各自字段。服务端地址和密码必须来自实际服务配置，不能把其他协议的字段拼在一起凑成节点。

本例的 proxies: [] 明确表示没有远程节点。策略组中的 DIRECT 是内核内置的直连动作，不需要在节点列表中再声明。类似地，REJECT 是拒绝连接的内置动作。

select 只负责选择，不负责测速

proxy-groups 把一个或多个出口组织成组。示例的 type: select 表示手动选择，组名是“出口选择”。以后加入真实节点时，要把节点的准确名称加入该组的 proxies 列表，才能在这个组里选到它。

rules 中的“出口选择”
        ↓ 名称必须一致
proxy-groups 中 name 为“出口选择”的组
        ↓ 当前选中项
DIRECT，也就是直接连接目标

url-test 才是按测试结果选择出口的一类策略组；它需要合理的测试地址与间隔。测试延迟只是到特定目标的观测值，不代表下载带宽，也不保证所有站点都能打开。

订阅中还可能出现 proxy-providers，它表示从文件或远程来源加载节点集合。策略组通常通过 use 引用提供器名称，而不是把提供器名称当成单个节点塞入 proxies。读到这类配置时，要继续检查来源、更新路径和健康检查设置。

rules：从第一条读到 MATCH

规则通常按列表顺序匹配，先命中的规则决定去向。因此，具体条件放前面，宽泛条件放后面，最终兜底放最后。把 MATCH 放在第一条，后面的普通规则就没有机会处理新连接。

域名规则与 IP 规则不要混读

DOMAIN 用于精确域名，DOMAIN-SUFFIX 用于域名及子域名。规则里填域名，不填完整网址；例如 https://example.com/path 含协议和路径，不能直接当成域名条件使用。

IP-CIDR 中的 CIDR 是用前缀长度描述 IP 范围的写法。末尾的 no-resolve 表示不要为了检查这条 IP 规则主动触发域名解析；如果连接元数据已有目标 IP，仍可据此匹配。它不是“禁用整个 DNS”的开关。

示例只列出部分常见本地网段，并非完整的特殊地址策略。若访问打印机、路由器或企业内网失败，应查看实际目标地址和规则命中记录，不要假设所有内网都只在 192.168.0.0/16。

遇到 RULE-SET 再追到规则提供器

RULE-SET 引用的是 rule-providers 中定义的规则集合，不是代理节点集合。需要同时核对提供器名称、来源、格式与 behavior 类型；下载成功只说明拿到了内容，不代表内容格式一定适合当前配置。

加载前检查与生效验证

配置能通过语法检查，不等于网络已经按预期工作。建议把验证拆成“能读取、能监听、能匹配、能连接”四步，每次只改一处，出错时才容易回到上一个可用状态。

1. 检查文件。将测试副本保存为 UTF-8 编码的 config.yaml，确认扩展名没有变成 .yaml.txt。检查缩进、重复键和策略名称。
2. 验证内核配置。使用客户端提供的检查入口；也可在装有 mihomo 命令行程序的环境中执行下方测试命令。Windows 当前目录的程序通常需要写成 .\mihomo.exe。
3. 加载并查看日志。确认没有语法错误、找不到策略或端口占用提示。若客户端重写配置，还要查看其实际生成的配置内容。
4. 通过明确入口发起请求。先显式指定代理端口，排除系统代理开关和浏览器设置造成的干扰。
5. 核对连接记录。检查测试连接的命中规则、策略组与最终出口，再逐步启用原来的 DNS 或 TUN 设置。

# 检查配置；此命令不会正常启动长期运行的代理服务
mihomo -t -f ./config.yaml

# 配置已加载且内核运行后，测试本机 HTTP 代理入口
curl --proxy http://127.0.0.1:7890 --head https://example.com

第二条命令测试的是本机代理入口到示例站点的链路；本例最终使用 DIRECT，即使请求成功，也不能证明远程代理节点有效。Windows 上若 curl 被终端解释为其他命令，可明确使用已安装的 curl.exe。

后续维护继续沿用同一阅读顺序：入口参数、运行模式、DNS、流量接管、节点、策略组、规则。需要更细的字段解释时，可对照本站的 YAML 手册；从导入到启用的操作流程则放在 使用文档。保留一份已验证的配置，比每次出错后从头重写更省事。