Clash YAML 配置手册

一、YAML 结构与配置生效路径

Clash 配置文件不是逐行执行的脚本，而是一组有层级的数据。顶层字段声明监听方式、代理来源、策略组和规则；内核读取整份文件后建立相应对象。理解这个区别很重要：把一条规则写在文件最后，不代表它最后才被创建；真正影响匹配先后的，是 rules 列表内部的顺序。文件可以叫不同名字，扩展名也可能是 .yml，但客户端实际加载哪份文件，要以当前选中的配置为准。

先辨认映射、列表与字符串

冒号把字段名与值连接起来，冒号后通常需要一个空格；短横线表示列表项。缩进表示从属关系，建议统一使用两个空格，不使用 Tab。下面的 proxies 是策略组里的候选项，不是顶层代理节点列表。两者虽然同名，却处在不同层级。遇到解析错误，应先看报错行前后的缩进，而不是只检查该行的文字。

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

proxy-groups:
  - name: "出口选择"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口选择

这是一份可用于理解结构的直连配置：它会打开混合代理端口，但全部连接最终直连，并不包含远程代理能力。用它确认内核能够读取文件，比一开始就导入复杂规则更容易定位语法问题。列表中的 DIRECT 是内置出站，不需要额外声明。策略组名称必须与规则引用完全相同，空格、标点和大小写差异都可能导致引用失败。

区分订阅原文与运行配置

在 Clash Plus、Clash Verge Rev 等客户端中，远程订阅往往只是配置来源。客户端还可能叠加端口设置、TUN 开关、全局扩展和当前订阅的覆写，最后生成供内核运行的文件。因此，直接修改临时生成文件通常不是持久方案：下一次切换订阅、保存设置或重启，都可能重新生成。应先确认当前编辑的是订阅副本、持久覆写，还是仅用于查看的运行结果。

普通 YAML 文件也能通过语法检查，却不一定符合 mihomo 的字段要求。例如把 proxy-groups 写成一个字符串，通用解析器可以接受，但内核需要的是列表。相反，文件语法正确、结构正确，也不等于节点能连接：域名、认证和远端服务仍需单独验证。排错时把“能读取”“能启动”“能建立连接”分开，能减少反复修改无关字段的情况。

保存前检查三个细节

第一，使用 UTF-8 保存，避免编辑器把中文组名转换成异常字符。第二，包含冒号加空格、井号或特殊标点的字符串应加引号；注释从引号外的井号开始，不属于值。第三，同一级映射不要重复写同名键。不同解析器对重复键的处理可能不同，有的报错，有的只保留最后一项，不能把这种行为当作可靠的合并方法。

调整前保留一份能工作的配置，再复制到测试用配置中修改。若有独立 mihomo 可执行文件，可使用 mihomo -t -f config.yaml 做配置测试；应使用与客户端一致的内核，并确认相对路径依赖所在目录。测试成功后仍要重新加载，并在日志确认当前配置已被接受。订阅返回内容异常时，可进一步阅读订阅解析失败自查清单。

二、通用字段：监听端口与运行模式

通用字段决定内核如何接受本地连接，以及连接进入后是否按规则选择出站。它们不能替代 Windows 系统代理设置：内核监听了端口，只表示端口可供应用连接；是否有应用把请求送过来，还取决于客户端的系统代理开关、应用自己的代理选项或 TUN 接管。遇到浏览器没有变化时，应先检查流量入口，不要立即改节点协议。

port、socks-port 与 mixed-port

不需要为了“完整”同时开启三种代理端口。一般桌面使用，一个混合端口已经足够。端口号可以调整，只要在有效范围内、没有被占用，并且与应用填写的值一致。本文使用的 7897 是示例，不代表每个客户端都采用这个默认值。修改后，原先手动填写旧端口的浏览器扩展、命令行工具和下载器，也要一起更新。

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

这组设置适合仅供本机应用访问的起点。allow-lan: false 表示不为局域网设备提供接入；显式的回环监听地址进一步表达本机用途。若要让手机访问电脑的代理，需要调整相关限制、使用电脑的局域网地址，并在可信网络范围内配置 Windows 防火墙。不要为了排错直接关闭整个防火墙，也不要把本地代理端口映射到公网。

规则模式与策略组是两层设置

