Clash 配置文件
参考手册

01 YAML 结构与引用关系

Clash 配置不是一串按顺序执行的命令，而是一份描述网络行为的数据。文件顶层通常同时放置监听端口、运行模式、DNS 设置、节点列表、策略组和规则。内核读入文件后，先建立这些对象，再根据连接命中的规则选择出口。因此，文件能够保存，不代表节点能连接；语法正确，也不代表所有名称都引用正确。

缩进决定字段属于谁

YAML 用空格缩进表达层级，建议统一使用两个空格，不要混入制表符。冒号后面跟普通值时保留一个空格；列表项以短横线加空格开头。同一层字段必须对齐。编辑器里看似只偏了一格，实际可能把顶层的规则列表放进 DNS 对象，导致字段被忽略或出现类型错误。开启显示空白字符，比靠肉眼猜缩进可靠。

# 可独立加载的最小直连配置，不包含代理节点
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

上例可以检查配置是否被正常加载，但所有连接都直连，不会产生代理出口。空列表写成 []，意思是当前没有条目，不等于缺少整个字段。若正在排查编辑器或目录权限问题，先用这种最小文件确认加载链路，再逐段加入自己的节点和策略组。不要一开始就把完整订阅、外部规则和覆写脚本同时接上。

字符串、布尔值与列表

布尔值建议写成 true 或 false，端口写整数，节点名称和规则字符串按需要加引号。名称包含冒号、井号或特殊符号时尤其要留意：井号可能被识别为注释，冒号加空格可能被识别为映射分隔符。密码即使只由数字组成，也建议用引号明确保留为字符串，避免读取后类型变化。

多行块写法更适合查阅，花括号包住的行内映射更紧凑，两者可以表达相同对象。本页优先使用多行写法，让每个字段的归属一眼能看清。不要把 YAML 外层再套一层 Markdown 代码围栏；网页中的示例标记不是配置内容。复制时只取代码正文，文件应保存为正常文本，而不是富文本编辑器生成的文档。

名称构成一条引用链

节点的 name 会被策略组引用，策略组的 name 又会被规则引用。引用按完整名称对应，空格、大小写和标点都应保持一致。若把策略组改名，却没有修改规则中的目标，加载时可能提示代理不存在。排查这类错误，应从规则目标往回查：先找同名策略组，再看组内每个成员是否确实存在。

顶层同名键不要重复写。两个 rules 并不意味着自动拼接，两个 dns 也不意味着自动合并；不同解析器可能拒绝重复键，或只保留其中一个。需要增加规则时，修改已有列表；需要保留订阅结构时，使用客户端明确支持的覆写机制。YAML 本身不会替用户理解“把这两段接在一起”的意图。

处理订阅时还要分清原始内容和运行内容。订阅下载后，客户端可能再应用端口覆盖、DNS 覆写或规则合并。编辑 Profiles 中的源文件后没有效果，不一定是内核未读取，也可能是更靠后的设置再次覆盖了它。先记录当前启用的配置名称与来源，后面每次修改都以实际运行配置和日志为准。

02 端口、模式与访问边界

端口字段描述客户端在本机哪里接收连接，不是远端服务器的端口。浏览器或命令行把请求送到这个入口，内核才有机会按规则分流。修改端口以后，使用旧端口的程序不会自动跟随所有变化；Windows 系统代理、独立浏览器设置、终端环境变量可能分别保存地址，需要逐处确认。

分开监听与混合监听

# 本机使用的通用字段片段
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

不需要局域网共享时，可以保持仅本机访问。上例的监听地址和访问开关都偏向本机用途。若改为给手机或另一台电脑使用，不能只打开 Allow LAN：还需要让监听地址覆盖对应网卡，在防火墙里允许可信网络访问，并在另一台设备上填写这台电脑的局域网地址，而不是填写它自己的回环地址。

监听失败常见于端口已被占用。先退出重复启动的客户端，再检查占用进程，不要连续换几个端口后忘记同步应用设置。在 Windows 终端运行下面的命令，可以查看该端口的监听项和进程编号。它只帮助定位占用者，不应看到编号就直接结束进程；先到任务管理器核对程序名称与用途。

