Clash 配置文件参考

CHAPTER 01

YAML 结构总览

配置文件如何被读取

Clash 配置文件本质上是一份 YAML 文档。内核启动时先解析语法，再读取监听端口、DNS、代理节点、策略组和规则等顶层字段，最后建立本地代理入口与流量匹配链。语法阶段失败时，客户端通常不会进入可用状态；语法通过但字段关系错误时，则可能出现能够启动、却没有可选节点或规则无法命中的情况。因此排查配置不能只看文件是否能打开，还要依次确认 YAML 语法、字段名称、对象引用和运行环境。

常见顶层结构包括 port、socks-port、mixed-port、mode、log-level、dns、proxies、proxy-groups、rules、proxy-providers 与 rule-providers。并非每份配置都要同时包含全部字段。例如只使用 mixed-port 时，可以不再单独设置 HTTP 和 SOCKS 端口；节点由远程提供器加载时，proxies 可以为空，但策略组必须通过 use 引用对应提供器。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - https://dns.alidns.com/dns-query

proxies:
  - name: Example-Trojan
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - Example-Trojan
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,节点选择
  - MATCH,节点选择

上面的示例展示了最短的完整链路：本地程序连接 7890 端口，DNS 模块处理域名解析，proxies 定义一个出口，proxy-groups 把出口组织成可选择的策略，rules 决定流量交给哪个策略。真实订阅通常会包含更多节点和规则，但关系仍然是“入口—解析—出口—策略—匹配”。理解这条链路后，遇到连接失败时就能判断问题属于哪一层。

缩进、列表与数据类型

YAML 用缩进表达层级，建议统一使用两个空格，不要使用 Tab。冒号后需要留一个空格；列表项以短横线和空格开头；同级字段必须保持相同缩进。dns 是映射对象，内部字段比它多缩进一级；nameserver 是列表，列表中的每个地址再多缩进一级。把 enable 与 nameserver 错缩进到不同层级，解析器可能直接报错，也可能把内容解释成与预期不同的结构。

布尔值宜使用 true 与 false，端口写成整数，名称与地址写成字符串。包含冒号、井号、逗号或容易被识别为布尔值的内容时，使用引号更稳妥。例如密码里出现井号，未加引号时井号后的部分会被当成注释；节点名写成 on、off 等词时，不同 YAML 解析器可能采用不同解释。对于订阅链接、正则表达式和复杂密码，建议使用单引号；若字符串需要转义字符，再使用双引号。

名称引用必须完全一致

策略组和规则通过名称引用其他对象，名称区分全角、半角、空格和大小写。节点名是“香港 01”，策略组中写成“香港01”就不是同一个对象；规则末尾写“节点选择”，配置中却只有“代理选择”，也会形成悬空引用。修改订阅时不要只改定义处，应该同时搜索全部引用。节点重名同样需要避免，因为界面可能只显示一个名称，难以判断实际选中了哪一项。

YAML 允许注释，但注释只适合说明字段用途，不宜用来暂存大段失效配置。被注释的节点仍可能被策略组引用，删除节点却忘记清理引用也是常见错误。较稳妥的维护方式是保留一份基础配置，将实验字段放在单独副本中，确认能够加载后再移入常用配置。使用 Clash Plus、Clash Verge Rev、FlClash 等图形客户端时，也可以先在客户端内执行配置检查，再切换为当前配置。客户端入口与平台说明见获取客户端。

CHAPTER 02

通用字段、端口与运行模式

本地监听端口

port 提供 HTTP 代理入口，socks-port 提供 SOCKS5 入口，mixed-port 则在同一端口接受 HTTP 与 SOCKS 请求。多数桌面环境只需要设置 mixed-port，然后让客户端的系统代理功能把操作系统代理地址指向该端口。若某个开发工具只接受 SOCKS5，可以单独启用 socks-port；多个字段同时启用时，端口号必须不同，也不能与其他本地程序占用的端口重复。

port: 7890
socks-port: 7891
mixed-port: 7892
redir-port: 7893
tproxy-port: 7894

redir-port 和 tproxy-port 主要用于 Linux 路由转发或透明代理。它们不是普通桌面软件设置系统代理所必需的字段，单独写入配置也不会自动建立防火墙与路由规则。使用透明代理时，还要在系统层配置流量转发、策略路由和权限；如果目标是让不遵循系统代理的程序也进入 Clash，通常应先了解 TUN 模式。相关原理和配置步骤可参考Clash TUN 模式开启方法。

局域网访问与监听地址

allow-lan 决定其他设备能否连接当前设备上的代理端口。设置为 false 时，本机应用仍可使用代理，但局域网中的手机、电视或另一台电脑不能把这里当作代理服务器。设置为 true 后，还需要确认 bind-address、操作系统防火墙与网络类型。只在可信局域网中使用时，可以将监听范围限制到具体内网地址，避免在所有网络接口上开放。

allow-lan: true
bind-address: 192.168.1.20
authentication:
  - local-user:your-password