mode: rule 让连接依次匹配规则；global 使用全局出站选择；direct 让连接直连。切换全局模式不会修改原有规则文本，只是改变当前路由方式。规则模式下，某条规则可能指向一个选择组，而选择组又指向直连，因此“处于规则模式”不能证明请求一定经过远程代理。验证时要查看实际命中的规则和最终出站链。

客户端界面上的模式按钮可能在运行时覆盖文件值，也可能在重新生成配置时写回。若每次重启都回到另一个模式，应查客户端的持久设置，而不是反复修改订阅。log-level 可在排错时临时提高到 debug，结束后恢复 info；调试日志可能记录域名和连接细节，分享前需要清理订阅地址、认证信息和个人访问记录。

顶层 IPv6 与控制接口

顶层 ipv6 控制内核对 IPv6 的相关支持，与后文 DNS 中的同名字段不是同一个层级。把它关闭不等于关闭 Windows 网卡的 IPv6，也不能单独证明所有应用都已被接管。若网络需要 IPv6，应围绕入口、路由、解析和节点能力整体检查，而不是长期依赖一个关闭开关掩盖路径不一致。

external-controller 是管理接口，不是给浏览器使用的 HTTP 代理端口。客户端通常已经管理其地址和访问认证，不建议在订阅中随意改动。连接面板突然无法显示、但代理仍能使用时，要区分管理接口失联与代理监听失效。查端口占用可在 PowerShell 运行 Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue，结合进程信息确认占用者，不要直接结束不明系统进程。

三、代理节点与订阅提供器

节点定义描述如何连接远端代理服务。顶层 proxies 通常是节点列表，每项包含名称、协议类型、服务器地址、端口及协议专用认证。名称是供策略组引用的本地标识，不会自动变成服务器地址。把节点改名可以改善界面辨识，但必须同步修改显式引用它的组；若订阅更新会重新生成名称，更适合通过提供器或稳定的组结构管理。

共用字段与协议专用字段

server 可以是域名或 IP 地址，port 是服务端实际监听端口，不能把分享链接里任意数字当作它。不同协议的认证方式不同：Shadowsocks 通常使用加密方法和密码，Trojan 使用密码并涉及 TLS，VLESS 则有自己的身份与传输参数。不能只修改 type 就把一个节点转换成另一种协议，服务端必须提供匹配的服务。

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

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

这个片段使用真实的 SOCKS5 字段，但只有本机确实运行了端口为 1080 的 SOCKS 服务时才能转发。它不提供远程节点，也不应指回 mihomo 自己的混合端口，否则可能形成循环。示例选择本机地址，是为了说明数据结构而不引入虚构凭据。实际节点参数应从服务提供者取得，逐项核对，不要用网页示例替换自己的认证信息。

udp: true 表示允许该节点处理相应 UDP 流量，不会让原本不支持 UDP 的服务自动获得能力。协议实现、服务端配置、中间网络和入口接管都可能影响结果。若网页正常但语音或游戏异常，应先确认应用使用的传输方式，再看该节点是否能承载，而不是单纯根据网页可打开就认定整条链路正常。

proxy-providers 是代理集合来源

当配置需要独立更新节点集合时，可以使用 proxy-providers。提供器内容通常是包含 proxies 列表的代理集合，不应把任意完整配置地址直接当成同一种格式使用。HTTP 提供器会获取远程内容，文件提供器读取本地文件；提供器本身不等于策略组，需要由组通过 use 引用。下面以本地文件说明关系，路径应位于内核允许读取的配置目录范围内。

proxy-providers:
  local-pool:
    type: file
    path: ./providers/local-pool.yaml

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

相应的 local-pool.yaml 应包含节点列表，而不是再套一层 proxy-providers。相对路径通常以运行目录或内核工作目录为依据，不一定以当前编辑器打开的文件夹为依据。出现文件不存在时，应查客户端展示的配置目录与内核日志；不要把文件随意移入系统目录，也不要为了绕过路径限制扩大整个磁盘的访问权限。

连接失败按层次检查

先检查服务端域名能否解析，再确认目标端口是否可达，随后核对认证、TLS 名称和传输参数。TLS 中用于验证证书的名称不一定等于连接地址，必须按服务端要求填写；遇到证书错误，优先检查系统时间、证书链和名称，不要把跳过证书验证当作日常修复。连接超时与认证拒绝是不同阶段的问题，日志中的错误类型比反复换端口更有参考价值。

