Clash 配置字段

一、YAML 结构与配置加载

先区分配置文件和运行状态

Clash 配置文件描述监听端口、解析方式、可用代理以及流量选择规则。它不是节点列表的另一种名称：只有节点而没有策略组与规则，通常还不足以构成符合预期的分流方案。图形客户端负责导入、保存与启动，内核负责读取生成后的配置并处理连接。编辑器里看到的订阅原文、客户端保存的本地配置和内核实际读取的文件，可能是三个不同的内容层。

开始修改前，先在客户端的配置页面确认当前启用项，再查找编辑、查看运行配置或打开配置目录等入口。不同客户端的名称可能不同，但目标相同：确定此次修改会作用于哪份文件。不要仅凭文件名判断，名为 config.yaml 的文件也可能只是缓存或启动模板。修改未生效时，首先确认配置是否已重新加载，而不是立即怀疑字段失效。

缩进、映射和列表

YAML 用缩进表达父子关系，建议每层使用两个空格，不使用制表符。冒号后留一个空格表示键与值，短横线加空格表示列表项。顶层的 dns、proxies、proxy-groups 和 rules 各自属于不同段落；缩进错误有时仍能被解析，却会把字段放到错误层级，因此通过语法检查只是第一步，还需要确认结构含义。

# 本地直连基础配置：用于检查结构和监听端口
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,Proxy

这份配置没有远程代理节点，策略组只有内置的 DIRECT，因此所有流量最终直连。它适合排除复杂订阅的干扰，但不能用来验证远程代理服务是否可用。后续添加节点时，需要同时把节点名称加入策略组，再确认规则指向该组。只在 proxies 段增加一条记录，并不意味着现有流量会自动选择它。

字符串、布尔值与同名字段

数字端口通常直接写成整数，开关使用 true 或 false。包含井号、冒号加空格、特殊前缀或容易被识别成其他类型的文本，建议使用引号包住；密码也建议按字符串处理。井号在合适位置表示注释，注释不会参与运行。规则中的逗号属于规则字符串内部语法，不是 YAML 的键值分隔符，不能把整条规则随意拆成多个字段。

同一映射层级不要重复定义相同键。例如前面已经写过 dns，文件末尾又写一个 dns，这不是可靠的合并方式：解析器可能拒绝，也可能只保留其中一段。应当把子项放进同一个映射。节点名、策略组名与引用字符串也要逐字一致，全角空格、末尾空格以及大小写差异都可能造成找不到引用对象。

建立能够回退的编辑流程

先保存原配置副本，再只改一个功能点，保存并重新加载后查看日志。如果客户端支持测试配置，优先使用内置入口；使用命令行内核时，可执行下面的结构检查。命令中的程序名和路径需要与本机实际位置一致，检查过程不替代网络测试，也不会证明节点凭据正确。测试失败时从第一条明确错误开始处理，后续报错可能只是连锁结果。

mihomo -t -f ./config.yaml

本手册中的字段以 mihomo 的常用配置方式为主。原版 Clash、历史分支和不同图形客户端可能存在兼容差异，不能把一份适用于当前内核的配置直接认定为所有客户端都支持。需要先辨认内核与界面项目时，可阅读Clash、Clash Meta 与 mihomo 的生态关系，再决定保留哪些字段。

二、端口、模式与通用字段

监听端口决定流量从哪里进入

port 用于 HTTP 代理监听，socks-port 用于 SOCKS 代理监听，mixed-port 在同一个端口接收两类代理请求。一般桌面使用场景只保留混合端口即可，是否同时设置其他入口取决于应用需要。端口号只是本机入口，不是远程节点服务器端口；浏览器连接本机代理后，内核才会依据策略选择真正的远程出口。

修改端口后，要同步更新客户端的系统代理设置或应用内代理地址。出现地址已被使用的错误，说明另一个进程已经占用相同监听组合，也可能是旧内核进程没有退出。应先查看正在运行的客户端与日志，停止重复实例，再决定是否换端口。随意更换端口却保留旧系统代理地址，会表现为内核启动正常但网页无法连接。

三种模式不是三种网络开关

mode: rule 按规则顺序决定连接去向；global 使用全局策略选择；direct 让内核接管到的连接直连。这里的范围始终是已经进入内核的流量，而不是设备上所有网络请求。只开启规则模式但没有设置系统代理、应用代理或合适的流量接管方式，浏览器请求可能根本没有进入内核，自然也看不到规则命中。