启用局域网访问意味着同一网络中的设备可以尝试连接监听端口，因此不应只依赖网络环境名称判断安全性。公共网络、临时热点和共享宿舍网络中，建议关闭 allow-lan。确需共享时，可以配合认证字段，并在系统防火墙中只允许指定网段。远程控制接口与代理入口是两类不同服务，开放代理端口并不代表需要把控制接口也暴露到局域网。

Rule、Global 与 Direct 模式

mode: rule 表示按 rules 从上到下匹配，是日常配置最常用的模式。global 会把连接交给全局策略组，不再逐条执行分流规则；direct 则直接连接。图形客户端里的模式切换可能在运行时覆盖配置文件中的默认值，因此文件写着 rule，界面仍可能处于 Global。排查异常分流时，应同时查看配置字段和客户端当前状态。

Global 模式适合短时间确认某个问题是否由规则引起，但不适合替代完善的规则配置。如果 Rule 模式下网站无法访问，而 Global 模式可以访问，通常说明域名被交给了错误策略、规则顺序不当，或者目标策略组当前选择了不可用节点。Direct 模式适合确认本地网络本身是否可达；如果 Direct 也失败，则应先检查网络、DNS 和目标服务，而不是反复更换代理节点。

日志、IPv6 与控制接口

log-level 常用值包括 silent、error、warning、info 和 debug。日常使用保持 info 通常足够；定位配置加载、DNS 查询或连接握手问题时，可以暂时改为 debug。日志可能包含访问域名、节点名称和本地连接信息，分享排错截图前应先检查内容。错误解决后恢复正常级别，可以减少无关输出。

ipv6 不是简单的“网络更快”开关。当地网络没有稳定 IPv6，但 DNS 返回了 AAAA 记录时，程序可能先尝试不可达地址；完全关闭 IPv6 又可能影响只提供 IPv6 的环境。应根据实际网络能力决定，并让顶层 ipv6、DNS 模块与 TUN 设置保持一致。遇到同一域名时通时断，可分别测试只返回 IPv4 与同时返回 IPv6 的结果，判断是否存在地址族差异。

external-controller 为图形界面或外部面板提供控制接口。桌面客户端往往自动管理该字段，不需要手工开放。自行配置时优先监听回环地址，例如 127.0.0.1:9090，并设置控制密钥。把它写成 0.0.0.0:9090 会允许其他网络接口访问，只有明确需要远程管理并完成访问限制时才应这样设置。external-ui 只是静态面板文件目录，不会自动下载或更新界面。

external-controller: 127.0.0.1:9090
secret: your-control-secret
external-ui: dashboard

通用字段应从“最少可用”开始添加。先确认一个混合端口、Rule 模式和基础日志能够工作，再逐步启用局域网、TUN、控制接口或高级网络选项。一次加入大量字段，虽然文件看起来完整，却会让错误来源难以定位。不同 Clash 分支对高级字段的支持范围可能不同，使用图形客户端时应以它实际搭载的内核和配置检查结果为准。

CHAPTER 03

DNS 配置与解析链路

DNS 模块解决什么问题

应用访问域名时，需要先得到目标地址，再建立连接。若域名解析绕过 Clash，而连接本身进入代理，就可能出现解析结果与代理出口不一致、污染结果被直接使用或规则无法取得原始域名等问题。Clash 的 DNS 模块可以接收本机查询，按指定上游解析，并在 Fake-IP 模式下建立虚拟地址与域名的映射，让后续流量仍能按域名规则判断。

dns.enable 控制模块是否启用，listen 指定监听地址，nameserver 是主要上游，fallback 可提供另一组解析来源。桌面客户端可能通过 TUN 或系统设置自动把查询导向内置 DNS；仅在配置中写入 listen: 127.0.0.1:1053，并不会自动修改操作系统 DNS。若普通系统查询仍发往路由器，就需要检查客户端的 DNS 接管选项。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  nameserver:
    - 223.5.5.5
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - '*.lan'
    - localhost.ptlogin2.qq.com
    - time.*.com

Fake-IP 与 Redir-Host

enhanced-mode: fake-ip 会向应用返回保留地址范围中的虚拟 IP，并记录它对应的原始域名。应用连接该虚拟地址时，Clash 恢复域名并执行规则匹配。这种方式通常更容易保留域名信息，也能减少应用先自行解析再连接造成的分流偏差。fake-ip-range 应使用专门保留的地址段，不应随意换成家庭局域网、公司网络或真实公网地址范围，否则可能与已有路由冲突。

部分局域网服务、游戏设备发现、打印机、时间同步或依赖真实地址的应用不适合收到 Fake-IP，可以通过 fake-ip-filter 排除。过滤项不是越多越好：范围过宽会使大量域名退回真实解析，削弱 Fake-IP 对域名识别的帮助。出现某个应用能打开网页却无法发现本地设备时，先从该应用使用的局域网域名入手，而不是直接把所有域名加入过滤列表。