订阅地址往往带有访问凭据，截图、日志和公开问题中都应隐藏完整链接。更换客户端前先保留订阅来源，再从客户端页面选择对应平台；本站首推 Clash Plus，也提供 Clash Verge Rev 等选择。不同图形客户端对扩展字段的处理不完全一致，迁移时需核对内核支持范围，可结合mihomo 与原版内核差异理解字段来源。

四、策略组：选择、测速与回退

策略组位于规则与具体节点之间。规则可以指向组，组再决定使用哪个节点，也可以指向另一个组，从而形成有层次的出站结构。这样更新节点集合时，不必同步修改所有域名规则。组名应短而稳定，尽量表达用途，例如“工作出口”“媒体出口”；名称本身不会带来特殊行为，真正决定算法的是 type 与相关字段。

select 适合需要明确控制的场景

select 是手动选择组，用户在客户端界面决定当前候选项。它可以包含节点、其他组以及 DIRECT 等内置出站。首次加载时的选择结果与客户端是否保存历史选择有关，不能只根据列表第一项推断当前出口。修改完配置后，应到代理页面实际确认一次，尤其是组曾经选中过直连、旧节点或已经被删除的候选项时。

proxy-groups:
  - name: "自动回退"
    type: fallback
    proxies:
      - "本机 SOCKS 入口"
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: "出口选择"
    type: select
    proxies:
      - "本机 SOCKS 入口"
      - "自动回退"
      - DIRECT

该片段引用上一章定义的本机节点，不能单独替代整份配置。fallback 按候选顺序选择可用出口，示例特意把直连放在最后，便于说明回退行为。如果业务要求远端代理中断时停止访问，就不应把 DIRECT 放进回退组。配置中的可用性与隐私目标是两回事，回退成功只表示选到了可用候选，不表示仍走原来的网络路径。

url-test 与 fallback 的判断不同

url-test 根据探测结果选择候选，通常用于自动选择响应较快的出口；fallback 更强调顺序和可用性。interval 的单位是秒，表示探测周期，不是每个业务连接的超时。tolerance 可用于减少微小差异造成的频繁切换，但不应把它当作保证业务延迟的参数。切换组内候选通常影响新连接，既有连接未必立即迁移。

测速地址应是能够稳定返回预期响应的 HTTPS 地址。示例中的地址只是探测目标，不是站点外部资源依赖。某个探测目标可达，不等于所有网站可达；反过来，探测地址被拦截也可能让正常节点显示异常。不要根据一次探测结果判断套餐带宽，更不要把探测耗时当作下载速度。排查时可手动访问同一目标，并对照日志确认测试经过了哪个节点。

嵌套关系需要保持单向

组可以引用组，但不能形成循环。例如“出口选择”引用“自动选择”，而“自动选择”又引用“出口选择”，并不会形成更智能的决策，只会造成无效依赖。提供器通过 use 加入，显式节点通过 proxies 加入，二者可以按需要组合。若候选列表突然为空，要检查过滤条件是否过严、提供器是否更新成功，以及组名有没有在覆写中被替换。

负载均衡不是把单个下载连接拆成多条线路叠加速度。不同分配算法可能让同一业务的不同连接使用不同出口，进而触发登录验证或会话异常。工作登录、支付和需要固定来源地址的服务，更适合明确选择单一出口。对普通桌面配置，先保留一个手动组和少量清楚的嵌套层级，比堆叠大量名字相似的组更容易维护，也更容易从连接记录追踪实际路径。

五、规则语法与从上到下匹配

规则模式下，mihomo 通常按 rules 列表从上到下寻找匹配项，命中后使用该规则指定的出站。因此，规则位置与规则内容同样重要。把宽泛的直连规则放在前面，后面的精细域名规则就可能永远没有机会生效。配置自定义规则时，先明确想匹配的是域名、目标 IP、进程还是其他属性，再选择规则类型，不要只复制相近的文字。

域名规则不填写完整网址

DOMAIN 用于精确域名，DOMAIN-SUFFIX 用于域名及其子域，DOMAIN-KEYWORD 则按关键词匹配，范围通常更宽。字段中不包含 https://、路径和查询参数。网页地址里的一段路径不能靠普通域名规则区分；同一网站的登录、图片和接口也可能使用不同域名，需要从实际连接中观察，而不是只处理地址栏里的主域名。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,出口选择

示例域名采用文档保留域名，不对应实际业务。“出口选择”需要在策略组中存在。最后的 MATCH 是兜底规则，接受此前未被匹配的连接，通常放在末尾。它前面的私有地址规则用于说明局域网直连，但仍应结合实际网络审核：某些企业网段可能需要通过特定隧道访问，不能把“私有地址”一概等同于“本机一定可以直连”。

