99吧机场

站长推荐

IPLC专线+BGP中转，不限使用设备数量，价格亲民，性价比拉满！

→

FlyBit机场

折扣优惠

IPLC专线+中转,所有线路都是1倍率，用多少算多少，很实在！

→

很多人使用 Clash 时，通常只需要导入订阅、选择节点，然后开启系统代理。但当遇到“某个网站没有按预期走代理”“订阅里的节点名称看不懂”“想给一类应用单独选节点”时，最终都会接触到配置文件。

Clash 配置文件并不神秘，它本质上是一份用 YAML 格式写成的网络转发说明书：有哪些可用代理、如何把代理组织成菜单、什么流量走哪个菜单，以及 DNS 应该怎样查询。读懂其中几个核心字段，不意味着要手写整份复杂配置；更重要的是，你能判断一份配置在做什么，也能在排障时快速定位问题。

先建立一个整体概念：配置文件像四层“决策流程”

一份典型 Clash 配置看起来很长，但普通用户最需要关注的内容通常可以分成四层：

1. 代理节点（proxies）：可连接的服务器信息，例如协议、地址、端口和认证参数。
2. 代理组（proxy-groups）：把多个节点或其他组组织成可选择、可测速或可自动切换的菜单。
3. 规则（rules）：决定某个域名、IP、应用流量应当交给哪个代理组，或直接连接。
4. DNS 与网络设置：决定域名怎样解析、是否启用 IPv6、透明代理或 TUN 等能力如何工作。

可以把它理解为：访问一个网站时，Clash 先识别目标地址，再按规则找到对应的“出口菜单”，最后由该菜单选出一个节点或直连方式。配置里任何一层不匹配，都会出现“明明选了节点，为什么这个网站还是不通”的现象。

YAML 是什么：格式比内容更容易出错

Clash 的传统配置多使用 YAML。它对缩进非常敏感，通常使用空格，不要混用 Tab 制表符。例如下面的结构：

mixed-port: 7890
mode: rule

proxies:
  - name: "节点 A"
    type: ss
    server: example.com
    port: 443

这里有三个容易忽略的规则：

• 冒号后面通常需要一个空格，例如 name: "节点 A"。
• 同一层级的字段，缩进必须一致。
• 以 - 开头的内容代表列表中的一项；proxies 下每一个 - name，就是一个独立节点。

手动编辑时，少一个空格、缩进多一层，都可能导致客户端提示配置解析失败。对于订阅生成的主配置，更稳妥的做法不是直接编辑原文件，而是优先使用客户端提供的“覆写”“扩展脚本”或“本地规则”功能。因为订阅更新后，原文件往往会被重新下载的内容覆盖。

此外，不要把完整配置、订阅链接或节点详情发到公开评论区。它们可能包含服务器地址、认证 UUID、密码、订阅令牌等敏感信息。需要请人协助排查时，应先删除或替换这些字段。

proxies：节点列表，不等于你实际使用的线路

proxies 字段保存的是节点定义。不同协议的字段会有区别，但常见内容包括：

proxies:
  - name: "香港-示例"
    type: trojan
    server: node.example.com
    port: 443
    password: "已隐藏"
    sni: cdn.example.com

其中：

• name 是客户端界面显示的名字，也是其他配置引用它时使用的标识。
• type 是协议类型，例如 ss、trojan、vmess、vless 等。
• server 和 port 是服务端地址与端口。
• password、uuid、cipher、sni、tls 等字段属于连接参数，具体取决于协议。

需要注意的是，节点存在于 proxies 中，并不代表日常流量一定会使用它。真正决定选哪个节点的，通常是后面的 proxy-groups。而且节点名称可能被服务商调整，因此不建议在自定义规则中大量硬编码某个具体节点名；更通用的做法是引用一个稳定的代理组名称。

proxy-groups：Clash 界面里的“选择菜单”从哪里来