redir-host 返回真实解析结果，兼容路径更接近传统 DNS，但在复杂透明代理环境中可能较难保留原始域名。选择哪种模式取决于客户端、操作系统和网络接管方式。一般桌面与移动图形客户端可先使用其默认模式；只有出现明确的兼容问题时再调整。切换增强模式后，旧 DNS 缓存与连接可能继续存在，测试前应在客户端重启 DNS 模块，必要时清理系统缓存并重新打开目标应用。

Nameserver、Fallback 与引导解析

nameserver 可以填写普通 UDP DNS 地址，也可以填写 DoH 地址。普通地址配置简单，但查询路径取决于本地网络；DoH 使用 HTTPS 传输，需要先解析 DoH 服务器本身的域名，这就产生了引导解析问题。支持相关字段的内核可使用 default-nameserver 提供纯 IP DNS，用于解析其他加密 DNS 的主机名。该列表应填写 IP 地址，不要再次填写需要域名解析的 DoH URL。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query

proxy-server-nameserver 用于解析代理服务器地址。节点的 server 如果填写域名，必须先取得该域名的 IP，才能建立代理连接；此时不能依赖尚未建立的代理通道完成解析，否则会形成循环。为代理服务器准备可直连访问的解析器，可以把“解析节点地址”和“代理普通域名”分开。若订阅节点全部使用 IP 地址，该字段的影响会较小。

fallback 不是简单地把所有查询同时交给第二组服务器。具体选择逻辑会受到内核实现和过滤字段影响。配置 fallback-filter 时，可根据地理数据库、IP 范围或域名判断采用哪类结果，但过度复杂的过滤会提高排错成本。对于基础配置，优先确保一组稳定的 nameserver 能正常工作，再考虑 fallback；如果所有解析器都不可达，增加数量不会解决网络路径问题。

DNS 排错顺序

排查时先确认查询是否进入 Clash，再确认 Clash 能否访问上游，最后检查返回结果如何被规则和连接使用。日志里完全没有目标域名的 DNS 查询，说明系统或应用可能使用了其他解析路径；有查询但持续超时，应检查上游地址、网络防火墙与代理依赖；查询成功但访问失败，则继续查看规则命中、策略选择和目标地址族。不要把所有连接问题都归为 DNS，也不要在未确认链路前频繁更换解析器。

浏览器可能启用自己的安全 DNS，移动系统也可能使用私人 DNS，这些设置会改变查询路径。TUN 接管能覆盖更多流量，但仍需处理系统权限和路由冲突。若问题表现为节点超时、域名偶发失败和系统代理状态混杂，可按从订阅到 DNS 的排查顺序逐层检查。DNS 配置的目标是让解析路径明确、可重复，而不是堆叠尽可能多的上游地址。

CHAPTER 04

代理节点字段

所有节点共有的基础关系

proxies 是节点对象列表。每个对象至少需要名称、协议类型、服务器地址、端口以及该协议要求的认证字段。name 供策略组和界面引用，type 决定后续字段如何解释，server 可以是 IP 或域名，port 必须与服务端监听一致。节点信息通常由订阅提供，不应凭经验把一个协议的字段复制到另一个协议中。

节点能通过 YAML 检查，只说明字段结构可被读取，不代表服务端真实可达。服务器地址错误、端口关闭、认证不匹配、系统时间偏差、TLS 主机名不一致和本地网络拦截都可能造成连接失败。排查时先确认原始订阅是否仍有效，再检查客户端日志中的失败阶段。若多个不同协议节点同时超时，更可能是订阅、DNS、本地网络或系统代理问题，而不是每个节点恰好同时失效。

Shadowsocks 与 Trojan 示例

proxies:
  - name: Example-SS
    type: ss
    server: ss.example.net
    port: 8388
    cipher: aes-128-gcm
    password: your-password
    udp: true

  - name: Example-Trojan
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net
    skip-cert-verify: false
    udp: true

Shadowsocks 的 cipher 必须与服务端一致，不能只根据客户端支持列表随意更换。password 应作为字符串处理，含特殊字符时加引号。udp 表示允许该节点承载 UDP，但最终能否使用还取决于服务端、网络路径和客户端运行模式。只有系统代理时，许多 UDP 流量不会自然进入代理；TUN 或透明代理环境才更常涉及 UDP 接管。

Trojan 通常通过 TLS 连接，sni 用于指定握手中的服务器名称。节点 server 写 IP、证书却签发给域名时，正确的 SNI 尤其重要。skip-cert-verify: true 会跳过证书验证，不应被当作通用修复办法；若打开后才能连接，应继续检查服务器名称、系统时间、证书链和订阅字段是否正确。保持验证开启，才能发现握手目标与证书身份不一致的问题。

VMess 与 VLESS 的传输字段

proxies:
  - name: Example-VMess
    type: vmess
    server: vmess.example.net
    port: 443
    uuid: 11111111-2222-3333-4444-555555555555
    alterId: 0
    cipher: auto
    tls: true
    servername: vmess.example.net
    network: ws
    ws-opts:
      path: /proxy
      headers:
        Host: vmess.example.net

  - name: Example-VLESS
    type: vless
    server: vless.example.net
    port: 443
    uuid: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
    network: tcp
    tls: true
    servername: vless.example.net
    udp: true