mixed-port: 7890
allow-lan: false
bind-address: "127.0.0.1"
mode: rule
log-level: info
ipv6: false

profile:
  store-selected: true

示例把监听限制在本机，并保存策略组选择状态。客户端可能在启动时依据界面选项重新写入这些字段，因此界面显示的模式与订阅原文不一致时，应查看最终运行配置。模式切换也不一定重建已有连接，验证新选择时应新建请求，必要时在客户端连接页面关闭旧连接。三种模式的场景差异可参阅规则、全局与直连模式说明。

局域网共享与控制接口

allow-lan: true 允许其他设备接入，但仍需结合 bind-address、系统防火墙和所在网络的隔离设置判断。只想在本机使用时，保持关闭更容易控制访问范围。确实需要共享给手机或其他电脑时，连接目标应是运行客户端设备的局域网地址，而不是其他设备自己的回环地址；同时应限制可信来源，并按需要配置代理认证。

external-controller 是供面板或客户端调用的管理接口，与混合代理端口用途不同。管理接口可以改变策略、读取连接信息，通常应绑定回环地址并由客户端管理认证。不要为了让网页恢复访问，把控制端口填进系统代理设置；也不要把它直接开放到公共网络。代理入口的认证与控制接口认证属于不同机制，不能相互替代。

日志、IPv6 与流量接管边界

日常使用可从 info 级别开始，排错时临时提高详细程度，确认问题后再恢复。日志过多会增加阅读负担，也可能包含目标域名与连接信息，分享前应移除订阅地址和敏感内容。顶层 ipv6 与 DNS 段中的同名开关作用层面不同，不应只修改一个字段便推断整个设备的 IPv6 已经关闭，更不能替代系统网络设置检查。

TUN 是另一套流量接管入口，涉及虚拟网卡、路由、权限和 DNS 劫持，并非设置混合端口后自然生效。桌面客户端、移动端系统接口以及服务器命令行环境也不能使用同一套授权步骤。初次配置建议先让普通代理入口工作，再独立验证 TUN。这样出现权限或路由问题时，可以保留一个已知可用的连接路径，避免同时修改多个层面后无法定位。

三、DNS 与 Fake-IP 字段

先确认域名由谁解析

DNS 配置决定内核怎样把域名转换成地址，以及如何保留域名与连接之间的关联。浏览器、操作系统、应用自身和内核都可能参与解析，因此写入 dns.enable: true 并不等于全设备请求已经交给内核。系统代理下部分域名可随代理请求传入，TUN 场景则常需结合 DNS 劫持与系统路由；应用自带的加密解析也可能走另一条路径。

dns.listen 是内核提供 DNS 服务的监听地址，不是上游解析服务器。即使监听在本机某个高位端口，系统也不会自动发现它；需要客户端或网络配置把查询送到这里。下面示例用于说明字段关系，不包含 TUN 接管设置。示例中的加密解析地址是否可达取决于当前网络，配置时应选用能够稳定访问、并符合使用环境要求的解析服务。

dns:
  enable: true
  listen: "127.0.0.1:1053"
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"

Fake-IP 保留域名关联

enhanced-mode: fake-ip 会向应用返回一个用于映射的地址，随后内核根据映射还原域名并选择策略。这个地址不是目标网站真实服务器地址，因此在系统查询结果里看到它，不代表解析被污染。关键在于后续连接是否仍回到持有映射的内核。如果 DNS 请求由一个实例处理、连接却发给另一个实例，就可能出现地址存在但无法正确访问的情况。

fake-ip-range 是分配池，不是远程节点地址，也不是建议添加到绕过代理名单的网段。与本地网络、虚拟网卡或其他工具的路由发生冲突时，需要整体检查，而不是任意改一个看起来空闲的范围。切换 DNS 模式或重启内核后，应用可能仍缓存旧映射；此时应重新建立连接，必要时清理应用和系统的相关缓存，再判断修改效果。

fake-ip-filter 用来列出不适合返回映射地址的域名，例如部分局域网名称或需要真实地址工作的服务。加入列表不等于这些连接必定直连，实际出口仍由规则决定。过滤范围过大，会改变大量域名的解析路径并增加排错难度。发现某个服务异常时，应先确认它是否依赖真实地址，再添加尽量具体的域名，而不是直接排除所有域名。