打开 Clash 客户端，你通常会看到“节点选择”“自动选择”“流媒体”“AI 服务”等菜单。这些菜单在配置中大多对应 proxy-groups。

最常见的手动选择组类似这样：

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "自动选择"
      - "香港-示例"
      - DIRECT

type: select 表示由用户手动选择。proxies 中列出的项目既可以是具体节点，也可以是另一个代理组，还可以是内置动作：

• DIRECT：不经过代理，直接连接。
• REJECT：直接拒绝连接，常用于拦截不需要的请求。
• 其他组名：形成多级菜单，例如“节点选择”里嵌套“自动选择”。

另外两类常见代理组是 url-test 和 fallback。前者会定期访问指定测试网址，并按延迟等结果选择节点；后者通常在当前节点不可用时尝试切换到备用节点。它们能减少手动切换次数，但不是万能的“最快线路保证”：测试网址的响应只代表该测试目标在某一时刻的连通表现，未必能代表所有网站、所有应用的真实体验。

看配置时还要留意一个细节：组名必须准确匹配。规则写的是 节点选择，而配置中的代理组叫作 🚀 节点选择，这两者并不是同一个名称。中文、空格、表情符号都属于名称的一部分。很多规则失效，问题并不在规则语法，而在于引用了不存在的组名。

rules：分流真正发生的地方

如果代理组是“出口菜单”，规则就是“分配条件”。Clash 会按照规则的先后顺序进行匹配，先匹配到的规则先执行，后面的同类规则不再参与判断。

一个简化示例：

rules:
  - DOMAIN-SUFFIX,example.ai,AI 服务
  - DOMAIN-KEYWORD,google,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

可以这样理解：

• DOMAIN-SUFFIX,example.ai,AI 服务：所有以 example.ai 结尾的域名，交给“AI 服务”代理组。
• DOMAIN-KEYWORD,google,节点选择：域名中包含 google 的请求，交给“节点选择”。
• GEOIP,CN,DIRECT：匹配到中国大陆 IP 的流量直接连接。其实际效果还会受 DNS 解析、数据库版本和客户端实现影响。
• MATCH,节点选择：前面都没有命中的流量，默认交给“节点选择”。它通常应当放在较靠后的位置。

规则的顺序是排障重点。假设你为某个域名新增了一条代理规则，但它前面已经有一条更宽泛的 DOMAIN-SUFFIX 或规则集把该域名匹配走了，那么新增规则不会生效。此时不要盲目反复添加规则，而应该先确认：目标域名实际是什么、已有规则从上到下如何覆盖、规则最终指向的代理组是否存在。

对于不熟悉规则语法的用户，建议把自定义需求控制在少量、明确的场景，例如“某个工作域名固定使用某个代理组”或“局域网网段始终直连”。大规模复制来源不明的规则集合，可能造成误分流、解析缓慢、内网设备无法访问等问题。

DNS：域名解析决定了规则能否准确命中

用户在浏览器中输入的是域名，但网络连接最终往往需要 IP 地址。DNS 就是把域名转换为 IP 的过程。Clash 配置中的 DNS 设置，会影响域名解析路径，也会影响基于域名或 IP 的规则判断。

常见的 DNS 区块会包含 enable、listen、enhanced-mode、nameserver、fallback 或按规则区分的解析服务器等字段。不同 Clash 内核和客户端支持的写法并不完全一致，因此不要把一份配置原样套用到所有客户端。

普通用户需要掌握以下原则：

• 若配置已经有一套完整 DNS 方案，排障时不要同时在多个位置随意修改，例如系统 DNS、客户端 DNS、路由器 DNS 一起改，最后会很难判断是谁生效。
• 某些模式下，域名解析的结果可能影响 GEOIP、IP-CIDR 等规则的判断；遇到“域名规则正常、IP 规则异常”时，DNS 是重要检查项。
• 内网域名、路由器管理地址、公司 VPN 域名等场景，往往需要使用本地网络提供的 DNS 或设置明确的直连规则。否则可能出现打印机、NAS、公司资源打不开的情况。
• 不要仅凭“改 DNS 能解决一切”的说法修改配置。连接失败也可能来自代理节点、证书时间、网络限制、规则顺序或应用自身缓存。