VMess 与 VLESS 都会使用 UUID，但两者不是同一种协议。WebSocket 传输还需要核对 network、路径和 Host；服务端要求特定路径时，少一个斜杠或大小写不同都可能导致握手失败。TLS 字段名称在不同配置格式与内核分支中可能存在差异，订阅生成的结构应优先保留，不要为了“统一格式”批量改名。配置检查能识别未知字段，却不能验证远端反向代理是否按相同路径转发。

当节点使用 gRPC、HTTP/2、Reality 或其他扩展传输时，会出现额外的服务名、公钥、短标识或流控字段。这些字段必须成套来自服务端配置。缺少其中一项时，有时仍能通过语法检查，但握手无法完成。手工迁移节点时，应按一个完整对象迁移，不要只复制 server、port 与 UUID 三项。不同内核对扩展协议的支持也会变化，图形客户端应选择与订阅要求相符的内核。

DIRECT、REJECT 与内置出口

DIRECT 和 REJECT 是常用内置策略，不需要在 proxies 中声明。DIRECT 让流量直接连接，REJECT 拒绝连接。它们可以出现在策略组的 proxies 列表，也可以直接写在规则末尾。使用时仍要注意名称是否被订阅中的自定义节点占用，不要创建名为 DIRECT 的普通代理节点，以免阅读和排错产生歧义。

有些配置还会使用兼容、拒绝丢包或 DNS 相关的内置类型，其支持情况应以当前内核为准。为了让配置能在 Clash Plus、Clash Verge Rev、FlClash 等客户端之间迁移，基础文件宜优先使用常见字段，将特定内核扩展放到独立覆写中。移动端与桌面端的系统接管方式不同，但节点对象本身应尽量保持一致，差异主要放在端口、TUN、DNS 监听和界面设置中。

节点故障的分层判断

延迟测试失败不一定表示所有业务连接都失败，延迟测试地址也不等同于实际访问目标。应先查看是 DNS 解析失败、TCP 连接超时、TLS 握手错误还是认证被拒绝。解析失败检查 server 与代理服务器 DNS；连接超时检查网络与端口；TLS 错误检查 SNI、系统时间和证书；认证失败则回到订阅信息。不要先删除整个客户端配置，因为这样会丢失能够说明问题的日志和当前字段。

手工节点适合测试和理解字段，长期节点列表更适合由订阅提供器管理。订阅更新能够统一处理节点增删，但本地策略组与规则仍需稳定引用。下一章会说明如何把节点放入策略组，第七章则说明如何通过 proxy-providers 加载远程节点。若首次导入后不知道如何选择和验证节点，可先阅读首次连接教程。

CHAPTER 05

策略组字段与选择逻辑

策略组是规则与节点之间的中间层

proxy-groups 把多个代理节点、其他策略组和内置出口组织成一个可引用名称。规则通常不直接指向某个具体节点，而是指向“节点选择”“自动选择”“流媒体”等策略组。这样节点发生变化时，规则不必逐条修改，只需要调整策略组成员或当前选择。策略组也能嵌套，但必须避免循环引用，例如 A 包含 B、B 又包含 A，会让配置关系无法成立。

最常用类型是 select、url-test、fallback 与 load-balance。Select 由用户明确选择一个成员；URL-Test 定期测试并选择符合条件的成员；Fallback 按顺序寻找可用成员；Load-Balance 在多个成员间分配连接。不同类型解决的问题不同，不能简单把“自动”理解为一定更快。延迟测试只反映测试目标与当时网络，实际服务可能走不同路径。

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - 故障转移
      - Example-Trojan
      - Example-SS
      - DIRECT

  - name: 自动选择
    type: url-test
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: 故障转移
    type: fallback
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300

Select 与自动测试组

select 的优点是结果明确。用户在界面中选定节点后，策略保持该选择，适合需要固定出口、登录状态或特定地区的服务。缺点是节点失效时不会自动替换，必须手动选择。把自动测试组作为 Select 的第一个成员，可以同时保留自动与手动入口：日常选择“自动选择”，需要固定线路时再切换到具体节点。

url-test 使用 url 发起可达性测试，interval 控制周期，tolerance 用于避免多个延迟接近的节点频繁切换。测试间隔过短会产生持续请求，也可能让界面选择不断变化；间隔过长则不能及时发现故障。测试 URL 应返回简单、稳定的响应，不要使用需要登录、重定向复杂或本地网络经常拦截的页面。测试成功也只代表该节点能访问测试目标。

fallback 更强调成员顺序。第一个成员可用时通常保持使用，失败后再切换后续成员，适合有明确主备关系的线路。它与 URL-Test 的区别不在于是否测试，而在于选择原则：URL-Test 偏向测试结果，Fallback 偏向顺序与可用性。需要稳定会话时，频繁在节点间变化可能引发登录状态或地址变化，因此主备组往往比追求最低测试值更合适。

负载均衡与会话一致性

