Clash config.yaml 逐段拆解:端口、dns、proxy-groups 与 rules

先记住配置的处理链：应用把请求交给本地端口，内核按当前模式处理；在规则模式下，rules 决定交给哪个策略，proxy-groups 再决定具体出口。dns 负责名称解析，TUN 则改变流量进入内核的方式。它们有关联，但不是同一个开关。

本文按配置中常见的排列顺序拆解。基础字段适用于 Clash 配置体系；涉及 TUN、DNS 扩展或新协议时，以实际使用的内核为准。Clash Meta 后续使用 mihomo 名称，客户端界面名称与内核名称也可能不同，不能仅凭客户端叫“Clash”就判断所有字段都受支持。

1. 修改前先找对文件与生效入口

config.yaml 不一定就是客户端当前加载的完整配置。图形客户端可能分别保存订阅原文、用户设置、覆写片段和最终运行配置。直接修改运行时生成文件，下次切换订阅或重启时可能被重新生成。

打开客户端的「配置」或「Profiles」页，确认当前启用的条目，而不是只看最近导入的条目。
使用该条目的「编辑」或「打开文件」入口，另存一份修改前的内容。按钮名称随客户端版本变化。
检查客户端是否提供「覆写」「合并」或 Merge 功能。需要长期保留的本地规则，优先通过这些入口添加。
保存后执行「重新加载配置」或重新启用该配置，查看日志是否出现解析错误。

先排除 YAML 语法问题

使用空格缩进，不使用 Tab。本文统一用两个空格表示一层。
键和值之间保留空格，例如 mode: rule，不要写成 mode:rule。
列表项以 - 开头；同层节点、策略组和规则保持对齐。
布尔值写成 true 或 false。含特殊符号的名称、密码和地址建议加引号。

遇到 yaml: line 12: mapping values are not allowed in this context，先检查第 12 行及其上一行的冒号、引号与缩进。此时还没进入网络连接阶段，反复换节点通常没有帮助。

2. 端口与运行模式：请求从哪里进入

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

mixed-port 同时接受 HTTP 代理和 SOCKS5 代理请求。上例中，应用可把代理服务器设为 127.0.0.1、端口设为 7890。这些是示例值，客户端若显示其他端口，以实际运行值为准。

字段	用途	容易混淆的地方
`port`	HTTP 代理监听端口	不是 DNS 端口，也不是节点远端端口。
`socks-port`	SOCKS 代理监听端口	应用必须选择对应代理协议。
`mixed-port`	HTTP 与 SOCKS 共用一个入口	不需要与其他监听项重复绑定同一地址和端口。
`external-controller`	控制接口监听地址	供界面控制内核，不是给浏览器填写的代理入口。

mode: rule 表示按规则分流；global 使用全局策略；direct 走直连。编辑 rules 后却看不到变化，先检查界面是否仍处于「全局」或「直连」模式。

allow-lan: false 用于限制局域网设备接入。确实要给同一网络中的其他设备使用时，还要核对监听地址、系统防火墙与认证设置。不要为了让手机连上代理，就把控制接口直接暴露到公共网络。

log-level: info 适合作为日常排查起点；临时使用 debug 后应及时恢复，日志可能包含访问域名。这里的 ipv6: false 不是关闭操作系统 IPv6，不能替代系统网络设置。

3. dns：监听、上游与 fake-ip 各管什么

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query

enable 开启内核 DNS 模块；listen 决定 DNS 服务监听在哪里。写成 127.0.0.1:1053 只代表本机有这个 DNS 入口，不代表系统已经把所有 DNS 请求发到这里。常规系统 DNS 设置通常不能直接填写 1053 这样的自定义端口，还需要客户端的 DNS 接管、转发或 TUN 配套设置。

default-nameserver 不是普通的备用列表

当 nameserver 使用带域名的加密 DNS 地址时，内核需要先解析这个 DNS 服务器自己的域名。default-nameserver 主要承担这类引导解析；nameserver 才是常规查询使用的上游。把所有地址随意塞入同一个列表，会让故障定位更困难。

fake-ip 返回的是映射地址

fake-ip 模式为域名分配映射地址，帮助内核把连接与域名对应起来。看到 198.18.0.0/16 范围内的地址，不应立即判断成 DNS 污染。这些地址用于内部映射，并不是目标网站的真实公网 IP。

若局域网服务、打印设备或某个应用不兼容，可在已有 dns 段内添加精确的 fake-ip-filter 项。先确认出问题的域名，再按所用内核支持的匹配语法添加。不要直接过滤全部域名，否则会改变整套 DNS 行为。

4. proxies 与 proxy-providers：节点从哪里来

proxies 是直接写在配置里的节点列表。每个节点的 type 决定需要哪些字段，常见字段包括 name、server 和 port，但密码、UUID、TLS 与传输参数必须与服务端对应，不能照着另一种协议的字段硬套。

proxy-providers 则定义节点提供者，可以由远程地址或本地文件提供节点集合。它不是把任意订阅链接放进去就一定能用：提供者文件格式、订阅返回内容和内核支持范围都需要匹配。包含 rules、dns 的完整配置，也不能直接当成纯节点集合使用。

直接定义的节点，通过 proxy-groups 中的 proxies 引用名称。
提供者中的节点，通常通过策略组的 use 引用提供者名称。
名称要完全一致，空格、大小写与符号都算名称的一部分。
订阅地址、密码、UUID 与控制接口密钥不应出现在公开截图或公开日志中。

