先确定配置路径与引用方向

配置的核心关系是：规则选择策略组，策略组选择节点，DNS 为域名解析提供结果。把字段按这个关系拆开，比逐行修改订阅文件更容易定位问题。本文面向 mihomo，也就是常被称为 Clash Meta 内核的后续项目；旧版 Clash 内核和不同图形客户端的配置合并机制不一定支持相同字段。

直接运行内核时，可以把工作目录固定为 ~/.config/mihomo，配置文件放在该目录的 config.yaml。使用客户端时，先确认它最终交给内核的配置路径；订阅原文、覆写文件和运行时配置可能是三个不同文件。直接编辑运行时文件，下一次更新订阅后可能被覆盖。

mkdir -p ~/.config/mihomo
mihomo -v
mihomo -t -d ~/.config/mihomo

-v 用于记录正在运行的内核版本；-t 检查指定目录下的配置。配置尚未创建时，最后一条命令报找不到文件是正常现象。下文前六节的 YAML 片段可以按顺序合成一个起步配置；其中的本机 SOCKS 节点有明确前提，不能当成现成的远程代理服务。

一、mixed-port：先建立本机代理入口

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
ipv6: false

mixed-port 同时接受 HTTP 代理和 SOCKS5 代理连接，因此浏览器、命令行工具可以共用 127.0.0.1:7890。它不是控制面板端口，也不是节点服务器的远程端口。若只需要本机应用访问，保持 allow-lan: false，不要为了排查网页问题就把监听地址改成所有网卡。

字段用途本文取值
mixed-port应用连接的 HTTP / SOCKS 入口7890
port独立 HTTP 代理入口不单独开启
socks-port独立 SOCKS 代理入口不单独开启
dns.listen内核 DNS 服务监听地址127.0.0.1:1053
external-controller管理 API，不接收普通网页代理请求起步配置省略

这里把 IPv6 作为初次部署的变量暂时关闭，不代表所有网络都应长期关闭 IPv6。后续启用时，需要一起检查 DNS 的 AAAA 响应、节点 IPv6 连通性和系统路由。若要共享给局域网设备，应另外规划监听地址、认证和防火墙，而不是只修改一个布尔值。

ss -lntp 'sport = :7890'
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

第一条命令确认端口是否监听；第二条显式指定代理，绕过桌面环境的系统代理设置。只有内核已经启动，这两条验证才有意义。若出现连接被拒绝，优先检查进程与端口，不必立即调整 DNS。

二、mode 与日志：把分流方式固定下来

mode: rule
log-level: info

mode: rule 表示按 rules 列表选择出口。direct 模式倾向于直接连接，global 模式使用全局策略；排查规则时应先确认没有被客户端切换成其他模式。配置里的模式也可能被管理 API 修改，因此文件写着 rule，不等于当前运行状态一定如此。

log-level: info 适合观察一般连接和启动错误。需要追踪具体规则或 DNS 行为时，可短时间改为 debug，复现后再恢复。日志可能包含访问域名、节点地址和连接信息，分享前需要删去敏感内容。不要同时修改模式、节点和 DNS；每次只改一组字段，才能把现象对应到具体变化。

三、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
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

三个字段分别解决什么问题

  • listen 决定本地 DNS 服务接收查询的位置。这里使用非特权端口 1053，避免起步阶段直接占用系统常用的 53 端口。
  • default-nameserver 用于解析 DNS 上游服务器自身的域名，避免上游地址还没解析出来就无法继续查询。
  • nameserver 是默认域名解析上游。示例使用两个 DoH 地址，实际网络必须能够访问它们；写成 HTTPS 并不自动保证可达。

fake-ip 会给符合条件的域名返回虚拟地址，内核再通过映射关系还原域名并处理连接。它不是远程节点的实际 IP，也不表示目标网站落在 198.18.0.0/16。依赖真实解析结果的局域网服务，可以按域名加入 fake-ip-filter，让它们不走 fake-ip 响应路径。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 localhost A

在示例配置下，第一条查询通常返回 fake-ip 地址；过滤项的行为则取决于实际解析结果。若系统没有 dig，可安装发行版提供的 DNS 工具包。直接查询内核监听端口，是为了把“上游解析异常”和“系统没有使用内核 DNS”这两类问题分开。

四、proxies：声明节点，不把入口端口当上游

proxies:
  - name: "本机SOCKS"
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

这个示例引用本机已经运行的 SOCKS5 服务，地址为 127.0.0.1:1080，不带认证。它适合验证配置引用关系，不会创建该服务。没有这个上游时，稍后把策略组选为 DIRECT，仍能验证本地监听与规则加载，但不能验证代理节点连通性。

name 是配置内部的引用名称，后面的策略组必须逐字匹配；server 和 port 才是节点连接地址。若已有订阅，应使用服务方实际提供的节点参数，不要把 SOCKS5 示例机械地改成其他协议。Shadowsocks、VMess、VLESS 等类型的认证与传输字段各不相同，type 不是唯一差异。

五、proxy-groups：让规则引用稳定的出口名称

proxy-groups:
  - name: "出口"
    type: select
    proxies:
      - DIRECT
      - "本机SOCKS"

select 是手动选择组。规则只引用“出口”，节点替换时便不必逐条修改规则。DIRECT 是内置的直接连接策略，不需要在 proxies 中再次声明；“本机SOCKS”则必须对应上一节的节点名称。对于没有保存选择状态的首次运行，本例把 DIRECT 放在第一项，便于先验证基础链路。