上游、引导与节点域名解析

default-nameserver 主要用于解析 DNS 上游服务器自身的域名，解决加密解析地址尚未有地址可连的问题。nameserver 是常规查询使用的上游，两者不能仅按名称理解成完全等价的候选列表。若上游地址带有域名，网络启动阶段就需要可用的引导解析；引导阶段失败时，后面的加密解析往往也无法建立。

当远程代理节点的服务器地址也是域名时，还需要考虑节点域名如何解析。mihomo 提供 proxy-server-nameserver 等相关字段，可为节点服务器解析指定上游。若把访问解析服务的流量交给代理，同时代理连接又依赖该解析服务得到节点地址，就可能形成循环依赖。先让节点域名能通过独立可达的路径解析，再安排其他查询走代理，通常更容易稳定启动。

nameserver-policy 可以按域名或受支持的匹配写法指定解析上游，适合处理内部域名与公共域名需要不同解析器的情况。它决定的是解析请求去向，不是业务连接出口；业务流量仍需由 rules 决定。使用与规则联动的 DNS 选项前，应先确认代理服务器解析路径完整，避免把 DNS 策略和流量策略互相引用成闭环。

按现象缩小 DNS 故障范围

只有局域网服务失败，先查过滤列表与内部解析器；全部域名都失败，先看上游是否可达以及监听端口是否收到查询；地址可以获得但连接失败，再查规则与出口。不要把所有超时都归因于 Fake-IP，端口错误、节点认证失败和远程拒绝连接也会产生类似表象。可结合已连接却打不开网页的排查清单，把入口、解析和出口分开验证。

四、代理节点与协议参数

公共字段与协议字段分开理解

proxies 是静态节点列表，每一项描述一个远程连接方式。常见公共字段包括显示名称 name、协议类型 type、服务器地址 server 和远程监听端口 port。这里的端口由服务端提供，与本机混合端口没有对应关系。名称用于策略组引用，服务器字段用于真正拨号，不应把订阅链接或面板登录地址填进服务器字段。

不同协议的认证与传输字段不能互相套用。Shadowsocks 常见的是加密方法和密码，Trojan 使用密码并依赖 TLS，其他协议可能使用用户标识、流标记或特定传输参数。服务提供方给出什么协议，就按该协议支持的字段填写。仅把 type 改成另一个值，不会把已有节点转换成另一种协议，还可能产生看似可加载但必然无法握手的配置。

proxies:
  - name: "示例 SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "示例 Trojan"
    type: trojan
    server: trojan.example.com
    port: 443
    password: "your-password"
    sni: trojan.example.com
    skip-cert-verify: false
    udp: true

以上是字段写法示意，域名和口令不能用于实际连接。尤其不要根据端口是常见的安全端口，就推断服务一定使用某种协议或加密方式。服务器可以在自定义端口运行，关键是客户端与服务端的协议、认证、传输和 TLS 参数必须一致。凭据应从可信的服务配置中获取，不要根据分享截图猜测缺失字段。

TLS 名称与服务器地址

服务器地址决定连接目标，TLS 名称则参与握手与证书名称验证，两者可能相同，也可能由服务端要求分别填写。Trojan 示例里的 sni 不能因为连接失败就随意改成常见网站域名。对于使用 servername 等不同字段名称的协议，应按该协议定义填写，而不是把所有 TLS 名称字段同时堆上去，期待内核自行判断。

skip-cert-verify: false 表示保留证书验证。遇到证书错误，应先检查设备时间、服务器名称、证书有效性和服务提供方参数。直接关闭验证虽然可能改变错误表现，却会绕过原本用于识别服务器的保护，不能作为常规修复步骤。若确实是私有环境的证书部署，应先明确证书信任链如何建立，再选择合适的客户端配置方式。

传输层、UDP 与解析链

部分协议还需要 network、ws-opts、grpc-opts 等传输设置。路径、请求头和服务名称属于服务端约定的一部分，不能仅凭域名相同就省略。WebSocket 的路径与普通网站页面地址也不是同一概念。出现握手失败时，可先核对服务提供方原始参数，确认没有在订阅转换、复制或客户端导入时丢失传输配置。