理解 no-resolve 的限制

IP 类规则可能需要先获得目标地址。如果请求携带的是域名，解析动作又可能改变后续匹配路径。添加 no-resolve 表示不为匹配这条规则主动触发域名解析；已有目标 IP 的连接仍可参与匹配。它不是“这条连接永远不做 DNS”，也不是让域名自动对应某个地址。要按域名稳定分流，通常优先写域名规则，再把必要的 IP 规则作为补充。

进程规则适合按 Windows 应用划分，但依赖内核能识别连接对应进程。入口方式、权限、系统环境都可能影响识别结果。浏览器访问涉及多个子进程，应用更新也可能改变可执行文件路径，写规则前应在连接详情确认实际进程信息。不要把进程规则能匹配当作防火墙级隔离承诺；需要严格网络限制时，还应使用操作系统提供的控制措施。

规则提供器要同时核对格式与行为

rule-providers 用来组织可复用规则集合，与代理提供器不是同一种内容。behavior 表明集合中的条目如何解释，常见的有 domain、ipcidr 和 classical；format 则描述文件格式。二者分别回答“里面是什么规则”和“文件怎么编码”，不能互相替代。下面使用本地的传统规则集合，便于查看完整对应关系。

rule-providers:
  local-domains:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,出口选择

# ./rules/local-domains.yaml 的内容：
# payload:
#   - DOMAIN-SUFFIX,example.com
#   - DOMAIN,intranet.example.org

规则集合中的条目不再附带出站，因为引用处的 RULE-SET 已经指定了目标。规则集加载失败时，应先检查路径、返回内容与格式，而不是把整个规则列表删除。远程地址若返回登录页或错误提示，即使 HTTP 请求成功，也不是有效规则文件。更新周期只控制重新获取的节奏，不保证远端文件内容一定可解析。

验证规则时，先在客户端连接页面查目标域名、命中项和最终出站，再决定是否移动顺序。已有连接可能继续沿用原路径，测试前可关闭对应应用连接或重新打开应用，但不要把一次刷新当作所有连接都已重建。具体操作可接着看连接验证步骤；订阅会定期更新的场景，应将自定义规则放入持久覆写，下一章之外的合并细节见覆写与合并。

六、DNS：解析路径与 fake-ip

DNS 配置解决的是域名如何获得地址，以及解析请求通过什么路径发出。它与代理节点选择相关，但并不是同一套开关。浏览器能通过代理访问网页，不代表系统所有 DNS 请求都经过内核；反过来，内核启用了 DNS 服务，也不表示 Windows 或应用已经把查询交给它。讨论 Clash DNS 泄漏时，应先确认请求来源、解析器与网络出口，不能只凭一个字段下结论。

监听地址不等于接管系统解析

dns.enable 开启内核 DNS 功能，listen 指定本地监听地址。为避免和系统服务冲突，下面使用回环地址与非标准端口。仅添加这段配置后，Windows 默认解析仍可能使用网卡的 DNS，除非另有 TUN 劫持或明确的转发设置。不要把带端口的地址直接填进只接受 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:
    - 1.1.1.1
  nameserver:
    - https://dns.cloudflare.com/dns-query

这是一段解析结构示例，不代表该上游适用于所有网络。default-nameserver 主要用于引导解析 DNS 上游自身的域名，避免“访问解析器前还要先解析解析器”的依赖问题；nameserver 是常规查询使用的上游。使用加密 DNS 可以改变查询传输方式，但并不自动改变其出站路径，也不能修复本地网络无法访问上游的问题。

fake-ip 需要连接流量回到内核

fake-ip 为域名分配合成地址，内核保存地址与域名之间的映射，后续连接进入内核后再据此处理。示例地址段用于这类映射，不应被当作网站真实公网地址。若应用拿到合成地址后绕过内核直接连接，就可能失败，因此 DNS 入口与流量入口必须配套。看到合成地址并不等于解析错误，关键是后续连接有没有经过同一个内核实例。

fake-ip-filter 可让部分域名不使用合成地址，常用于本地设备发现或确实不兼容的服务，但不应把所有异常都丢进过滤列表。先确认应用是否依赖真实 IP、是否使用自己的 DNS，以及局域网域名应该由哪台解析器回答。redir-host 使用另一种处理方式，也有对应的匹配和解析边界；切换模式后应考虑旧 DNS 缓存，避免拿旧结果判断新设置。