netstat -ano | findstr :7890

规则、全局与直连模式

mode: rule 表示按规则顺序决定出口，适合日常分流。全局模式把连接交给全局策略选择，但前提仍然是流量已经进入内核。直连模式则让已接管的连接直接访问目标。模式不是系统级流量接管开关，把规则模式切到全局，不会让一个完全忽略系统代理的程序突然开始使用代理。

General 中的 System Proxy 是客户端设置 Windows 系统代理的操作，和 YAML 的运行模式不是同一回事。它通常影响遵循系统代理的程序；TUN 则通过虚拟网卡和路由接管流量，需要相应内核、权限和服务支持。旧版 Clash for Windows 的 Service Mode、TUN Mode 与当前 Mihomo 客户端的实现不能直接按同一套按钮位置理解。

日志与控制接口不要混用

log-level 日常使用 info 即可，排查时可临时提高到 debug。调试日志可能包含目标域名、连接信息和配置路径，分享前应删去订阅地址、认证信息与个人访问记录。日志越多不等于定位越快，复现一次问题后，按时间顺序找到对应连接，比长时间收集所有输出更有效。

外部控制接口用于客户端界面或仪表板管理内核，不是给应用上网的代理入口。需要配置 external-controller 时，优先绑定回环地址；若确需远程访问，应另行设计认证和访问限制。不要将控制接口端口填进浏览器代理设置，也不要为了让局域网设备上网，顺手把管理接口暴露给整个网络。

顶层 ipv6 与 DNS 模块中的 IPv6 选项作用范围不同。关闭其中一个字段，不代表系统网卡已经禁用 IPv6，也不代表所有应用的解析路径都发生变化。遇到某些目标只在特定网络下失败，应检查系统地址、DNS 返回、规则命中与出口连通性，避免把所有故障都归结为端口或一个代理开关。

改动这一章的字段后，先看内核是否成功监听，再看应用的代理地址，最后再验证模式和出口。按这个顺序可以把“入口不可达”和“远端连接失败”分开。更多操作入口见系统代理使用说明；如果退出客户端后仍无法联网，可到FAQ查找系统代理残留的排查方法。

03 DNS 与域名解析路径

DNS 负责把域名转换为地址，但在代理配置中，解析并不总发生在同一处。系统可以先解析，应用可以自带解析器，内核也可以接管请求，远端代理还可能负责最终解析。判断 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
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

enable 启用内核的 DNS 模块，listen 指定服务监听地址。上例使用回环地址和非特权端口，便于测试，不会自动修改 Windows 的所有 DNS 请求。系统网卡的常规 DNS 设置通常只接收服务器地址，不能直接填写带有这个自定义端口的字符串；完整接管还需要客户端或 TUN 的相关配置。

nameserver 是解析上游列表，不应被简单理解为严格的主用、备用顺序。不同内核的并发、缓存和选择行为可能不同。填入多个服务后，失败原因也不一定是“第一项坏了”。测试时先减少变量，用一条能从当前网络访问的上游确认基础功能，再加入加密解析或按域名分流的设置。

Fake IP 与真实地址

Fake IP 模式先向应用返回映射地址，内核保留地址与域名的对应关系，连接进入内核后再按域名处理。这有利于保留域名信息，但依赖查询和连接处在同一套接管路径中。若应用拿到映射地址，却绕过内核直接连接，就可能访问失败。关闭客户端前还保留旧缓存，也可能造成暂时无法访问的现象。

fake-ip-filter 用于让部分域名避免获得映射地址。局域网发现、某些设备服务或必须看到真实地址的程序可能需要例外，但它不是越长越好。把所有常用域名都排除，会改变原先预期的解析路径。应针对已经复现的问题添加最小例外，并在修改后清理相关应用缓存，再观察实际结果。