udp: true 表达节点允许处理相应 UDP 流量，但不保证整个链路都已支持。应用入口、接管方式、远程协议能力、服务器配置和网络防火墙都会影响结果。网页可打开而语音或游戏失败时，应分别检查流量是否进入内核以及远程出口是否支持所需传输，不能只反复切换节点上的 UDP 开关。某些基于 UDP 的代理协议还依赖底层网络允许相应连接。

节点服务器使用域名时，需要先完成域名解析才能建立远程连接。若日志显示节点名称正确，但服务器地址解析失败，应回到 DNS 章节检查节点解析上游；若已经连接到地址后出现认证拒绝，再核对口令与协议。把错误按解析、连接、握手、认证、业务请求分层阅读，比笼统地判断节点不可用更有帮助，也更容易向服务提供方说明现象。

节点维护与信息边界

同名节点会让引用关系变得含糊，更新订阅时尤其容易出现旧名称残留。静态列表中的每个名称应保持唯一，重命名后同步检查策略组和规则引用。需要动态维护大量节点时，优先使用后文的代理集合，而不是手工复制整段列表。准备更换客户端可到下载页按系统选择，常规图形客户端优先考虑 Clash Plus，并先确认所需协议能够被实际内核支持。

五、策略组与出口选择

策略组把节点组织成可引用目标

proxy-groups 为规则提供稳定的目标名称。规则可以一直指向 Proxy，用户则在组内更换节点，不必逐条修改域名规则。组内候选项既可以是具体节点，也可以是其他策略组或内置策略。理解时可把它看成一张有方向的引用图：请求先命中规则，再进入一个组，沿组的当前选择找到最终出口，而不是所有组同时处理同一连接。

select 用于手动选择，适合总入口、工作场景或需要明确固定出口的服务；url-test 根据探测结果自动选择候选；fallback 按候选顺序寻找可用项；load-balance 按支持的策略分配连接。自动组并不是给所有用户都适用的默认答案，是否允许出口变化、是否需要保持会话、节点是否来自同一服务环境，都应纳入选择。

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 自动选择
      - DIRECT

  - name: 自动选择
    type: url-test
    proxies:
      - "示例 SS"
      - "示例 Trojan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - MATCH,Proxy

示例依赖上一章定义的两个节点，单独复制策略组并不能运行。探测地址只是可用性检测目标，不是代理服务器，也不是某个业务网站的完整替代测试。若该地址在当前网络不可达，所有候选都可能被误判。应选择适合使用环境、响应稳定的探测目标，并确认探测本身经过预期节点完成，而不是用应用页面加载时间直接解释组内选择结果。

自动探测字段的实际作用

interval 通常以秒为单位设置探测间隔，tolerance 在自动选择中用于减少因小幅差异而频繁切换。间隔并非越短越好，过于频繁的探测会增加请求与功耗，移动设备尤其需要注意。部分自动组还支持惰性检测等选项，实际触发行为应以对应组类型和内核实现为准，不应期待未被使用的所有组始终按同样频率执行检测。

探测通过只说明节点能够访问该检测目标，不能证明所有网站、所有协议和所有账户会话都能正常工作。某个业务受地区、登录状态或出口限制影响时，应从实际业务的新连接验证。自动选择更换出口后，旧连接也可能继续保持原路径，因此同一时间观察到多个出口并不一定是配置冲突，而可能是连接生命周期不同造成的正常现象。

组间嵌套与引用约束

嵌套组适合把人工决策与自动选择分开，例如总入口在自动组与直连之间手动切换，自动组内部再选择节点。不要让两个组互相引用，也不要让一个组把自己作为候选，这会形成循环。排查名称错误时，从规则目标开始逐层查找：目标组是否存在、候选组是否存在、最终节点是否存在，直到找到真正能够连接的叶子项。

通过 use 可以让策略组从代理集合引入候选，通过 filter 可以筛选名称。过滤表达式是匹配条件，不是节点分类标签；订阅改名后，过去有效的筛选可能得到空集合。自动组没有候选时，应先查看集合是否加载和过滤是否过严，而不是提高检测频率。维护时可先取消过滤确认候选存在，再逐步缩小匹配范围。

保存选择不等于固定一切流量

profile.store-selected 可用于保存手动组的选择，但客户端可能有自己的状态持久化方式。更新配置后组名改变，旧选择未必还能对应到新组；候选节点被删除，也可能触发回退。需要固定某个服务出口时，应保留稳定的组名与节点名，并把该服务规则放在通用规则前。不要只看界面上总组的选择，因为更具体的规则可能指向另一个独立组。