图形客户端通常会保存策略组选择。修改列表顺序后，旧选择可能仍被恢复；测试前要看清当前选中的条目。若使用纯内核运行且未启用管理 API，起步阶段可以通过调整首项并重启测试，之后再按需要接入本地控制面板。

需要自动测速时再引入 url-test

url-test 会定期向指定 URL 发起探测并比较延迟；它不是“所有网站都可访问”的证明。比如设置 interval: 300 表示每 300 秒检查一次，而不是每次请求都测速。节点少、刚开始排查时，先用 select 确定一条可用链路，再考虑自动选择，避免把健康检查失败与节点认证失败混在一起。

六、rules：从具体匹配到最终兜底

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN,localhost,DIRECT
  - 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
  - DOMAIN-SUFFIX,github.com,出口
  - MATCH,出口

规则从上向下匹配，命中后通常不再继续向下找。DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配域名本身及其子域。例如 github.com 和 api.github.com 都能命中示例中的后缀规则，但并不意味着所有 GitHub 相关资源域名都包含在内。

IP-CIDR 按目标 IPv4 地址段匹配。no-resolve 表示不要仅为判断这条 IP 规则而主动解析尚未解析的目标域名；已有目标 IP 时仍能参与匹配。因此，局域网服务最好同时维护必要的域名规则，不能只靠私网地址段推断所有本地名称。

MATCH 是最终兜底，应放在最后。写在前面会使后续规则失去匹配机会。本例用显式私网地址段，起步时不依赖 GeoIP 数据库；它也不是完整的特殊用途地址清单。IPv6 已在前面的基础配置中关闭，启用 IPv6 后还需要补充相应的地址策略。

到这里，前六节片段已经构成基础配置。它的目标是展示字段关系，不是提供完整的地区分流方案。更细的规则集、DNS 分流和进程规则应在基线工作后逐项添加，相关字段可以继续查阅配置参考。

七、proxy-providers：节点多时再拆分文件

节点增加后，可以把节点列表移到 Provider 文件。下面是替换第四、五节的可选方案，不要与前面相同名称的策略组重复粘贴。主配置从文件读取节点，策略组通过 use 引用 Provider 名称，而不是把 Provider 名称写进节点列表。

proxy-providers:
  local-pool:
    type: file
    path: ./providers/local.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "出口"
    type: select
    proxies:
      - DIRECT
    use:
      - local-pool

在 ~/.config/mihomo/providers/local.yaml 中写入下列内容，并先创建 providers 目录。相对路径应按实际工作目录核对，本文启动命令通过 -d 明确指定了目录。

proxies:
  - name: "本机SOCKS"
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

Provider 文件需要满足节点集合格式。它不是把包含 dns、rules 等字段的完整客户端配置随意改名即可。若改用 type: http，还需要填入实际订阅 URL，并使用 Provider 层级的 interval 设置拉取周期。订阅地址通常带有访问凭据，不应出现在公开日志或截图里。

注意两个周期的区别：Provider 的 interval 控制远程内容刷新；health-check.interval 控制节点探测。这里是本地文件 Provider，不会因为健康检查每 600 秒执行一次，就从远程下载新节点。探测地址自身不可达时，也可能出现整组节点探测失败，需要结合实际请求判断。

八、TUN 是额外的接管层，不是配置必填项

先让显式代理正常工作，再启用 TUN。TUN 通过虚拟网络设备与路由接管流量；普通的 mixed-port 不会自动让所有应用走代理。下面片段只适用于准备好权限和路由环境的 Linux 测试，不属于前六节的基础配置。

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

auto-route 请求内核设置相应路由，auto-detect-interface 用于识别出口接口。创建 TUN 和修改路由需要足够的系统权限，通常由客户端的服务模式或管理员配置的服务提供；普通用户进程不一定具备条件。dns-hijack 用于接管进入该处理路径的传统 53 端口 DNS 请求，不会直接解密浏览器自己的 DoH 流量。

九、按“语法、监听、DNS、出口”验证

  1. 备份当前文件。修改前保留一份已知可用的配置，尤其是订阅覆写和手写规则。不要把备份文件误当成正在使用的配置。
  2. 检查语法与引用。运行 mihomo -t -d ~/.config/mihomo。节点名不存在、策略组引用错误和 YAML 缩进问题，应在重启前解决。
  3. 只保留一个测试实例。已有图形客户端占用 7890 时，先停止其内核，或为测试配置选择另一个端口。端口冲突不是节点故障。
  4. 前台运行观察日志。使用下方启动命令，再从另一个终端执行端口、DNS 和代理请求测试。退出前台测试可按 Ctrl+C。
mihomo -d ~/.config/mihomo

# 在另一个终端运行
ss -lntp 'sport = :7890'
dig @127.0.0.1 -p 1053 example.com A
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 -I https://example.com/

socks5h 中的 h 表示把目标域名交给代理端处理；与客户端先在本地解析域名的方式不同。这有助于判断问题是否发生在应用自己的 DNS 路径。HTTP 请求返回错误状态时，也要区分目标网站的响应与代理连接失败，不能只根据是否出现 200 判断网络链路。

配置测试通过，只说明配置能够被解析和加载，不保证订阅地址可访问、节点认证正确、DNS 上游可达或 TUN 路由合理。基线验证通过后，再恢复 systemd 服务或客户端托管，确认服务使用的二进制、工作目录和配置文件与测试时一致。需要部署步骤时，可按快速上手继续；遇到连接异常则先看疑难解答。

最终保留一条清晰的依赖链：应用连接 mixed-port，规则命中“出口”，策略组选中有效节点或 DIRECT，DNS 提供相应解析。后续加入订阅刷新、规则集和 TUN 时，每次只扩展一层，并重复同一组验证命令。