Redir Host 通常返回真实地址，适合部分不能接受映射地址的场景，但不意味着所有应用兼容性问题都会消失。域名信息能否完整保留、请求是否先被系统解析、目标地址是否变化，仍会影响规则行为。选择模式时应围绕当前应用和接管方式测试，而不是把两种模式理解成固定的速度高低排序。

Mihomo 的按域名解析策略

# Mihomo 局部示例：并入已有 dns 对象，不要再建第二个 dns
dns:
  nameserver-policy:
    "+.example.com":
      - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

nameserver-policy 可给指定域名安排解析上游，示例只展示字段层级，不代表该保留域名需要特殊处理。Mihomo 的 proxy-server-nameserver 用于代理服务器域名解析。两者关注的对象不同：访问网站的域名和连接节点服务器的域名，不能仅因为都叫“域名”就混为同一个解析步骤。

节点服务器写成域名时，启动连接本身就可能需要 DNS。若解析该节点又必须先经过这个节点，就会形成启动依赖循环。排查时先确认服务器域名能通过独立可用的路径解析，再讨论网站解析是否走代理。加密 DNS 上游使用域名时，也要关注其引导解析与连接路径，不能只替换一条地址就假设循环已经解决。

DNS 泄漏测试反映的是特定测试条件下观察到的解析出口，不等同于所有流量的统一结论。浏览器安全 DNS、应用自带 DoH、系统缓存、局域网 DNS 都可能绕开预期路径。验证时分别检查浏览器设置、内核 DNS 日志和 TUN 接管状态；仅做一次网页测试，无法替代对实际解析链路的确认。

04 代理节点字段与协议边界

proxies 列表保存具体的代理出口参数。一个条目至少需要能识别协议、服务器地址和端口，认证字段则随协议变化。客户端里显示的节点名称只是本地标识，不会替代认证信息。把节点改成更容易记住的名称，不会改变服务器位置，也不会让服务器获得原本不支持的协议能力。

先核对地址，再核对认证

# 教学节点片段：保留域名与假密码不能用于实际连接
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

server 应填写主机名或 IP 地址，不要把包含协议头、路径和查询参数的整条网页链接塞进去。port 是服务端监听端口，和本机的 mixed-port 没有对应要求。服务方给出什么就填写什么，不能因为网页常用某个端口，就认为任何节点都应改成相同值。

Shadowsocks 的 cipher 与 password 必须和服务器匹配。加密方式不是随意选择的性能选项，名称拼写错误或内核不支持都会导致失败。不同代际协议使用的密钥格式也可能不同，不能只改协议名称而保留其他字段。若订阅已经给出可用节点，优先保留原始参数，不要凭印象整理掉看不懂的字段。

TLS、SNI 与证书验证

TLS 节点通常还涉及服务器名称、证书和传输层参数。SNI 用于 TLS 握手中的服务器名称指示，未必与直连时填写的 IP 相同，应以服务端实际部署为准。证书错误不一定是密码错误，也可能是系统时间偏差、名称不匹配或中间网络干扰。应先看日志里的错误类型，再决定核对哪组字段。

skip-cert-verify: false 表示保留证书验证。遇到握手失败，不应把关闭验证当成常规修复步骤，否则可能掩盖服务器名称或证书配置问题。先校准系统时间，再检查 SNI 与服务方说明；如果订阅突然大批出现证书问题，还应确认是否加载了错误文件、是否经过需要认证的网络入口。

VMess、VLESS、Trojan、Shadowsocks 等协议的认证字段并不通用。某些协议需要用户标识，某些需要密码，某些还对传输方式和安全参数有额外要求。本页不提供一份混合所有字段的“万能节点”，因为多余字段可能被忽略，反而让错误看起来已经被修复。应按协议选择完整且匹配的节点定义。

传输能力需要两端共同支持

udp: true 只是允许对应节点使用 UDP 的配置意图，最终能否传输，还取决于协议、服务端、网络和入口接管方式。系统代理常见的 HTTP 入口不能自动接管所有应用的 UDP。游戏或语音程序失败时，应先确认流量有没有进入内核，再核对节点的 UDP 支持，而不是只在 YAML 里反复切换这一行。