内置 DIRECT 表示直连，REJECT 表示拒绝，并不是需要手工定义的远程节点。把直连加入自动检测组前，应考虑它是否会因为探测容易成功而长期被选中，从而偏离原本的代理目的。对自动选择结果不确定时，先在手动组固定一个已知可用的节点，确认业务恢复，再逐项恢复自动策略，这样能区分节点问题与组逻辑问题。

六、规则语法与匹配顺序

从上到下，首次命中即停止

rules 是有顺序的规则列表。内核按照列表先后检查连接，首次命中后交给对应策略，不会继续寻找更具体的下一条。因此专用域名规则通常放在前面，宽泛的地址规则靠后，最终用 MATCH 接住未匹配流量。将兜底放到开头会让后面大量规则失去作用，这种问题即使语法检查通过，也会导致实际分流与预期完全不同。

常见写法是规则类型、匹配内容、目标策略三个部分，以英文逗号分隔。MATCH 没有匹配内容，因此只带目标策略。目标可以是节点、策略组或内置策略，但必须能被内核找到。若名称中混入全角标点、不可见空格或复制时多出的引号，可能出现引用失败；规则列表本身建议按功能分段并添加简短注释，方便后续维护。

rules:
  # 局域网名称与私有地址
  - DOMAIN-SUFFIX,lan,DIRECT
  - 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

  # 示例域名交给 Proxy
  - DOMAIN-SUFFIX,example.com,Proxy

  # 需要可用的地理地址数据库
  - GEOIP,CN,DIRECT

  # 所有未命中连接
  - MATCH,Proxy

域名规则与地址规则

DOMAIN 匹配完整域名，适合只处理一个主机；DOMAIN-SUFFIX 匹配指定域名及其子域名；DOMAIN-KEYWORD 匹配域名中的关键词，范围更宽，容易命中并非目标服务的域名。想覆盖一个服务时，不宜仅因为名称相似就使用短关键词。服务也可能依赖多个域名，主页命中预期规则，并不代表登录、图片和接口请求都采用同一出口。

IP-CIDR 按地址网段匹配，IPv6 网段通常使用 IP-CIDR6。业务最初以域名进入时，某些地址规则可能需要解析后才能判断。尾部的 no-resolve 用于避免仅为该地址规则主动触发解析，但它不会清除已经存在的目标地址，也不保证该连接永远不经过其他解析流程。把它机械地加到所有规则后面，可能改变原本希望依赖地址匹配的行为。

GEOIP 与 GEOSITE 依赖相应数据资源，使用前应确认内核已经加载支持的数据。地域或站点类别是数据维护者给出的分类，不是对服务归属、实际服务器位置或访问效果的永久保证。分类不符合具体业务时，可以在前面补充更准确的域名规则，而不是在系统中同时叠加多套互相矛盾的宽泛规则。

进程规则和入口信息的边界

mihomo 还支持进程名、进程路径等规则类型，但能否获得进程信息取决于系统、权限、接管方式和查找设置。桌面本机应用可能能够识别进程，来自局域网另一台设备的代理请求则通常不能提供那台设备的完整进程信息。规则写法正确但没有命中时，应先确认连接日志中是否真的存在需要匹配的信息，而不是直接判断规则类型不可用。

应用名称与实际发起连接的进程名称也不一定相同。浏览器辅助进程、更新服务以及后台组件都可能独立连接，因此不要仅凭窗口标题填写进程规则。若涉及工作应用的固定出口，可先使用明确的业务域名验证，再评估进程规则是否能覆盖剩余连接。复杂逻辑规则应在基础分流已验证后引入，并保留能够单独测试的简单条件。

用连接记录验证规则

验证时先确认正在使用规则模式，再打开客户端的连接或日志页面，新建一个目标请求，查看命中的规则和最终策略链。只观察网页是否打开，无法判断它是按规则代理、直连，还是由已有连接缓存完成。改变规则后也应重新建立连接，必要时关闭目标应用的长连接；否则会把旧连接继续使用原出口误认为规则没有更新。

出现误命中时，先检查上方是否存在更宽的规则，再检查域名是否来自预期信息源，最后核对目标组的当前选择。不要直接把整个配置改成全局模式当作永久修复，那只能帮助区分规则路径与出口是否相关。若全局模式可用而规则模式失败，应沿着命中记录调整具体规则，相关模式区别见代理模式说明。