load-balance 可以让不同连接分配到多个节点，但并不等于把单个下载任务的带宽相加。一个网页会建立多个连接，这些连接可能从不同出口发出；若目标服务要求同一会话保持相同来源地址，分散出口可能造成验证码、登录失效或请求被拒。支持相关策略字段的内核可采用一致性哈希，让相同目标更稳定地落到同一成员，但仍需根据业务验证。

  - name: 均衡出口
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - Example-Trojan
      - Example-SS
    url: https://www.gstatic.com/generate_204
    interval: 300

负载均衡更适合多个独立目标或多个独立连接，不宜作为所有规则的默认出口。配置前应先确认每个成员都能独立工作，且地区、访问权限和协议能力相近。把差异很大的节点放入同一组，会让同一服务的表现难以重复。若只是希望节点故障时自动切换，Fallback 通常更符合需求。

通过节点名称筛选成员

使用 proxy-providers 时，策略组可通过 use 引入整个提供器，再用 filter 或 exclude-filter 按名称筛选。筛选通常使用正则表达式，应先观察订阅中的真实命名。把筛选规则写得过于依赖某个符号或固定前缀，订阅服务调整名称后，策略组可能突然变空。较稳妥的方法是从简单关键词开始，并为重要组保留手工可选入口。

proxy-groups:
  - name: 香港节点
    type: select
    use:
      - remote-nodes
    filter: '(?i)香港|HK|Hong Kong'

  - name: 节点选择
    type: select
    proxies:
      - 香港节点
      - DIRECT
    use:
      - remote-nodes

正则表达式中的括号、竖线与特殊字符应放在引号中。筛选结果为空时，先检查提供器是否加载成功，再检查名称是否匹配，不要直接判断订阅没有节点。客户端界面若能显示提供器原始节点列表，可以复制一两个名称进行最小测试。名称筛选只是管理手段，不应被当成节点质量判断依据；“高速”“专线”等名称文字不能证明线路状态。

策略组层级的维护原则

规则最外层宜引用少量稳定策略，例如“节点选择”“直连服务”“拦截规则”。地区组、自动组和具体节点放在这些策略下面。层级过深会让界面选择路径复杂，也让规则命中后难以追踪最终出口。一般两到三层足以表达“业务策略—地区策略—节点”的关系。每增加一层，都应能回答它解决了什么选择问题。

修改策略组后，应检查三个方向：所有成员是否存在、规则引用的策略是否存在、策略之间是否形成循环。订阅更新还可能删除已被手工组引用的具体节点，所以长期配置更适合通过提供器和筛选引用，而不是把远程节点名逐个复制进本地文件。若客户端显示策略组但无法展开，通常应先检查空组、引用错误和提供器加载状态。

CHAPTER 06

规则语法与匹配顺序

规则从上到下执行

rules 是有序列表。每个连接从第一条开始检查，命中后立即停止，不再继续查看后面的规则。因此规则类型正确但顺序错误，结果仍会偏离预期。范围较具体的规则通常放在前面，范围较宽的规则放在后面，MATCH 作为最终兜底放在末尾。把 MATCH 写在中间，后续规则将永远没有机会执行。

rules:
  - DOMAIN,api.example.com,节点选择
  - DOMAIN-SUFFIX,example.com,节点选择
  - DOMAIN-KEYWORD,example,节点选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

一条常规规则由规则类型、匹配内容和目标策略组成，并用英文逗号分隔。策略名称必须与 proxy-groups 中定义的名称或内置策略一致。中文逗号、末尾多余空格和名称拼写差异都可能导致规则无法按预期加载。规则值中若本身包含逗号，需要确认该规则类型是否支持相应转义，不应直接把复杂文本塞入普通三段格式。

域名规则的差异

DOMAIN 精确匹配完整域名。例如 DOMAIN,api.example.com 只匹配该主机，不自动匹配 www.example.com。DOMAIN-SUFFIX 匹配域名后缀，适合覆盖主域及其子域。DOMAIN-KEYWORD 按关键词匹配，范围最宽，也最容易误伤。能够确定域名边界时优先使用 DOMAIN 或 DOMAIN-SUFFIX，只有目标域名分散且具有稳定关键词时才考虑关键词规则。

域名规则是否可用，取决于内核能否在连接阶段获得域名。应用如果直接连接 IP，或 DNS 查询完全绕过 Clash，DOMAIN 类规则可能没有匹配对象。Fake-IP、TUN 嗅探和系统代理都可能帮助保留域名，但各自路径不同。发现域名规则没有命中时，应先看连接日志里显示的是域名还是 IP，再决定检查 DNS、嗅探或规则本身。

规则覆盖范围需要从业务边界出发。把顶级范围过宽的后缀交给代理，可能让无关服务一起改变出口；只写一个登录域名，又可能遗漏静态资源、接口和内容域名。可通过连接日志观察一次完整操作涉及哪些域名，再把属于同一服务且需要相同策略的域名纳入规则。不要仅凭网页地址栏推断全部请求。

IP、网段与 no-resolve