使用 WebSocket、gRPC 或其他传输层时，路径、主机头和服务名称要与服务端一致。网页能打开，不代表代理服务的握手参数正确；服务器端口能建立 TCP 连接，也不代表协议认证成功。日志中的连接超时、认证失败和握手中断分别指向不同阶段，按阶段排查，比一口气更换全部参数更容易定位。

新协议或扩展字段必须由当前内核支持。Clash for Windows 的旧内核不能通过加几行 Mihomo 配置就补齐能力。迁移时可先比较 Clash Plus、Clash Verge Rev、FlClash 等客户端的实际支持范围，具体入口见客户端对比。界面能导入文件，也不保证运行内核接受其中每种节点。

最后注意节点名称唯一性。两个同名节点可能让引用结果不明确，订阅更新也可能改变名称和顺序。手动维护时，名称表达用途即可，不应把密码、完整订阅地址或个人账号放进去。分享故障配置前，删除认证值和私有服务器信息；保留字段结构与错误提示，通常已经足够判断是格式问题还是协议边界问题。

05 策略组选择与健康检查

策略组位于规则和节点之间。规则把连接交给一个稳定的组名，组内再决定使用哪一个出口。这样更换节点时，不必把每条规则重写一遍。先理解这层间接关系，再设计分组：一组负责手动选择，一组负责自动检测，特定业务可以单独建组，但不需要为每个网站都复制一套相同成员。

手选与自动选择分开表达

# 依赖上一章已定义的两个教学节点
proxy-groups:
  - name: "代理选择"
    type: select
    proxies:
      - "自动选择"
      - "示例 SS"
      - "示例 Trojan"
      - DIRECT

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

select 是手动选择组，客户端界面通常允许直接切换成员。成员可以是节点，也可以是其他策略组，或 DIRECT 这样的内置出口。上例把自动组作为一个可选成员，因此日常可以选择自动检测，也可以临时固定某个节点。名称只是示例，修改时记得同步规则中的引用。

url-test 使用测试请求比较候选出口，interval 是检查间隔，通常以秒计；tolerance 则用于减少小幅差异造成的频繁切换，其含义和单位应以当前内核文档为准。上例在常见实现中以毫秒表达容差。不要为了让界面不断刷新而把检查间隔设得过短，健康检查同样会产生连接和流量。

检测成功不等于业务可用

测试地址返回成功，说明通过该出口到这个地址的请求在当时完成了，不代表视频、下载、游戏和办公系统都有相同表现。延迟值可能包含连接建立、握手和请求响应的影响，却不能直接表达持续带宽。一个测试较快的节点，也可能因拥塞、丢包或目标站限制，在真实业务中表现不佳。

因此，测试地址应选择稳定、能正确返回预期响应的地址，并结合实际用途验证。若所有节点同时出现检测失败，先检查测试目标是否可达、解析是否异常，而不是立刻断定全部服务器失效。关于数值与真实体验的差异，可参阅节点延迟测试原理。

故障切换与负载均衡

fallback 通常按候选顺序选择可用出口，适合主线路和备用线路的关系；它不是自动挑选最低延迟的另一种名称。load-balance 则按实现支持的策略分配连接，不会把多个节点的带宽简单叠加成一个连接的速度。网站对登录会话或出口地址敏感时，还需评估分配方式是否会影响会话稳定性。

策略组嵌套应保持方向清晰。可以让“办公”引用“代理选择”，再由“代理选择”引用具体节点；不能让两个组互相引用，形成循环。出现组不存在或循环依赖错误时，先画出从规则到节点的单向链路，把间接引用展开。组越多，排查越复杂，初始配置宜控制在能说明用途的少数组别内。

是否把 DIRECT 放入自动检查组，需要按业务目标决定。它也可能通过测试并被选中，但此时连接是直连，不再具有代理出口的网络路径。如果某个分组的目的就是固定使用代理，不应只因直连检测数值较小就让它参与竞争。分组的候选范围，比测试间隔的细微调整更影响最终行为。