规则集中的顺序同样重要，而主配置里引用规则集的位置决定它与其他规则谁先参与匹配。维护个人例外时，可以把少量稳定规则放在公共规则集前，再保留清晰的兜底。每次新增一条都应考虑它会覆盖哪些已有规则，尤其是关键词、地域和全端口条件。能用精确域名解决的问题，通常不需要扩大到整个网络或全部应用。

七、代理集合与外部规则集

把更新资源与主配置分开

proxy-providers 用于声明代理集合，rule-providers 用于声明规则集。两者都能把经常更新的内容从主配置分离出来，但载荷格式不同，不能把完整订阅文件直接当成规则集，也不能把域名清单当成节点列表。主配置负责说明资源在哪里、如何加载和如何引用；资源本身负责提供节点或规则，只有引用关系完整，内容才会参与实际运行。

初次排查建议先使用本地文件，确认格式和引用正确，再接入远程更新。这样可以把网络下载失败与内容解析失败分开。本地路径按内核工作目录及客户端的路径限制解释，不一定相对于当前编辑器打开的位置。某些客户端会把文件复制到自己的配置目录，修改原始文件后不会自动同步，因此应确认运行配置中的路径最终指向哪里。

# 主配置中的相关片段
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: Proxy
    type: select
    use:
      - local-nodes

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,Proxy

代理集合文件应有自己的 proxies 列表；如果服务端返回的是完整配置，能否作为代理集合读取取决于其内容和内核处理方式，不应把所有顶层设置都期待一并应用。最稳妥的做法是让集合只承担节点载荷职责。集合中节点名称变化会影响手动选择与筛选表达式，更新后应再次确认组内候选，而不是只看更新提示成功。

# ./providers/nodes.yaml
proxies:
  - name: "示例 SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

规则集行为必须与内容一致

behavior: domain 适合域名载荷，ipcidr 适合地址网段，classical 使用传统规则类型写法。format 则说明具体文件格式，例如 YAML 或受支持的文本、二进制格式。行为与格式是两个维度，不能把文件扩展名看起来像 YAML 就认定内容一定符合域名规则。解析错误时应打开实际载荷检查，而不是只修改主配置的名称。

# ./rules/direct.yaml
payload:
  - "example.org"
  - "+.example.net"

上面的域名载荷使用适用于域名规则集的写法，其中带加号点号的项用于覆盖域名及其子域名。若使用 classical，载荷中通常写规则类型与匹配条件，例如域名后缀规则，而出口策略在主配置的 RULE-SET 引用处指定。把完整的带策略规则机械搬入集合，容易重复指定目标或产生格式错误，转换前应确认目标行为的要求。

远程更新不只是一个网址

使用 HTTP 类型集合时，一般还需配置下载地址、保存路径和更新间隔；间隔通常以秒为单位。地址必须返回符合预期的资源正文，返回登录页面、访问提示或错误文档也可能在网络层显示成功，但内容无法解析。订阅地址还可能带有个人访问凭据，应只保存在自己的配置中，不要放进截图、公共仓库或公开的问题报告。

每个资源应使用独立的缓存路径，避免两个集合写入同一个文件后互相覆盖。远程更新失败时，内核是否仍可使用缓存，要看缓存是否存在、是否有效以及客户端如何管理。新设备首次导入没有旧缓存，启动失败的表现可能与已经运行很久的设备不同。不能因为一台设备暂时可用，就判断订阅服务器一定没有问题。

代理集合的健康检查用于判断其中节点的可达情况，与策略组的自动选择检测有关但不完全相同。同时开启多处高频检查，可能重复产生探测。应先明确哪一层负责更新、哪一层负责检测、哪一层负责选择，再设置合理间隔。远程资源下载是否通过代理，也要考虑启动时代理节点尚未加载的先后关系，避免资源依赖自身才能下载的循环。

把更新失败分成两类处理

若日志是请求超时、名称解析失败或证书错误，先检查资源获取路径；若已经获取正文却提示字段或载荷错误，先检查内容格式。不要在第二种情况下反复重置网络，也不要在第一种情况下盲目改规则集行为。更多订阅获取场景可参阅订阅更新失败与自动更新设置，修复后重新加载并确认规则命中，而不只是确认下载完成。

八、订阅覆写、合并与排错

区分源配置、覆写与最终配置

