config.yaml 逐段拆解:端口、dns、proxies、proxy-groups 与 rules 各管什么

1. 配置文件结构与实际生效顺序

config.yaml 描述的是连接入口、域名解析、可用出口以及出口选择规则。阅读时可以沿着“应用流量 → 本地端口或 TUN → 规则匹配 → 策略组 → 节点或直连”的方向理解。DNS 为其中的域名解析提供支持，但并不是所有连接都严格先经过同一条 DNS 路径。

本文按常见文件排列顺序讲解。YAML 顶层字段通常可以调整位置，dns 写在 rules 前面不代表它比规则拥有更高优先级；真正依赖先后顺序的是 rules 内的规则列表。协议支持和部分字段则取决于内核，传统 Clash 与 Clash Meta（现名 mihomo）的配置能力并不完全相同。

顶层映射：dns:、proxies: 等字段从行首开始。
嵌套缩进：建议每层使用 2 个空格，不用 Tab；列表项前保留 - 。
名称引用：策略组名和节点名按字符串精确匹配，大小写与空格都要一致。
客户端加工：订阅、覆写、合并脚本与界面开关可能共同生成运行配置，编辑磁盘上的某一份 YAML 不一定立即改变内核行为。

2. 端口、运行模式与控制接口

端口字段定义的是客户端在本机接收连接的位置，不是远端节点的服务器端口。下面以混合代理入口 7890 为例；这些数字是本文示例值，实际应以运行配置和端口占用情况为准。

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

字段	作用	使用要点
`port`	HTTP 代理入口	支持 HTTP 代理及 CONNECT 隧道，不是网页服务端口。
`socks-port`	SOCKS 代理入口	应用需要显式选择 SOCKS 代理类型。
`mixed-port`	共用 HTTP 与 SOCKS 入口	同一监听端口接受两类代理连接，配置应用时仍需选对协议。
`allow-lan`	是否允许局域网接入	局域网共享还取决于监听地址、系统防火墙及访问认证。
`mode`	运行模式	`rule` 按规则选择出口，`global` 使用全局策略，`direct` 采用直连。
`external-controller`	管理 API 监听地址	用于查询状态和切换策略，不作为应用的代理入口。

7890 与 9090 为什么不能混用

如果运行配置将 mixed-port 设为 7890，浏览器手动代理应填写主机 127.0.0.1、端口 7890。若另有 external-controller: 127.0.0.1:9090，这里的 9090 是管理 API，填进浏览器代理设置会导致连接失败。

管理接口应优先绑定回环地址，并设置独立的 secret。开启局域网代理时也不要顺手把管理接口暴露到所有网卡。系统代理开关通常由客户端界面管理，单独修改 mixed-port 不能保证所有应用自动改用新端口。

3. dns：解析服务器、监听地址与 Fake-IP

dns 段管理内核的 DNS 功能。enable 控制启用状态，listen 定义 DNS 监听地址，nameserver 指定上游解析服务器。DNS 的监听端口与 HTTP、SOCKS 端口属于不同服务，不能把代理端口当成 DNS 服务器端口使用。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

这个示例在回环地址的 1053 端口提供 DNS 服务，所列 IP 上游使用普通 DNS，并不代表加密解析。仅启动该监听并不会自动修改操作系统 DNS；应用、系统解析链路或 TUN 的 DNS 劫持需要另行接入。

Fake-IP 返回地址不等于真实服务器地址

fake-ip 模式会从配置的地址段中分配合成地址，内核保存其与域名的对应关系，以便后续连接按域名处理。看到 198.18. 开头的解析结果时，应先确认连接是否仍由内核接管，不能直接把它判断为远端网站的真实 IP。

应用兼容问题：某些设备发现、游戏或依赖真实解析结果的应用需要针对性检查 fake-ip-filter，不要一开始就加入大范围通配项。
上游可达性：先确认当前网络能够访问所选 DNS。新增加密 DNS 时还要考虑服务器域名的引导解析。
进阶字段：mihomo 的 respect-rules、proxy-server-nameserver 等字段有各自的路由和解析用途，应按实际内核文档配置，避免把 DNS 请求的出站策略与普通业务规则混为一谈。

排查时可以在支持指定端口的环境中执行 dig @127.0.0.1 -p 1053 example.com，观察是否有响应。该命令只检查指定 DNS 监听是否应答，不能单独证明系统流量已经接管或节点能够连接。

4. proxies：节点定义与协议参数

proxies 是节点对象列表。每个对象通常包含 name、type、server 和 port，其余字段由协议决定。比如 Shadowsocks 使用 cipher、password，其他协议可能需要 UUID、TLS 或传输层参数，不能只改 type 就完成协议转换。

proxies:
  - name: "本机测试节点"
    type: ss
    server: 127.0.0.1
    port: 8388
    cipher: aes-128-gcm
    password: "local-demo-only"

节点名称与服务器地址分开看

name 是供策略组引用和界面展示的标识；server 才是连接目标。把“本机测试节点”改名之后，引用它的策略组也必须同步修改。节点中的 port: 8388 指向服务端，与本地入口 mixed-port: 7890 没有数值对应关系。

含冒号、井号或容易被解释成布尔值的字符串建议加引号。凭据字段也应作为字符串处理。分享配置或日志时，隐藏密码、令牌和完整订阅 URL；仅改掉节点显示名称并不能移除这些敏感信息。

5. proxy-groups：规则与节点之间的策略层

proxy-groups 把节点或其他策略组组织成可引用的出口。规则通常指向一个稳定的组名，订阅更新时则替换组内节点。这样可以把“哪些流量走这里”和“这里当前选哪个节点”分开维护。