客户端可能记住策略组的选择结果，重新加载后不一定回到列表第一项。看到规则命中正确却走了意外出口时，展开组的实际选择，沿嵌套关系一直查到最终节点。仅看最外层组名无法判断当前路径；切换订阅后同名组的选择恢复机制，也需要结合客户端的持久化设置确认。

通过提供器引入节点时，策略组还可以用 use 引用节点集合，详细结构见第七章。此时节点健康检查和组内测试可能同时存在，应避免重复设置过密检查。修改组结构后，既要确认配置能加载，也要在界面手动切换一次，再查看新连接的实际出口，确保引用没有落到预期之外的成员。

06 规则语法与匹配顺序

规则模式下，规则通常从上到下检查，连接命中可用规则后交给目标策略处理。更具体的例外放前面，更宽泛的范围放后面，兜底放最后。规则列表不是会自动计算“最精确匹配”的路由表：前面一条宽规则已经匹配，后面的细规则就可能完全没有机会处理这次连接。

先写明确例外，再写兜底

# 依赖已有的“代理选择”策略组
rules:
  - DOMAIN,portal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,代理选择
  - DOMAIN-KEYWORD,example,代理选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理选择

DOMAIN 精确匹配指定域名，DOMAIN-SUFFIX 匹配该域及其子域，DOMAIN-KEYWORD 按域名中是否包含关键词判断。关键词范围往往比预期宽，可能把名称相似、用途完全不同的服务一起匹配。若已经知道目标域名，优先使用精确或后缀规则，避免为了少写几行牺牲可解释性。

示例将门户域名的直连例外放在域名后缀规则之前，因此访问该门户时不会落到代理选择。若把两行交换，后缀规则先接住请求，例外就失效。排查“明明写了规则却没有作用”，第一步应向上查找更早的匹配，而不是不断在列表底部追加同样的规则。

域名规则与地址规则

IP-CIDR 判断目标地址是否属于指定网段。尾部的 no-resolve 表示不要为了这条地址规则主动把域名解析为 IP；若连接已经带有目标地址，仍可能进行地址匹配。它不是“关闭所有 DNS”的开关，也不会让域名规则失效。局域网地址例外常使用这个选项，减少不必要的解析。

GEOIP 依据地址数据库判断目标 IP 所属地区，不是按域名注册地、网页语言或服务公司所在地判断。网站使用跨地区 CDN 时，同一个域名可能返回不同地区的地址。若业务要求明确走某条路径，应使用清楚的域名规则，而不是期待地理地址数据库总能替代业务分类。

MATCH 是最终兜底，通常应位于最后。它让没有被前面规则处理的连接仍有明确出口。如果在列表中间就写入兜底，后面的规则一般不会再起作用。兜底选择代理还是直连取决于使用目的；示例选择“代理选择”，但并不代表所有网络环境都适合相同默认行为。

规则命中需要观察新连接

改规则后，已建立的长连接可能继续沿用原来的出口，网页也可能复用连接或缓存资源。验证时重新发起请求，必要时关闭相关旧连接，再到 Connections 或日志里检查命中规则、策略组和最终出口。不要只刷新一次页面就依据体感判定规则无效，也不要只看组名而忽略组内当前选中的节点。

进程规则依赖操作系统和内核能否识别进程。Windows 上可能受权限、接管方式和应用结构影响，浏览器子进程或系统服务也会让名称不如预期直观。使用前先观察连接记录中的实际进程信息，再按当前内核支持的语法编写。对于跨平台共用配置，域名规则通常比硬编码本机路径更便于维护。

规则太多时，先按业务组织，再考虑是否交给外部规则集维护。局域网例外、特定服务例外、常规分流和最终兜底各自保持清晰边界；不要为了所谓完整，把多份来源不明的规则直接串联。列表长度增加不代表覆盖更准确，冲突和重复反而会让一次命中更难解释。

遇到只在某个应用里失效的规则，还应回到流量入口检查。内核没有接到连接，再正确的规则也无法参与处理；应用提前把域名变成地址时，域名匹配能力也可能受到影响。把入口、解析、匹配和出口分开看，通常比添加更多模糊规则更快找到原因。