按域名选择上游与代理节点解析

nameserver-policy 可以针对域名选择解析上游，适合企业内网域名需要交给内部 DNS 的情况。代理服务器本身的域名解析可通过 proxy-server-nameserver 单独安排，减少与普通业务解析互相依赖。若启用 respect-rules 让 DNS 上游连接遵循路由规则，应先明确代理节点域名如何解析，否则可能出现“解析需要代理，建立代理又需要解析”的循环。

DNS 字段之间的优先级会影响实际行为，不建议在初次配置时同时叠加大量备用上游、按域名策略和多个规则依赖。先建立一条可解释的解析路径，再增加必要例外。尤其要注意浏览器的安全 DNS、其他 VPN 的解析设置、企业安全软件和路由器转发，这些都可能让测试请求没有走到预期入口。所谓“备用”上游也不是越多越好，每一项都需要确认可达性与适用范围。

修改后可在必要时运行 ipconfig /flushdns 清理 Windows DNS 缓存，并重启持有独立缓存的应用。只清系统缓存不会必然清除浏览器、内核与远端解析器缓存。若局域网打印机或企业域名失效，应优先恢复正确的内网解析，而不是直接禁用整套分流。确认新方案可用后，再保存为持久设置，并记录哪些域名需要本地解析，以便后续维护。

七、TUN、系统代理与 Windows 路由

系统代理与 TUN 是两种常见入口。系统代理供遵循 Windows 代理设置的应用使用，通常更适合先验证浏览器连接；TUN 通过虚拟网络设备与路由处理更多流量，适合不读取系统代理的应用。开启 TUN 不会改变节点认证，也不会自动补齐 UDP 支持。应先用可工作的节点和基本规则确认出站，再接入 TUN，避免同时排查入口和远端连接两个问题。

配置字段与客户端权限共同决定结果

Windows 上创建虚拟网卡、调整路由和安装服务可能需要权限。客户端的服务模式、管理员启动与内核配置各有分工，不能把一个 YAML 开关视为完成了所有系统操作。优先使用客户端自身提供的服务安装和 TUN 设置入口；如果由界面管理这些字段，手工编辑订阅可能在下次生成时被覆盖。排错时先确认界面状态与运行配置一致。

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

这段使用 mihomo 的 TUN 字段：auto-route 请求自动设置路由，auto-detect-interface 用于识别出站接口，dns-hijack 描述要交给内核 DNS 处理的请求。它需要与有效的 dns 配置配合。劫持传统 DNS 端口并不等于接管所有加密 DNS，应用通过 HTTPS 自行解析时，流量形态已经不同，必须另行理解其行为。

网络栈不是通用的性能开关

stack 可选择内核支持的网络栈方式，具体兼容性受操作系统、内核实现和应用影响。mixed 是一种组合处理方式，不代表在所有设备上都优于其他选项。遇到特定应用异常时，可以在保留基线的前提下逐项比较，而不是同时修改网络栈、MTU、DNS 和节点。每次只改变一个条件，才能判断修复来自哪一项。

MTU 影响网络包大小，某些路径确实可能受到分片或隧道封装影响，但它不是所有卡顿的原因。先观察是否只有特定站点、特定传输或大数据包受影响，再考虑调整。过早套用网上的固定数值，可能把原本正常的连接变得更难解释。若只在 TUN 下异常、系统代理正常，应把检查重点放在路由、入口、DNS 和网络栈，而不是立刻更换订阅。

多网卡与其他 VPN 的排查顺序

电脑同时连接有线、无线、虚拟机网络或企业 VPN 时，默认路由和 DNS 可能来自不同接口。自动识别出站接口并非在所有复杂拓扑下都能得到用户期望的结果。可使用 Get-NetRoute -AddressFamily IPv4 查看路由，结合 Get-NetIPConfiguration 确认接口配置。先记录现状，再在允许的环境中逐个停用冲突软件，避免直接删除不认识的虚拟网卡。

系统代理和 TUN 同时开启时，并不必然出现双重代理，但会增加入口判断的复杂度。排查时可先只保留一种方式，并关闭应用内额外的代理扩展，建立清楚的测试条件。公司设备可能受管理员策略限制，应遵守所在网络的管理要求，不要通过删除服务或修改系统安全策略强行绕过限制。需要常驻使用时，再决定是否开启客户端自启和服务模式。