修改配置前，先选择正确的方法

面对“我只想加一条规则”的需求，常见做法有三种，优先级从推荐到谨慎如下：

1. 使用客户端的覆写或本地扩展功能

这是最适合订阅用户的方式。主订阅保持原样更新，本地覆写只保存你自己的代理组、规则或 DNS 微调。这样既便于恢复，也能避免更新订阅时丢失改动。

不同客户端对覆写格式和入口的命名不同，有的使用 YAML 片段，有的提供图形化规则编辑。操作前应确认客户端使用的内核类型，以及它要求的字段格式。

2. 单独维护本地配置

如果你已经理解节点、代理组和规则之间的引用关系，可以维护一份本地配置，并根据需要把节点信息导入其中。这种方式可控性高，但需要自己负责更新、语法检查和备份。

3. 直接改订阅下载的原配置

这通常只适合临时验证问题。订阅更新后改动可能消失；如果修改时引入格式错误，整个配置还可能无法加载。若不得不这样做，至少先复制原文件，并记录改动位置。

一份安全、可回退的修改流程

无论使用哪种方式，都建议遵循下面的顺序：

1. 备份：导出当前配置或复制覆写内容，保留一个可以立即恢复的版本。
2. 一次只改一件事：例如只新增一条规则，不要同时改 DNS、TUN、代理组和端口。
3. 确认引用名称：规则目标的代理组名称、节点名称必须与配置中完全一致。
4. 重载配置后观察日志：重点查看是否有 YAML 解析错误、找不到代理组、规则集下载失败等提示。
5. 用目标应用验证：不要只看客户端显示“已连接”。打开实际有问题的网站或应用，并确认它命中的代理组。
6. 失败就回退：如果改动导致大面积无法联网，先恢复上一版，而不是继续叠加更多未知修改。

常见误区：为什么“看起来没问题”却仍然无效

误区一：把规则写进了错误的位置。

有些客户端将“订阅覆写”“全局设置”“规则编辑器”分成不同页面。把一段 rules: 文本放到只接受单条规则的输入框中，或把完整配置粘贴进覆写片段，都可能无法按预期合并。

误区二：默认规则放得太靠前。

如果 MATCH、宽泛的域名后缀规则出现在前面，后续精细规则通常不会再有机会命中。

误区三：把节点名当成永久标识。

订阅提供方可以更改节点名称、增删节点或调整分组。自定义规则最好指向你自己维护的稳定代理组，而不是某个经常变化的节点名。

误区四：忽略应用缓存和已有连接。

浏览器、即时通信工具和系统服务可能复用旧连接。配置重载后，必要时重新打开目标应用，或等待旧连接结束，再判断新规则是否生效。

误区五：混淆“规则模式”和“全局模式”。

在全局模式下，许多精细分流规则不会按你预期参与决策；在规则模式下，才主要依赖 rules 的顺序。排查前先确认当前运行模式，能避免做无效修改。

结语：不必会写配置，但要学会验证配置

学习 Clash 配置最有价值的目标，不是从零手写一份几百行 YAML，而是建立一套判断思路：节点负责连接，代理组负责选择，规则负责分流，DNS 负责解析；配置改动应当可备份、可验证、可回退。

当你下次遇到某个服务访问异常时，可以按这个顺序检查：当前是否处于规则模式、目标流量命中了哪个规则、规则指向的代理组是否存在、该组实际选择了什么出口、DNS 和本地网络是否干扰了解析。把问题拆成这些环节，通常比不断切换节点或复制陌生配置更有效，也更安全。