07 节点订阅与外部规则集

提供器把频繁变化的内容从主配置中分离出来。节点提供器负责一组节点，规则提供器负责一组匹配条件；主配置只保留引用和策略关系。这样更新节点时，不必重写本地业务分组，更新规则时，也不必重新下载整个配置。但它会增加下载、解析、缓存和引用几层依赖，不能仅凭主配置加载成功就认为全部内容已经可用。

完整订阅和节点提供器不是一回事

# 本地节点提供器示例；需先创建对应文件
proxy-providers:
  local-nodes:
    type: file
    path: ./providers/local-nodes.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: "订阅选择"
    type: select
    use:
      - local-nodes

上例使用本地文件，避免把私人订阅地址写进教学示例。该文件应由当前内核能够读取，并包含节点提供器所需的数据结构。相对路径通常以加载目录或工作目录为基准，客户端可能设置自己的工作目录；具体位置要通过日志和文件管理入口确认，不能只按主配置在磁盘上的位置猜测。

# providers/local-nodes.yaml 的内容示例
proxies:
  - name: "本地示例 SS"
    type: ss
    server: ss.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"

完整订阅可能包含端口、DNS、策略组和规则，节点提供器通常只需要节点集合。不能把任何订阅链接原样放入 proxy-providers 就假设内核能理解。先确认服务方输出的格式和当前内核支持，再决定是整份导入，还是作为节点集合引用。格式不符时，错误有时会表现为提供器为空，而不是主配置直接报错。

规则提供器按行为类型组织

# Mihomo 本地规则提供器片段
rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,订阅选择

# rules/local-direct.yaml 的内容示例
payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

这个规则文件使用 payload 包装规则条目，具体出口由主配置中的 RULE-SET 决定。不要把普通 rules 列表原封不动放进去，也不要在每一项后面重复添加策略组。规则集负责描述匹配对象，主配置负责把它接到出口，这种分工才方便同一份规则在不同环境复用。

behavior 必须与规则内容相符。域名集合、地址集合和经典规则条目不是同一种格式；把经典规则当成纯域名列表，可能得到解析错误或完全不同的匹配结果。Mihomo 还支持其他规则格式，但旧内核不一定支持。准备共享配置时，应选择目标内核确实接受的交集，而不是仅在自己的客户端测试一次。

更新失败分四层检查

远程提供器还需要可访问的下载地址、更新间隔与缓存路径。第一层检查网络请求是否成功，第二层检查响应是不是预期的 YAML 或规则数据，第三层检查内核能否解析，第四层检查策略组或规则是否真的引用了它。网页返回登录页、订阅额度提示或错误信息时，即使 HTTP 请求有响应，也不代表拿到了可用配置。

更新间隔一般按秒配置，不应把频繁刷新当作修复方法。服务端可能限制请求次数，多个客户端同时刷新也可能触发限制。先保留可用缓存，再手动更新一次查看错误；不要在不知道失败原因时清空所有缓存，否则可能把暂时的下载故障变成完全没有可用节点的状态。

订阅地址常包含私人授权信息，应按密码一样保管。截图、日志和导出的运行配置都可能带出完整地址。需要求助时，用保留域名替换地址，并保留返回状态、解析错误和相关字段结构。不要把私人订阅交给来源不明的在线转换工具，也不要把别人的订阅链接放进公共配置示例。

节点集合更新后，名称变化可能影响手动选择或过滤条件。检查提供器条目数量是否符合预期、策略组是否仍有候选成员，再确认新连接的出口。对于“下载成功但组里没有节点”的情况，重点查引用名称、格式和过滤条件。具体失败提示可结合订阅更新相关 FAQ逐项定位。

08 覆写、合并与运行验证