订阅更新通常会重新获取源文件，因此直接修改订阅缓存，可能在下一次更新后丢失。覆写的目的，是把个人设置作为独立层保存，再由客户端在生成运行配置时应用。这个过程主要由图形客户端实现，并不是所有内核都存在一个通用的覆写开关。使用 Clash Plus、Clash Verge Rev 或 FlClash 时，应分别确认其配置管理入口和合并方式，不能把一个客户端的脚本直接复制到另一个客户端。

常见层次是远程订阅提供节点与基础规则，客户端补充监听端口、控制接口等运行参数，个人覆写再调整 DNS、策略或例外规则。实际顺序由客户端决定，也可能允许多份覆写依次处理。最终应以运行配置为准，而不是以某一个编辑页面中的文本为准。出现界面设置被覆盖时，先画清这些层次，找出最后写入该字段的一层。

映射合并与列表替换不是一回事

标量字段通常被新值覆盖，映射可能递归合并，列表可能整体替换、追加或按特定规则处理，这些都不是 YAML 文件格式本身替客户端统一规定的行为。尤其是 rules、proxies 和 proxy-groups，如果误把整体替换理解成自动追加，就可能丢失全部订阅规则或节点。保存前必须确认当前入口究竟接受完整配置，还是只接受补丁片段。

# 仅表示期望覆盖的字段，不是通用覆写文件格式
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

profile:
  store-selected: true

上面的片段适合表达修改意图，能否直接粘贴使用要看客户端的覆写说明。如果该入口把整个 dns 映射替换，原来的上游与过滤列表可能被清空；如果递归合并，则未提及字段可能继续保留。操作后应查看最终 DNS 段，确认上游仍然完整。不要把一段简短示例当成可覆盖所有订阅的通用答案，也不要用重复顶层键模拟合并。

规则插入位置需要明确

新增个人规则时，应区分前置与后置。精确例外通常需要放在公共规则之前；兜底只应位于最后。如果客户端只提供列表追加，把个人域名规则追加到现有 MATCH 后面，即使保存成功也不会被执行。应使用客户端支持的前置规则或完整列表替换机制，并在运行配置中找到实际位置。若需要重建列表，必须保留原本仍然需要的规则。

节点和策略组也有依赖顺序上的逻辑约束：新规则引用的组必须存在，组引用的节点或集合必须能够加载，删除节点前要先移除相关引用。改名应视为一次引用迁移，而不是只修改显示标签。自动更新订阅后出现找不到目标，往往是个人规则保留了旧组名。使用稳定的个人组名作为中间层，可以减少上游节点改名对规则的影响，但仍需验证候选是否有效。

按四个阶段验证修改

第一阶段检查解析：缩进、类型、重复键和不支持字段是否导致启动失败。第二阶段检查引用：规则目标、策略组候选、集合名称与资源路径是否存在。第三阶段检查接管：请求有没有进入当前内核、系统代理端口是否一致、TUN 权限与路由是否正常。第四阶段检查网络：节点解析、远程连接、TLS、认证和目标业务是否依次成功。每次只推进一个阶段，避免跳过前面的基础问题。

如果配置能够加载，但请求完全不出现在日志中，应先检查应用代理与接管入口；如果有请求却走错策略，查规则顺序和组选择；如果策略正确但无法连接，再查节点与 DNS。日志中的错误时间也很重要，旧记录不一定代表本次修改仍失败。重新加载后记住时间，发起一个新的测试请求，围绕该请求查看记录，比连续切换多个节点后再回头阅读日志更清楚。

系统休眠、网络切换和客户端异常退出后，还要检查系统代理是否残留、虚拟网卡是否恢复以及旧内核是否仍占端口。切换到另一个客户端前，先退出前一个实例，避免两套接管同时工作。平台安装与权限问题不宜混在配置字段中反复修改；需要重新安装时前往客户端下载页，首次恢复连接则回到快速上手主线。

保留可复现的回退记录

一次修改完成后，保留修改前副本、修改目的和验证结果即可，不必复制所有历史缓存。若问题出现，先回退最近一次变更，确认是否恢复，再逐项重做。分享排错信息时提供所用客户端、内核类别、接管方式、错误阶段和已移除敏感信息的相关片段，不要公开完整订阅。能够说明哪个请求、命中哪条规则、在哪一步失败，比只提供一句无法上网更容易找到原因。