IP-CIDR 匹配 IPv4 网段，IP-CIDR6 匹配 IPv6 网段。CIDR 后的数字表示网络前缀长度，例如 192.168.0.0/16 覆盖常见的一个私有地址范围。IP 规则适合处理局域网、固定服务器或数据库提供的地址范围，但服务使用动态地址和内容分发网络时，单个 IP 很快可能变化。

no-resolve 表示执行这条 IP 规则时不要为了取得 IP 主动触发额外解析。对于局域网网段和已经以 IP 形式建立的连接，这可以避免不必要的 DNS 查询。它不是所有 IP 规则都必须添加的装饰字段；如果前面的匹配流程确实需要域名解析结果，应理解加入后的影响。排错时可通过日志确认规则看到的是原始 IP、解析结果还是 Fake-IP。

rules:
  - 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
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,节点选择

局域网直连规则通常应位于通用代理规则之前，防止打印机、路由器和内部服务被送往远程节点。但公司网络可能使用与常见私网重叠的复杂路由，TUN 环境还涉及实际路由表。若访问内部地址失败，除了规则，还要检查系统是否把该网段正确路由到本地接口。Clash 只能处理进入它的连接，不能替代缺失的底层网络路由。

GEOIP、规则集合与数据库

GEOIP 根据本地地址数据库判断 IP 所属地区。它的准确度取决于数据库内容和更新状态，不能把每个地址都视为永久不变。服务迁移、内容分发节点变化和数据库滞后都可能造成分类差异。若某个重要服务被 GEOIP 分到错误策略，应为其添加更具体的域名或 IP 规则，而不是等待宽泛地理规则碰巧修正。

较大的规则库适合通过 rule-providers 管理，再用 RULE-SET 引用。这样主配置只保留规则集合的顺序与目标策略，具体条目由提供器更新。需要注意的是，不同规则集合可能有重叠，仍然遵循主配置中的引用顺序。广告拦截、直连域名和代理域名若同时包含相同目标，排在前面的集合会决定最终结果。

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,direct-domain,DIRECT
  - RULE-SET,proxy-domain,节点选择
  - RULE-SET,private-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

排查规则未命中

先在连接日志中找到目标请求，记录它显示的域名或 IP、命中的规则以及最终策略。若命中了一条过宽的前置规则，调整顺序或缩小范围；若直接落入 MATCH，检查规则内容是否与日志对象一致；若命中了正确策略却走了错误节点，则问题在策略组当前选择，不在规则。把这三层分开，可以避免反复改规则却没有改变最终出口。

测试规则时一次只改一个条件，并在修改后确认当前配置已经重新加载。浏览器连接复用、DNS 缓存和应用后台进程可能继续使用旧连接，必要时关闭应用后重试。规则设计应尽量可读：具体例外在前、规则集合居中、地区与最终兜底在后，并用简短注释说明少数特殊项的原因。大量无说明的临时规则会使后续维护越来越困难。

CHAPTER 07

订阅、代理提供器与规则提供器

本地节点与远程提供器的区别

把节点直接写在 proxies 中，适合少量固定节点和临时测试；使用 proxy-providers，则可从远程地址定期更新节点列表，并由策略组通过 use 引用。提供器将“节点数据如何更新”和“节点如何参与策略”分离：远程内容变化时，本地主配置的策略名称和规则不必跟着变化。

提供器不是完整配置订阅的同义词。某些订阅地址返回整份 Clash 配置，其中包含端口、DNS、策略组与规则；proxy-providers 通常需要返回节点集合格式。把完整配置地址直接填入 provider，可能因内容结构不符而加载失败。客户端的普通订阅导入与配置内部的代理提供器也属于不同层级，应先确认服务端提供的文件类型。

proxy-providers:
  remote-nodes:
    type: http
    url: https://config.example.net/nodes.yaml
    path: ./providers/remote-nodes.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 节点选择
    type: select
    use:
      - remote-nodes
    proxies:
      - DIRECT

type: http 表示从远程地址获取，url 是订阅地址，path 是本地缓存位置，interval 是更新间隔。缓存让客户端在短暂无法访问远程地址时仍可读取上次成功内容。路径应位于客户端允许写入的配置目录中，不要指向需要额外系统权限的位置。多个提供器不能共用同一个缓存文件，否则更新时会互相覆盖。

订阅地址通常具有访问权限，应避免写入公开分享的日志、截图和示例文件。本文示例使用不可用于真实服务的示例域名。订阅加载失败时，应查看 HTTP 状态、TLS 错误、响应内容格式和本地文件写入权限，而不是只看策略组是否为空。远程请求成功但内容不是预期 YAML，也会导致解析失败。

健康检查与策略测试

health-check 可以定期检查提供器中的节点是否能访问指定 URL。它与策略组的 URL-Test 有关联但不是同一层：提供器健康检查维护节点可用状态，策略组测试则决定组内如何选择。两处都设置很短的间隔，会产生重复测试。可根据节点数量和使用方式保留合理周期，不必持续高频探测。

健康检查失败可能是节点不可用，也可能是测试 URL 在当前网络或目标地区不可达。若所有节点在同一时刻对同一个测试地址失败，应尝试用实际目标和另一稳定地址交叉验证。测试 URL 返回重定向、验证码或较大页面时也会增加误判。简单的空响应端点更适合可达性检查，但仍不能代替业务访问验证。