订阅负责更新远端内容，本地覆写负责保留个人设置。两者需要明确边界，否则更新一次订阅就丢失规则，或者修改源文件后又被界面设置覆盖。先找到客户端提供的配置管理入口，确认当前文件是订阅源、覆写片段还是最终运行文件，再决定改哪里。Clash for Windows 的 Mixin 与其他客户端的合并或脚本功能不能直接按名称互换。

合并规则必须由实现明确规定

YAML 只描述数据，不规定多个文件如何合并。客户端可能对映射递归合并，对列表直接替换，也可能提供专门的前置和后置规则机制。不同工具中相似的“合并”按钮，不保证有相同语义。应用一个很短的 rules 列表前，应先弄清它是追加到原规则，还是替换整份规则；否则容易只剩自己的两条规则。

# 覆写意图片段：仅在客户端支持对应合并方式时使用
mixed-port: 7890
allow-lan: false
log-level: info

dns:
  ipv6: false

上例表达的是固定本地入口和部分解析选项，不是一份完整运行配置。若作为独立文件加载，缺少其余网络结构；若通过浅层合并覆盖整个 DNS 对象，又可能意外移除已有上游。正确做法是先在副本中应用，再查看生成结果，确认没有丢掉 nameserver、节点、策略组或规则等原有内容。

需要追加个人规则时，优先使用客户端明确提供的规则插入位置。业务例外通常前置，最终兜底仍留在末尾；把新增规则追加到已有 MATCH 后面不会得到预期效果。若客户端没有稳定的列表合并能力，可以考虑由本地主配置引用节点提供器，而不是持续修改整份订阅生成的规则列表。

区分文件、界面与运行状态

配置来源可能经过多步处理：下载订阅、应用本地片段、执行脚本、写入运行文件、通知内核重新加载。具体顺序由客户端决定，不能在没有确认的情况下假定界面设置总是最后生效。遇到“保存成功却没变化”，应先检查最终运行配置，再看重载是否成功，最后检查旧连接是否仍沿用先前状态。

如果使用 Mihomo 的命令行程序，可通过下面的测试命令检查配置。命令中的文件名应替换成实际文件，工作目录也要包含相关提供器文件。测试通过主要说明配置能够被该内核接受，不保证节点认证、远程下载和业务访问一定成功。旧环境应使用相应内核的帮助信息确认参数，不要直接套用程序名。

mihomo -t -f config.yaml

验证过程按层推进：先看语法与引用，再看入口监听，再看 DNS 和提供器，最后看实际连接。若报错给出行号，应同时检查该行上方的缩进、引号和列表边界，因为解析器发现错误的位置不一定就是最早写错的位置。修复一处后重新测试，不要把多个猜测性改动一起提交到正在使用的配置。

保存回退点，再检查真实请求

正式修改前，导出当前可用配置，并记录启用的覆写项与策略组选择。保留一个能够恢复的本地副本，不能只依赖可能继续变化的订阅地址。修改后若网络中断，先恢复最后可用状态；不必一边失去连接，一边继续添加新字段。备份中同样可能包含私人认证信息，应放在受控位置，不要上传到公开空间。

端口验证可以用支持代理参数的工具发起请求，但要区分连接到了入口，还是已经成功访问目标。在 Windows 上执行下例时使用 curl.exe 明确调用程序，避免某些终端中的同名别名干扰。目标采用保留示例网站；如果当前网络无法访问，应结合返回错误判断阶段，不能仅按命令退出结果给所有节点下结论。

curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/

随后到连接记录查看目标、命中规则和最终出口，并分别测试需要直连与需要代理的业务。验证 TUN 时，还应使用不会自行读取系统代理的应用，确认接管范围符合预期。不要同时运行多个客户端争抢系统代理、虚拟网卡或监听端口；出现不稳定时，先只保留一套明确启用的网络接管路径。

一份便于维护的配置，应能回答四个问题：流量从哪里进入，域名在哪里解析，哪条规则作出选择，最终使用哪个出口。每次变更都围绕其中一层，留下注释说明用途，删除已经失效的临时例外。这样订阅更新、系统切换或更换客户端后，仍能沿着同一条链路找回问题，而不是从头堆一份更长的配置。