如果日志提示某个代理不存在，先核对引用关系，再查订阅是否成功更新。删除节点或更改名称之后，旧策略组仍引用原名，也会导致配置无法通过检查。

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

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT
  - name: 默认出口
    type: select
    proxies:
      - 手动选择
      - DIRECT

这段示例只展示引用结构，DIRECT 是内置直连策略，不是代理节点。因此照抄后不会获得远程代理能力。实际使用时，应把配置中已经存在的节点名称或提供者引用加入策略组。

组名「默认出口」可以被规则引用，组内又可以引用「手动选择」。这种层级便于把业务规则与具体节点分开：规则长期指向一个稳定的组名，换节点只在代理页调整组内选择，不必逐条修改规则。

类型	主要行为	配置注意点
`select`	手动选择一个候选出口。	候选可以是节点，也可以是其他策略组。
`url-test`	依据探测结果自动选择出口。	需要合理配置探测 URL、间隔和切换容差。
`fallback`	按候选顺序选择可用出口。	重点是优先级和故障接替，不是挑最低延迟。
`load-balance`	按指定策略分配连接。	不是把多个节点带宽合并给一条下载连接。

自动组显示的探测时间，只能说明对探测目标的当次连接情况，不等于所有网站的访问速度。探测间隔也不是越短越好；例如 interval: 300 表示 300 秒，设置前先确认服务提供方的限制与实际需要。

还要避免循环引用，例如 A 组包含 B 组，B 组又包含 A 组。组名层级看似完整，内核却无法得到一个有效的最终出口。

6. rules：从上往下，首次匹配就结束

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
  - MATCH,默认出口

上例使用保留的示例域名解释语法，不代表真实业务推荐规则。DOMAIN 精确匹配一个域名；DOMAIN-SUFFIX 匹配该域名及其子域名；IP-CIDR 匹配目标 IP 所在网段。第三个字段是处理策略，可以是组名，也可以是 DIRECT、REJECT 等内置策略。

MATCH 必须留在兜底位置

MATCH 接住此前未匹配的请求。如果把它放在第一行，后面的域名与网段规则就没有机会执行。需要新增一个域名直连时，应放到会提前匹配它的宽泛规则之前，而不是机械地追加到文件末尾。

no-resolve 不是关闭全部 DNS

IP-CIDR 后面的 no-resolve 表示不要仅为了判断这条 IP 规则而主动解析域名。若目标 IP 已知，仍可按 IP 匹配。它不会禁止 DNS 模块工作，也不会让依赖域名解析的应用自动恢复连接。

使用 GEOIP 或基于地理数据的规则时，还要检查对应数据文件是否可用、格式是否受内核支持。相关错误可继续参考问题诊断中的 GeoIP 排查。规则集则需要同时核对 rule-providers 的类型、内容格式和 RULE-SET 引用名。

7. TUN 与客户端覆写：文件写对了也要确认接管

TUN 是虚拟网络设备入口，不是另一份代理节点列表。以下是 mihomo 中常见的字段组合，启用前应确认客户端的服务权限、系统路由和其他 VPN 状态。

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

auto-route 用于自动配置路由，auto-detect-interface 用于自动选择出站接口。不同操作系统和内核版本的支持细节存在差异；无法创建虚拟网卡时，先检查客户端的服务模式或授权流程，不要通过随机增删 DNS 地址来处理权限错误。

dns-hijack 的示例针对进入接管路径的传统 53 端口 DNS 流量，并不等于拦截所有加密 DNS。浏览器自带 DoH、其他 VPN 路由和应用自身的网络实现，都可能影响实际路径。

另外，客户端可能用界面设置覆盖文件里的 mixed-port、mode、dns 或 tun。如果保存后数值又变回去，应查看客户端提供的「运行配置」或等效入口，比较最终生效内容与订阅原文。不要连续编辑多个文件，导致无法判断哪一层覆盖了哪一层。

8. 保存后的验证顺序：语法、加载、流量、规则

先检查配置能否解析。使用 mihomo 命令行内核时，可运行下面的检查命令。图形客户端则优先使用自身的配置检查功能。
确认重新加载成功。查看日志是否仍有旧错误，核对监听端口与当前模式。仅保存文件不一定触发重载。
用一个请求验证入口。关闭 TUN 时，可显式指定本地 HTTP 代理测试，避免把系统代理是否开启也混进同一次排查。
观察连接详情。核对目标域名、命中的规则、策略组与最终节点。组名正确但组内选中 DIRECT，仍然会直连。
最后测试持续生效。重新启动客户端，再更新一次订阅，确认覆写仍然保留。若丢失，应修正合并方式，而不是重复手工补写。

# 在配置文件所在目录执行；mihomo 需已加入命令搜索路径
mihomo -t -f config.yaml

# 显式使用本机 7890 端口的 HTTP 代理发起请求
curl -I --proxy http://127.0.0.1:7890 https://example.com

命令行检查应使用与客户端相同版本的内核，并留意相对路径依赖。配置检查通过，只能证明配置可被该内核接受，不保证节点可达、订阅可更新或目标网站可访问。上面的 curl 请求也只验证这一条请求的代理路径，不代表所有应用都已接管。

如果出现 bind: address already in use，先找出占用端口的进程，或把监听端口和应用里的代理端口一起调整。若是节点连接超时，则转向检查节点地址、网络可达性与服务状态，可参考连接超时排查。

安全修改的关键是一次只动一层：先端口与模式，再 DNS，再策略组与规则，最后考虑 TUN 接管。每次保留能工作的版本，出现问题即可回退。需要重新确认订阅启用、模式切换与本地端口，可按入门指南逐项核对。