规则提供器结构

rule-providers 用于加载可更新的规则集合。常见字段包括行为类型 behavior、格式 format、远程地址、缓存路径和更新周期。behavior: domain 适合域名集合，ipcidr 适合 IP 网段，classical 则可容纳带规则类型的经典条目。主配置中的 RULE-SET 引用必须与集合行为匹配，IP 集合通常还会配合 no-resolve。

rule-providers:
  direct-domain:
    type: http
    behavior: domain
    format: yaml
    url: https://rules.example.net/direct-domain.yaml
    path: ./rules/direct-domain.yaml
    interval: 86400

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    url: https://rules.example.net/private-ip.yaml
    path: ./rules/private-ip.yaml
    interval: 86400

rules:
  - RULE-SET,direct-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,节点选择

Domain 行为的 YAML 内容通常是域名条目列表，IPCIDR 行为则是网段列表。Classical 内容会带 DOMAIN-SUFFIX、IP-CIDR 等完整规则类型。把 Classical 文件声明为 Domain，解析器可能拒绝加载，或者条目无法按预期解释。创建自有规则集时，应先选定行为类型，再按对应格式编写，不要把不同类型混在同一个简化集合中。

更新、缓存与失败恢复

远程更新应视为一次配置变更。节点提供器更新后，当前选中的节点可能被删除或改名；规则提供器更新后，同一域名可能命中不同集合。更新完成后应检查提供器状态、策略组当前选择和关键服务的规则命中。自动更新不等于无需观察，尤其是在本地配置依赖名称筛选时，远程命名变化会直接影响组成员。

提供器拉取失败但缓存仍存在时，客户端可能继续使用旧数据。这种行为有利于保持连接，却也容易让人误以为更新成功。查看状态时应区分“加载了缓存”和“刚刚完成远程更新”。缓存文件损坏时，可以在确认远程地址可用后删除对应单个缓存并重新拉取，不应清空整个客户端目录。清空全部数据会同时丢失策略选择、配置和排错线索。

订阅返回空内容时，不要立即把空结果覆盖到长期使用的本地文件。图形客户端一般会在解析失败时保留旧配置，但不同实现的处理方式可能不同。手工脚本更新时更应先下载到临时文件，通过 YAML 与配置检查后再替换目标文件。这样的“先验证、后替换”流程可以避免网络中断或服务端异常把可用配置变成空文件。

敏感信息与可迁移配置

配置中的订阅 URL、节点密码、UUID 和控制密钥都属于访问相关信息。分享配置用于排错时，应删除这些值，同时保留字段结构、协议类型和错误附近的缩进。单纯把节点名称改掉并不能移除认证信息。日志中也可能出现完整订阅地址，应先处理再发送给他人。

为了提高桌面与移动设备之间的可迁移性，可以把远程节点、通用策略组和规则作为基础层，把端口、控制接口、TUN、DNS 监听地址等设备差异放在覆写层。Clash Plus 作为全平台客户端可从下载页按系统获取；其他客户端对覆写入口和本地目录的呈现方式可能不同，但基础 YAML 的引用关系应保持清楚。

CHAPTER 08

配置覆写、合并与系统排错

为什么需要覆写层

远程订阅通常由服务端维护，更新时会重新生成配置。若直接在订阅文件中增加 DNS、策略组或规则，下次更新可能恢复为远程版本。覆写或合并的作用，是在不修改原始订阅的前提下，把本地长期设置应用到更新结果之上。不同客户端可能把这一功能称为覆写、合并、扩展配置或预处理，界面位置与支持语法并不完全相同。

设计覆写时，应先区分“替换一个值”“向列表追加元素”“删除已有元素”和“按名称修改对象”四种操作。普通 YAML 合并只能表达对象键的覆盖，不能自动理解两个策略组名称相同就应该合并成员。客户端自带的覆写系统可能提供专用规则，但不能假设所有客户端都采用同一语义。迁移配置前应查看实际生成结果，而不是只查看覆写源文件。

映射覆盖与列表替换

映射字段通常按键覆盖。例如基础配置中 mode: rule，本地覆写写 mode: global，最终值一般以后者为准。嵌套映射是否深度合并，则取决于工具：有的只覆盖 dns 中指定的子字段，有的会用整个新 dns 对象替换旧对象。如果覆写后 nameserver 突然消失，往往就是嵌套对象被整体替换。

# base.yaml
mixed-port: 7890
mode: rule
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5

# override.yaml
mode: rule
dns:
  ipv6: false
  fake-ip-filter:
    - '*.lan'

理想的深度合并结果会保留 enable、enhanced-mode 与 nameserver，再加入 ipv6 和过滤项；整体替换结果则只剩覆写中的两个字段。不能仅凭文件名判断是哪一种行为，应在客户端中导出或查看最终配置。首次设置覆写时，选择一个容易观察的非敏感字段进行测试，比一次加入整段 DNS 和策略组更容易确认语义。