退出客户端前建议先关闭 TUN 与系统代理，确认系统网络恢复。若异常退出后网页无法打开，先检查 Windows 代理设置是否仍指向已停止的本地端口，再检查残留路由和其他 VPN 状态，不要立即重置整个网络。白屏、服务无法启动等问题，可按Windows 客户端启动排查继续定位；验证访问链路则回到教程验证章节。

八、覆写、合并与可回退的修改流程

订阅通常由远端维护，直接修改导入后的内容容易在更新时丢失。覆写的目的，是把本地偏好与订阅来源分开：远端继续更新节点，本地继续保留必要规则和设置。但“覆写”不是 mihomo 内核统一规定的一种编辑器功能，而是客户端生成配置时采用的处理机制。Clash Plus、Clash Verge Rev 等客户端的入口、语法和执行顺序，应以各自界面说明为准。

标量、映射与列表不能用同一种思路合并

端口、模式这类标量通常表现为后一个值替换前一个值；DNS 这类映射可能按子字段合并，也可能整体替换；规则和策略组这样的列表则可能被替换、追加或前置。客户端没有明确说明时，不能假定它会自动理解“把这一条放在所有规则前面”。下面只是希望得到的最终规则片段，不是可以通用于所有客户端的覆写指令。

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口选择
  - MATCH,出口选择

如果订阅原本已经有一套规则，直接用上面列表替换它，会丢掉订阅中的其他规则。若选择追加到末尾，而原有列表已经包含 MATCH，新增规则又可能没有机会命中。正确做法是使用客户端支持的前置规则功能，或在脚本中明确定位插入位置，再检查生成结果。需要改变一个组时，也要确认是修改同名组，还是意外新增了重复名称。

先画清生成顺序，再决定放在哪里

一次配置生成可能依次涉及远程订阅、订阅专属扩展、全局扩展、图形界面设置和运行时选择。实际顺序由客户端决定，本页不把某个客户端的顺序推广到整个生态。若覆写保存后没有效果，应先查看最终运行文件里该字段是否存在：不存在，通常是覆写未应用或被后续阶段覆盖；存在但行为不符，再检查引用关系、规则位置和入口流量。

全局覆写适合所有订阅共用的偏好，例如明确的本机监听限制；订阅专属覆写适合依赖某个提供器或组名的规则。把只存在于一份订阅的组名写入全局规则，会让其他订阅在切换时找不到目标。迁移前应把旧客户端的专有解析脚本与内核 YAML 分开，不能把整个脚本文件粘进配置。相关对照可看Clash for Windows 迁移笔记。

按保存、测试、加载、验证四步修改

保存阶段先备份当前可工作的来源与覆写，备份中若有订阅凭据应妥善保管。测试阶段检查 YAML 语法、节点引用与规则目标；能运行独立内核测试时，再验证最终配置，而不只是测试零散片段。加载阶段确认客户端没有退回旧配置，查看日志是否出现解析或提供器错误。验证阶段则针对修改目标发起新连接，确认命中规则和最终出口符合预期。

# 在安装了对应内核的终端中测试指定文件
mihomo -t -f config.yaml

# PowerShell：检查示例代理端口的监听情况
Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue

# 清理 Windows 系统 DNS 缓存
ipconfig /flushdns

这些命令分别回答不同问题：配置测试不验证远端认证，端口监听不证明目标网站可达，刷新 DNS 也不修复错误规则。不要把三条命令当成固定的万能修复序列。若命令不存在，应先确认可执行文件路径或终端环境，而不是下载来源不明的工具。客户端已内置配置检查功能时，也可以优先使用它，避免独立内核与客户端内核不一致。

更新后复查依赖，而不只看能否启动

订阅更新可能改名、移除节点或调整规则组，客户端更新也可能改变扩展处理方式。更新完成后，应复查本地规则引用的组是否仍存在、规则提供器是否正常加载，以及 TUN 与 DNS 是否保持预期。能启动只说明配置被接受，不能证明业务规则仍符合原来的目标。对重要应用做一次新连接验证，再确认常用内网资源和普通网页都能按设计访问。

如果需要继续查字段术语，可转到术语手册；如果尚未完成订阅导入，回到订阅导入步骤即可，不需要一次配置所有高级功能。维护一份配置的重点，是让每个字段都有明确用途、每条例外都能解释、每次更新都能回退。较短而可验证的本地覆写，通常比长期复制整份订阅更容易保持稳定。