proxy-groups:
  - name: "手动出口"
    type: select
    proxies:
      - "本机测试节点"
      - DIRECT

select：由用户或管理 API 选择成员，适合明确指定出口。
url-test：根据探测结果自动选择成员；探测 URL、间隔和容差会影响选择，结果不等同于实际下载带宽。
fallback：按列表顺序选用可用成员，适合主备切换，而不是按最低延迟排序。
load-balance：按支持的分配策略为连接选择成员，不会把一条普通连接自动合并成多节点带宽。

上面的列表引用了上一节定义的“本机测试节点”，以及内置出口 DIRECT。删除该节点却保留引用，会产生配置错误。组可以引用其他组，但要避免形成循环依赖，例如 A 引用 B、B 又引用 A。

订阅节点不一定直接写在 proxies 里

使用 proxy-providers 的配置可以从提供器载入节点，策略组通过 use 引用提供器名称。因此，看到顶层 proxies: [] 不能立即断言没有节点。应同时检查提供器是否加载成功、组中是否配置 use，以及界面是否施加了筛选条件。

6. rules：从上到下匹配，命中后选择出口

在 mode: rule 下，内核按列表顺序判断规则，命中后使用规则指定的策略。常见结构是“规则类型、匹配内容、目标出口”；MATCH 不需要匹配内容，通常放在最后承接尚未命中的连接。

rules:
  - DOMAIN,example.com,手动出口
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手动出口

规则	匹配范围	检查重点
`DOMAIN`	精确域名	`example.com` 不自动包含其子域名。
`DOMAIN-SUFFIX`	域名及其子域名	`example.org` 可覆盖 `www.example.org`。
`IP-CIDR`	目标 IPv4 网段	`no-resolve` 阻止仅为该规则主动解析域名，不会关闭全部 DNS。
`RULE-SET`	引用规则提供器	需要存在对应的 `rule-providers` 定义及可用规则内容。
`MATCH`	剩余连接	放在前面会截断后续规则的匹配机会。

“局域网直连”不能只靠示例中的 192.168.0.0/16 覆盖所有环境；实际网络还可能使用 10.0.0.0/8、172.16.0.0/12 或 IPv6 地址。应依据本地网段和服务发现方式补充规则，而不是把示例当作完整规则库。

若把 MATCH,手动出口 移到第一行，后面的域名规则便不会被执行。排查“规则写了但没有生效”时，先确认当前为规则模式，再检查更靠前的规则和客户端追加的覆写内容，最后查看连接记录中的命中规则与实际出口。

7. 完整最小示例与 TUN 的边界

下面是一份用于核对结构的最小配置：开启混合端口、内核 DNS 和规则模式，保留一个只有直连成员的策略组。它不提供远端代理能力，适合先确认 YAML 能否加载、端口是否监听以及组名引用是否一致。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

proxies: []

proxy-groups:
  - name: "手动出口"
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,手动出口

TUN 接管入口，不替代分流规则

TUN 用于通过虚拟网络接口接管流量，常见于应用不遵循系统代理的场景。它不属于 proxies，也不会自动修复错误的节点凭据。以支持相关字段的 mihomo 为例，可在现有配置中单独加入下列片段；它不是传统 Clash 所有内核都通用的配置。

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

实际启用仍需要操作系统权限、可用的虚拟网卡支持和正确路由。dns-hijack 用于处理进入该接管路径的相应 DNS 流量，不代表应用自带的 HTTPS 加密 DNS 都会被截获。若客户端已经通过界面管理 TUN，应先查看生成后的配置，避免同时在多个地方维护相反设置。

8. 修改、验证与回滚顺序

保留副本：导出当前 Profile，并记录选中的策略组成员。订阅原文件与本地覆写分别备份。
一次只改一类内容：先改端口并验证，再处理 DNS，最后调整节点、组和规则。不要同时更换内核、开启 TUN 和替换整套 DNS。
执行配置检查：若使用 mihomo 命令行且配置位于当前目录，可执行 mihomo -t -f ./config.yaml；其他内核先用 -h 确认选项。命令行校验通过仍不代表网络可达。
核对实际运行配置：重新加载后查看日志，确认没有 YAML 解析失败、节点引用不存在或监听地址占用等错误。
分层验证：依次确认本地入口、DNS 响应、节点连接和规则命中。查看连接记录时同时记录目标域名、命中规则、策略组与最终成员。
故障时回滚：切回上一份可用 Profile，恢复原来的系统代理或 TUN 开关，再定位差异。不要连续导入多份未知配置掩盖最初问题。

按错误现象定位字段

加载时报行号：先查缩进、引号、冒号和列表格式，再看报错行的上一行是否缺少结构。
提示找不到代理或策略：核对 rules、proxy-groups、proxies 之间的名称引用。
提示地址已被占用：检查 7890、1053 等当前配置端口是否被其他进程或另一份内核占用。
能解析但无法连接：继续检查节点服务器、协议参数、当前选中成员和出站网络，不要只反复修改 DNS。
手动改动更新后消失：检查修改对象是否为订阅缓存文件，把需要保留的设置迁移到客户端支持的覆写或合并机制。

阅读配置时，先认清入口端口，再跟踪规则引用的组和组内成员，最后单独检查 DNS 与 TUN 的接入条件。理解这几层关系后，才能区分“文件能够加载”“规则已经命中”和“连接真正可用”这三个不同结果。更多操作步骤可查看进阶配置，字段含义可对照术语表。