列表处理更加需要小心。rules、proxies 与 proxy-groups 都是列表。普通合并工具常把整个列表替换，另一些工具允许前置、后置或按名称插入。若本地规则需要优先于订阅规则，应明确使用“前置规则”能力；简单追加到 MATCH 后面不会生效。若客户端只支持整体替换，则需要完整保留远程规则或改用规则提供器，不能只写新增的几条。

YAML 锚点的适用范围

YAML 锚点可以减少同一文件中的重复字段。例如多个自动策略组使用相同测试地址和间隔时，可以定义公共映射再合并。但锚点只在同一次 YAML 解析中有效，不能跨远程订阅和本地覆写文件自动共享。部分配置处理器还会在生成阶段展开或移除锚点，因此使用前应确认客户端最终能读取。

group-test: &group-test
  type: url-test
  url: https://www.gstatic.com/generate_204
  interval: 300
  tolerance: 80

proxy-groups:
  - name: 自动选择
    <<: *group-test
    proxies:
      - Example-Trojan
      - Example-SS

  - name: 备用自动组
    <<: *group-test
    proxies:
      - Example-SS
      - Example-Trojan

锚点适合减少静态重复，不适合掩盖复杂层级。过度使用会让读者必须来回追踪合并来源，也增加跨客户端迁移难度。需要长期维护的公开配置，宁可保留少量重复，也应让每个策略组的核心行为清楚可见。若锚点展开后的最终配置不易检查，应优先使用客户端明确支持的覆写机制。

按阶段验证最终配置

配置修改应分四个阶段验证。第一阶段检查 YAML 语法，确认缩进、引号和数据类型；第二阶段检查对象关系，确认节点、策略组、提供器和规则引用都存在；第三阶段加载客户端，确认端口、DNS 和控制接口没有与系统资源冲突；第四阶段用实际连接验证规则命中与最终出口。只完成第一阶段，不能说明配置已经可用。

1. 保存基础文件与当前可用状态

   保留原订阅、本地覆写和最终生成配置的副本，并记录修改前能正常使用的策略。恢复时应能回到明确状态，而不是依赖记忆逐项撤销。

2. 一次修改一个配置层

   先改通用字段，再处理 DNS，随后加入策略组和规则。若同时更换节点、开启 TUN 并重写 DNS，出现错误后很难判断是哪一层造成。

3. 查看最终展开结果

   确认覆写后是否仍保留原有列表、同名策略是否被替换、规则是否出现在 MATCH 之前，以及提供器缓存路径是否独立。

4. 按连接链路测试

   依次测试直连、本地代理端口、DNS 查询、单个节点、策略组和规则分流。每一步通过后再进入下一步，避免把所有现象归为节点问题。

常见错误与处理顺序

端口冲突可以通过操作系统网络工具确认。Windows 可在终端中使用 netstat -ano 查看监听端口，macOS 与 Linux 可使用 lsof 或 ss。找到占用进程后，应先判断它是否是另一个正在运行的代理客户端。不要同时开启多个客户端的系统代理和 TUN，否则即使端口各不相同，也可能因路由、DNS 或系统代理反复覆盖而产生循环。

# Windows：查看 7890 端口
netstat -ano | findstr :7890

# macOS：查看 7890 端口
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看监听端口
ss -lntp | grep 7890

从最小配置恢复

复杂配置无法定位时，可以建立一份最小测试文件，只保留一个本地端口、一个已确认可用的节点、一个 Select 策略组和一条 MATCH 规则。先关闭 TUN、自定义 DNS、规则提供器和脚本覆写，验证基础代理链路。基础链路成功后，再按 DNS、提供器、策略组、规则和 TUN 的顺序逐层加回。这样比在数千行配置中随机删改更可靠。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: Test-Node
    type: trojan
    server: edge.example.net
    port: 443
    password: your-password
    sni: edge.example.net

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - Test-Node
      - DIRECT

rules:
  - MATCH,节点选择

最小配置仍失败时，应根据日志判断是本地端口、节点解析、服务器连接还是 TLS 认证问题。如果最小配置可用，而完整配置失败，问题就在后来加入的某一层。每加回一层都保存一次可用状态，就能得到清晰的二分边界。需要更多现象对应的处理方法，可查看疑难解答；若尚未完成安装和首次订阅导入，则返回快速上手按主线操作。

长期维护建议

稳定配置不以字段数量衡量，而以关系清楚、更新可控和故障可恢复为标准。基础层保存通用端口、DNS 与少量稳定策略；远程层负责节点和大型规则集合；设备层负责 TUN、监听地址和系统差异；覆写层只存需要长期保留的本地变化。每一层都应能单独说明来源和作用。

订阅或规则库更新后，重点检查提供器状态、空策略组、当前节点和关键规则命中。客户端升级后，先用配置检查确认高级字段仍受支持，再启用日常配置。遇到问题时保留日志、最终展开配置和最小复现片段，不要在多个配置文件之间来回切换而不记录结果。按照“语法—引用—端口—DNS—节点—策略—规则—系统接管”的顺序检查，通常能够把问题缩小到明确层级。