Skip to main content

Clash 配置格式详解：从能看懂到能自己改（以 Mihomo 为准）

· 6 min read
Jiang
Operator

很多人手里有订阅链接，但一打开 config.yaml 就懵：

  • proxy-groups 到底引用的是谁？
  • rules 为什么顺序一变就全挂？
  • rule-providers 和 proxy-providers 有什么区别？
  • fake-ip、redir-host、no-resolve 这些选项什么时候该开？

这篇文章不讲“某个机场怎么填”，专门讲配置文件格式本身，目标是让你能独立看懂、改对、排错。

本文以 Mihomo（Clash Meta） 的官方配置文档为准。不同内核（老 Clash、Mihomo、部分 GUI 的兼容层）字段会有差异，别拿旧教程硬套新内核。

先记住一个总结构​

一个可维护的 Clash/Mihomo 配置，通常可以按这 7 块去读：

  1. general（顶层通用字段）
  2. dns
  3. proxies / proxy-providers
  4. proxy-groups
  5. rule-providers
  6. rules
  7. tun（按需）

你可以把它理解成：

  • 上游节点从 proxies/proxy-providers 来
  • 策略组在 proxy-groups 里编排这些节点
  • 分流规则在 rules，按顺序把流量导向某个策略组
  • DNS 和 TUN 决定“流量是怎么被识别、怎么进入规则引擎”的

一份能跑的最小骨架​

先给一个“结构正确”的最小模板（不是最优模板）：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "change-me"

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - tls://1.1.1.1
    - tls://8.8.4.4

proxy-providers:
  mysub:
    type: http
    url: "https://example.com/sub?token=xxx"
    path: ./providers/mysub.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: Proxy
    type: select
    use:
      - mysub
    proxies:
      - DIRECT
  - name: Auto
    type: url-test
    use:
      - mysub
    url: https://www.gstatic.com/generate_204
    interval: 300

rule-providers:
  cn:
    type: http
    behavior: classical
    format: yaml
    url: "https://example.com/rules/cn.yaml"
    path: ./rules/cn.yaml
    interval: 86400

rules:
  - RULE-SET,cn,DIRECT
  - MATCH,Proxy

1) 顶层通用字段：先看“入口和控制面”​

最先看这些：

  • mixed-port / port / socks-port
  • allow-lan + bind-address
  • mode（rule/global/direct）
  • external-controller + secret

这里最常见的坑：

  • 开了 allow-lan: true 却忘了 secret，控制接口暴露风险高
  • mode: global 时误以为规则没生效（它本来就不按规则走）
  • GUI 看起来“节点正常”，但实际本地代理端口没开对

2) DNS：这是分流正确率的地基​

多数“规则写得没问题但分流错了”，根因在 DNS。

重点字段：

  • enhanced-mode: fake-ip 或 redir-host
  • nameserver / fallback
  • nameserver-policy
  • fallback-filter
  • respect-rules（慎用）

经验上：

  • 新手优先 fake-ip，但要配好 fake-ip-filter
  • 国内外并存环境要明确 fallback-filter 策略
  • 不要盲目开一堆“看起来高级”的 DNS 开关

3) proxies vs proxy-providers：静态节点和动态节点​

proxies：

  • 你手写每个节点参数（vmess/trojan/hysteria2...）

proxy-providers：

  • 从远端订阅拉节点，定时更新
  • 由策略组通过 use 引用

生产上更常见 proxy-providers，因为你不想手改几十上百个节点。

4) proxy-groups：把节点编排成“可决策”出口​

最常见分组类型：

  • select：手动选
  • url-test：自动测速选优
  • fallback：按顺序故障切换
  • load-balance：负载分摊

高频坑：

  • 组 A 引用组 B，组 B 又绕回组 A（循环依赖）
  • url-test 的 url 不稳定，导致误判“节点全挂”
  • 只写了 use 没有兜底 DIRECT / REJECT，故障时策略不清晰

官方还提示了一个重要变化：

  • relay 策略即将废弃，建议迁移到 dialer-proxy

5) rule-providers：把规则集外置，别把大规则硬塞在主配置​

当规则多起来，主配置建议只保留骨架，把规则放到 rule-providers。

核心字段：

  • type: http/file/inline
  • behavior: classical/domain/ipcidr
  • format: yaml/text/mrs
  • path / url / interval

最容易错的地方：

  • behavior 与规则文件实际内容不匹配
  • RULE-SET 引用了不存在的 provider 名
  • provider 下载路径、权限或更新失败但你没关注日志

6) rules：按“从上到下”匹配，最后必须有兜底​

规则引擎最核心的一条：

上面的优先，下面的兜底。

所以：

  • 高精度规则放前面
  • 大范围规则放后面
  • 最后总要有 MATCH,...

常见规则类型：

  • DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD / DOMAIN-WILDCARD
  • IP-CIDR / GEOIP
  • PROCESS-NAME（Android 上可匹配包名）
  • RULE-SET
  • MATCH

no-resolve 只在“目标 IP 类规则”场景有意义，别到处乱加。

7) tun：它决定你是不是“全局接管流量”​

很多客户端会帮你生成 TUN 配置，但你至少要知道：

  • tun.enable
  • stack（常见 system/gvisor/mixed）
  • dns-hijack
  • auto-route / strict-route（按平台和需求）

如果你不是高级用户，优先用顶层 tun 配置，不要直接折腾 listeners 里的低层 tun 配置。

一张表看懂“改哪里”​

你要实现的目标主要改哪块
换订阅链接proxy-providers
改默认出口（手动/自动）proxy-groups
某域名强制直连/代理rules
DNS 污染、分流异常dns
局域网共享代理allow-lan / bind-address / 鉴权
全局接管设备流量tun

排错建议（比“删配置重装”更有效）​

  1. 先看配置是否通过 YAML 和内核校验（语法错误先清掉）
  2. 再看 provider 是否拉取成功（节点/规则是否真的更新）
  3. 看 rules 是否有兜底 MATCH
  4. 抓一个域名做单点排查：DNS 结果 -> 命中规则 -> 命中策略组 -> 最终节点
  5. 晚高峰再复测一次，别只看白天结果

常见误区​

  • “规则没生效”其实是 mode: global
  • “节点都超时”其实是测速 URL 被墙或被污染
  • “按国家分流没对上”其实是 DNS 策略和规则冲突
  • “复制别人配置就能跑”通常忽略了内核版本和字段差异

参考资料（官方）​