Clash 配置文件参考

YAML 结构与配置边界

Clash 配置不是一串按顺序执行的命令，而是一份描述监听、解析、出站和路由关系的结构化文档。顶层的 dns、proxies、proxy-groups 和 rules 各有职责，只有名称引用正确、数据类型符合要求，内核才能把它们连接起来。阅读陌生配置时，先找顶层字段，再顺着规则里的目标名称查策略组，最后检查组内引用的节点；从文件第一行逐字读到最后一行，反而容易忽略这种依赖关系。

映射、列表与缩进

YAML 用缩进表达父子关系，建议统一使用两个空格，不混入制表符。冒号后有空格时通常表示键值分隔，短横线后有空格时通常表示列表项。同样写着 name，放在节点下面和放在策略组下面，含义并不相同。编辑器的自动格式化可以帮助对齐，但不能判断业务引用是否正确。复制片段时要连同父级一起确认，避免把本该位于 dns 内的字段误放到根层级。

# 结构示意：列表里的每一项都是独立的策略组
proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手动选择

字符串、数字和布尔值应保持明确。端口通常写成数字，开关写成 true 或 false；写成带引号的字符串后，某些解析器会拒绝，另一些可能进行转换，不能依赖这种差异。包含特殊符号、前导零或可能被误读的文本时，使用引号更稳妥。密码建议加引号，内容若含单引号或双引号则按 YAML 的转义规则处理。普通注释放在 # 后，但字符串里的井号是否属于内容，取决于引号和所在位置。

区分订阅源、编辑内容与运行配置

桌面客户端通常保存不止一份文件：远端订阅的原始文本、本地编辑或覆写内容，以及最终交给内核的运行配置。界面上看到的端口、系统代理和 TUN 开关，也可能通过客户端设置写入最终结果。修改订阅文本不等于修改当前运行配置；重新加载、切换订阅或应用覆写后，才可能触发生效。排查时要记录所选配置名称和实际加载时间，避免一边编辑旧文件，一边观察另一份配置的连接结果。

顶层字段的顺序通常不影响映射含义，但列表顺序可能直接改变行为。例如规则按列表顺序匹配，手动选择组里的第一项也可能影响初始显示。不要把格式整理工具的“按字母排序”套用到所有列表。重复键尤其危险：同一层出现两次 dns 或两次 rules，不同工具可能报错，也可能只保留后一项。需要合并时应在同一个键下整理内容，而不是把整段配置简单粘贴到文件末尾。

最小结构与配置兼容性

准备新配置时，先建立能启动的最小结构，再逐项增加节点、组和规则。某份订阅能被一个客户端导入，只能说明该客户端接受了输入，不代表其他客户端拥有同样的字段处理能力。旧内核可能不理解较新的协议或 DNS 字段，客户端也可能过滤某些选项。遇到未知字段，应先查当前内核文档与日志，不要为了消除提示而随意删除整段内容；它可能正好承担域名解析或出站选择的关键功能。

YAML 锚点和别名可以减少重复，但会增加覆写工具、订阅转换器与人工审阅的复杂度。单人维护的小配置，宁可适度重复，也应保证每段都能独立读懂。将配置交给他人排查时，保留层级、字段类型和引用关系，只替换服务器地址、密码与订阅链接。整段删去节点或组名会破坏问题现场，使语法错误、字段不兼容和连接失败混在一起，降低排查效率。

端口、代理模式与接管范围

通用字段决定内核在哪里接收连接、如何选择路由，以及允许哪些设备访问。最常见的误区是把监听端口与服务器端口混为一谈：mixed-port 是本机应用连接代理时使用的入口，节点中的 port 则是远端服务器提供服务的位置。两者数值可以不同，也没有必须保持一致的关系。修改本地监听端口后，还要检查系统代理和应用内代理地址是否同步，否则内核运行正常，应用仍会连接旧端口。

监听字段的用途

只需要本机应用使用代理时，通常保留一个混合端口就足够。HTTP、SOCKS 和混合端口没有必要全部开启，更不能让两个监听项占用相同地址上的相同端口。若出现地址已被使用，先查看是否有另一个代理实例或后台服务仍在运行。允许局域网访问也不只是把一个布尔值改成开启，还涉及监听地址、系统防火墙与访问控制；不应把代理端口直接暴露到不可信网络。

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

规则、全局与直连

mode: rule 让流量进入规则列表，根据匹配结果选择出站；全局模式通常交由全局选择项处理；直连模式则不按自定义规则选择代理节点。模式是路由入口，不是连接接管方式。即使选择全局模式，没有被系统代理、应用内设置或 TUN 接收到的流量，也不会凭空进入内核。相反，规则模式中的某条规则命中 DIRECT 时，连接依然由内核接收，只是最终选择直连出站。

系统代理通常修改操作系统提供给应用的代理设置，是否遵循由应用决定。TUN 通过虚拟网卡和路由接收流量，覆盖范围更广，但会涉及权限、路由冲突及 DNS 接管。不能把 TUN 看作“更强的全局模式”，也不能认为开启后所有网络问题都会解决。游戏、虚拟机、容器和企业 VPN 的流量路径各有差异；启用前应保存当前状态，确认能够恢复原来的默认路由和解析设置。

TUN 与客户端设置的分工

# TUN 片段：启用前确认客户端权限与路由环境
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

上例描述自动路由及对传统 DNS 请求的接管意图，并不保证覆盖应用自带的加密 DNS 或所有平台的网络栈。不同系统对虚拟网卡、服务权限和防火墙有不同要求，客户端还可能统一管理这些字段。若界面开关与文件相互覆盖，应优先确定一个管理入口。具体开启流程放在使用指南，本页只解释字段关系，避免在不了解客户端实现时直接替换整段网络设置。

日志级别适合在日常使用时设为 info，故障复现期间再临时增加细节。调试日志可能含目标域名、连接信息和配置路径，分享前需要脱敏。根层级的 ipv6 与 DNS 内部同名字段分别影响不同环节，不应只改其中一项就认定 IPv6 路径已经处理完整。涉及远程控制接口时，还要单独理解控制面与代理面的区别：管理接口用于修改状态，不应作为普通应用的代理入口。

开机自启、静默启动、主题和托盘行为多数属于 GUI 客户端偏好，并非可以通用于所有内核的 YAML 字段。迁移配置时，应把“网络行为”和“界面行为”分别记录。选择客户端可前往安装包页面，一般用户可先考虑首推的 Clash Plus，再按系统与配置兼容需求选择 Clash Verge Rev 等客户端；不要仅凭界面相似就认定设置文件可以直接互换。

DNS 字段与域名解析路径

DNS 的任务是将域名转换为地址，但代理环境中的解析不只有一个阶段。应用可能先自行解析，内核可能为规则匹配查询目标地址，连接代理服务器时也可能需要解析服务器域名。只有先区分这些对象，才能理解为什么某个域名在浏览器能访问，命令行却失败，或为什么节点使用域名时无法连接。配置加密解析服务器并不等于所有应用都采用了它，也不等于路由已经选择了代理出站。

监听、上游与启动解析

dns.enable 控制内核 DNS 功能，listen 指定 DNS 监听地址，nameserver 指定常规解析上游。使用带域名的 DoH 地址时，必须先取得该上游自身的地址，这就是启动解析问题。default-nameserver 可参与这类基础解析，宜使用明确的 IP 地址。节点服务器本身若使用域名，可通过 proxy-server-nameserver 指定其解析来源，避免把服务器解析与目标域名分流混作一件事。

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:
    - 1.1.1.1
  nameserver:
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

这是一份字段关系示例，不是适合所有网络的解析方案。上游的连通性受网络环境影响，选择前应先测试是否能够访问。仅仅让内核监听 1053 端口，并不会自动让系统把 DNS 请求发到这里；需要客户端或系统网络设置负责接入，TUN 场景则要检查劫持和路由是否真正生效。若应用启用了自己的安全 DNS，它可能绕过传统端口上的接管路径，排查时应将这一因素单独记录。

fake-ip 与真实地址解析

fake-ip 模式给应用返回保留地址段内的映射地址，内核再根据映射恢复域名并安排连接。这样有助于保留域名信息，但依赖流量仍然经过同一个内核；应用拿到映射地址后绕开代理路径，就可能无法连接。部分局域网服务、发现协议或对地址有特殊假设的软件不适合这种返回结果，可通过过滤条目按需排除。不要为了处理一个应用就把所有域名排除，否则会失去原本选择该模式的意义。

redir-host 通常返回解析得到的真实地址，行为与 fake-ip 不同，并不代表它在所有环境中更稳定。真实地址可能被多个域名共享，某些连接进入内核时又缺少域名信息，规则匹配结果便可能变化。两种模式之间切换后，应清理相关应用缓存或重建连接，否则旧地址会继续影响观察。看到保留地址并不能直接判断网络异常，也不要把它当作真实网站服务器的地址进行地理归属判断。

按域名选择解析器

nameserver-policy 可以为特定域名指定解析来源，适合企业内部域名、家庭设备名称或有明确解析要求的服务。它控制“向谁询问”，不是“连接走哪条出站”；要改变业务流量路径，仍需配置规则。内部解析器往往只能在对应局域网或 VPN 中访问，离开网络后继续强制使用会导致超时。维护此类配置时，应记录适用网络，并避免把内部域名交给不相关的公共解析服务。

# 合并到现有 dns 映射中，不要重复声明顶层 dns
dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

fallback 与过滤条件是另一套选择机制，不能简单理解为主服务器失败才启用的备用列表。是否接受某个解析结果，可能还取决于地址范围或相关过滤设置。没有明确需求时，不必为了“配置完整”添加多组解析器。配置越复杂，越难分辨结果来自缓存、策略还是后备路径。先保持单一可用上游，确认接管路径正确，再逐项增加策略，通常更容易定位失败发生在哪个阶段。

检查 DNS 泄漏应先写清预期：哪些请求应由系统解析，哪些交给内核，哪些由代理服务器处理，再用实际连接和解析记录验证。检测网站看到的解析出口只能反映一次测试，不能替代对应用行为的检查。若解析正常但 HTTPS 报错，不应直接修改证书校验；可按代理后证书错误排查核对系统时间、信任链与网络环境，分别处理解析和证书两个层面的问题。

代理节点字段与连接参数

proxies 是静态出站定义列表，每个列表项描述一种具体连接方式。节点名称供策略组和规则引用，服务器地址、端口、协议和认证字段则决定能否建立连接。节点名字写着某个地区，只是维护者给出的标签，不构成服务器位置或连接质量的证明。排查连接失败时，应先确认实际协议与服务端参数，而不是反复修改显示名称；名称改动只会影响引用关系，不会修复远端服务。

共同字段与协议专属字段

多数节点具有 name、type、server 和 port，但认证和传输字段不能跨协议照抄。Shadowsocks 使用加密方法和密码，其他协议可能使用用户名、标识符或不同的 TLS 参数。同名字段在协议实现中的支持情况也可能不同。应以服务端提供的参数和当前内核支持范围为准，尤其不能把分享链接中的每一段文字按直觉填进 YAML；编码、转义和可选参数都有明确规则。

# 结构示例：地址与密码为教学假值
proxies:
  - name: 示例出口
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

上例展示静态节点的基本组织方式，不能用于真实连接。udp: true 表示允许该出站使用相应能力，并不保证整条链路支持 UDP；服务端、协议、路由及应用接入方式都可能形成限制。TCP 页面访问正常，也不能用来证明语音、游戏或其他 UDP 业务一定可用。测试时应选择与实际应用相同的传输路径，分别观察连接是否进入内核、是否选中目标出站，以及服务端是否接收。

TLS、服务器名称与传输层

启用 TLS 的协议常见 servername 等服务器名称字段，其用途涉及握手与证书名称匹配，不等于本地显示名称，也不一定等于底层连接使用的 IP。服务端要求特定名称时应准确填写，不能为了绕过错误而随意换成其他域名。证书错误应先检查系统时间、证书链和参数一致性。关闭证书验证会改变安全边界，不应作为常规排查步骤，更不应写进给所有设备使用的公共配置。

传输类型、路径和请求头等配置属于另一层协商。以 WebSocket 类传输为例，路径和 Host 可能由反向代理配置决定；底层端口能建立 TCP 连接，不代表后续传输握手就成功。若日志显示连接重置或握手失败，应对照服务端提供的信息逐项检查。一次只调整一个变量并保留失败日志，比同时更换域名、端口和传输类型更有诊断价值，也能避免把暂时的网络波动误判为参数修复。

节点提供器与订阅格式

节点较多时，可通过 proxy-providers 将节点载荷与主配置分离。提供器通常返回包含 proxies 列表的 YAML，而不是任意分享链接集合，也不一定等同于完整 Clash 配置。提供器的类型、路径和更新周期描述如何获取数据，策略组再通过 use 引用它。导入失败时应先检查返回内容是否为预期格式；登录页、错误提示或 HTML 页面即使下载成功，也不是合法的节点载荷。

# 本地提供器；paths 按内核工作目录与客户端限制配置
proxy-providers:
  本地节点:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: 提供器选择
    type: select
    use:
      - 本地节点

本地提供器示例需要预先准备实际载荷文件，路径通常相对内核工作目录解析，也可能受客户端路径限制影响。不要假设相对于当前编辑器打开的文件夹。远程提供器还会涉及更新失败、缓存和访问凭据；订阅链接本身往往具备访问权限，应视为敏感信息。分享截图、日志或报错文本时，不仅要遮住密码，还应移除完整订阅地址与查询参数，避免别人取得同样的服务数据。

节点名称在整个配置里最好保持唯一，并避免与策略组名称、内置出站名称冲突。批量重命名后，要同步更新所有静态引用；使用提供器时则检查筛选表达式是否仍能匹配。某些服务更新会替换名称或删去节点，因此长期规则不宜绑定频繁变动的具体节点。更稳妥的做法是让规则指向稳定命名的策略组，由组负责适配节点变化，把业务路由和服务端清单分开维护。

策略组类型与引用关系

策略组将“某类流量应使用什么出口”与“当前有哪些节点可选”分开。规则可以始终引用一个稳定的组名，而组内节点随订阅更新变化。理解策略组时，应同时看类型、候选项和被引用的位置。一个自动选择组只有在流量实际指向它时才起作用；在界面里看见测试结果，不代表所有连接都会使用该组。顶层手动选择组如果仍选中直连，下面的自动组即使正常运行，也不会改变这条业务路径。

手动、自动测试与故障回退

select 最容易预测，适合对出口变化敏感的登录和办公业务。url-test 通过测试地址比较候选，但测试的是一类请求的完成表现，不等于真实应用吞吐量。fallback 更侧重候选顺序，适合主用与备用关系。负载分配则不意味着一个文件会同时使用全部节点叠加速度，不同分配策略还可能影响会话出口稳定性。应根据业务容忍度选择，而不是把自动化程度当作性能排名。

嵌套结构与可追踪路径

# 合并到已有节点配置后使用；示例出口须真实存在
proxy-groups:
  - name: 业务出口
    type: select
    proxies:
      - 示例出口
      - 自动选择
      - DIRECT

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

rules:
  - MATCH,业务出口

上例的连接路径是规则指向“业务出口”，再由用户决定使用静态节点、自动组或直连。嵌套有利于复用，但层级越深越难判断最终出口。建议让组名体现用途和职责，不以含糊的“默认”“其他”重复命名。禁止形成循环引用，例如甲组包含乙组、乙组又回到甲组。循环不是备用路径，而是无法确定出站的依赖错误；内核或客户端可能直接拒绝加载。

自动测试的 url、interval 和容差参数应结合服务行为设置。测试目标不可达时，多个本来正常的节点可能同时显示失败，因此不能只凭一次测试删除节点。测试过于频繁会增加连接与移动设备后台消耗，过于稀疏又会延迟状态变化。测试地址最好具备简单、可预期的响应，但仍需意识到它与真实目标服务的网络路径不一定相同，不能据此推断所有站点体验。

提供器、筛选与选择持久化

组通过 use 引用节点提供器时，候选集合会随提供器内容变化。若再使用名称筛选，应确保表达式能匹配实际名称，并考虑更新后出现空集合的情况。不要把所有分流组都依赖同一条脆弱的命名规则；一旦服务端更改标签，整份配置可能失去候选。涉及筛选时，可先在测试配置中检查匹配结果，再替换业务组；保留一个明确可用的手动入口有助于恢复。

客户端可能记住手动选择，也可能在配置切换、名称变化或缓存重建后回到默认项。组中的第一项不应承担未被文档记录的隐含安全约定。若业务要求固定出口，应在每次更新后确认选择状态，而不是只确认配置加载成功。现有连接通常也不会因为修改组选择就全部即时迁移；连接复用、长连接和客户端行为都会影响观察，验证时要创建新的请求并检查其实际路径。

面向移动设备维护配置时，应减少不必要的重复健康检查，让同一提供器的检查与组内测试各有目的。若每个业务组都完整测试同一批节点，后台请求可能明显增加。具体电池与保活设置可结合手机代理客户端耗电与后台策略阅读。策略组的目标是让出口选择更清晰，而不是用尽所有类型；能用两层结构解释清楚的路由，不必堆成多层选择树。

规则语法、顺序与规则集

规则列表是连接进入内核后的路由决策链，通常从上到下检查，首先匹配的规则决定目标出站。它不是把所有命中结果综合评分，也不会自动把更具体的规则放到前面。维护规则时，除了看单条内容，还必须检查它之前有什么。常见的“规则不生效”其实是前面的宽泛规则已经完成匹配，或客户端仍运行另一份配置。先找到连接记录中的匹配项，再改规则，比凭目标网站的地理印象调整更可靠。

域名、地址与最终兜底

# 业务出口必须是已存在的策略组
rules:
  - DOMAIN,service.example.com,业务出口
  - DOMAIN-SUFFIX,example.net,业务出口
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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,业务出口

DOMAIN 精确匹配域名，DOMAIN-SUFFIX 用于某个域名及其子域。它们匹配的不是完整网页地址，规则中不应带协议头、路径或查询参数。DOMAIN-KEYWORD 按关键词匹配，覆盖面更宽，容易误伤包含相同片段的其他域名；明确知道服务域名时优先使用精确或后缀规则。一个网站还可能加载多个资源域名，主页面匹配正确，并不代表图片、登录和接口都走同一出口。

IP-CIDR 与 IP-CIDR6 分别处理地址网段。no-resolve 的作用是避免该类匹配主动触发目标域名解析，不等于强制直连，也不负责屏蔽 DNS。若连接已有目标地址，相关地址规则仍可能参与匹配。把大段地址规则放在域名规则之前，可能使原本希望按业务名称处理的连接提前结束路由判断。顺序应体现优先级，而不是按规则类型机械分组。

规则命中依赖可见信息

域名规则能否命中，取决于内核是否知道目标域名。应用直接连接 IP、使用自己的解析结果，或某些接管路径丢失域名信息时，结果会与浏览器代理请求不同。嗅探可以在支持的场景补充部分信息，但不是任意协议都能恢复原始域名，也不能用来绕过加密保护。排查时先看记录里显示的是域名还是地址，再判断该使用域名规则、地址规则，还是调整 DNS 与接管方式。

MATCH 是最终兜底，通常放在列表末尾。它之后的普通规则不会获得匹配机会。内置出站 DIRECT 表示直连，REJECT 用于拒绝，而自定义目标必须与节点或组名一致。写错大小写、混入不可见空格或重命名后漏改引用，都可能导致加载失败。维护拒绝规则时尤其需要限定范围，先用明确测试对象验证，不应将模糊关键词直接扩展到整份订阅。

规则提供器与载荷行为

rule-providers:
  内网域名:
    type: file
    behavior: domain
    path: ./rules/internal.yaml

rules:
  - RULE-SET,内网域名,DIRECT
  - MATCH,业务出口

# ./rules/internal.yaml 的内容
payload:
  - "+.home.arpa"
  - "+.lan"

规则集把大列表从主文件中分离出来，便于更新和复用。behavior: domain 的载荷是域名规则内容，地址类载荷与经典规则载荷有不同格式，不能只更改行为字段就继续沿用原文本。经典载荷通常放匹配条件，由主配置里的 RULE-SET 规则指定目标出站；应对照所选格式检查，而不是把完整主配置规则不加区分地塞进所有类型的载荷中。

远程规则更新还带来维护边界：上游可能增删范围，缓存可能让旧结果继续生效，下载失败也可能仅保留已有文件。应记录规则集来源和用途，避免两个覆盖面高度重叠的集合以相反目标连续出现，却没有明确优先级。与节点订阅一样，文件更新成功只证明获取完成，不证明业务结果符合预期。更新后至少抽查一条应命中和一条不应命中的请求，确认边界没有变化。

进程规则依赖平台与进程识别能力，不宜直接作为跨系统配置的唯一分流依据。应用名称也可能因启动器、子进程和容器环境改变。遇到 Windows 商店应用完全没有连接记录时，要先判断请求是否能到达代理入口，可参考UWP 回环豁免设置，不要在没有流量进入内核的情况下反复追加路由规则。规则只处理已接收到的连接，无法补救入口层面的隔离。

订阅覆写、合并与更新顺序

订阅更新与本地自定义最容易发生冲突。远端订阅负责交付节点、策略组或规则，本地用户可能希望固定端口、增加内网直连，或改变某些业务出口。直接编辑已下载的原始订阅，下一次更新时很可能被重新生成的文本替换。可靠的维护方式是保留远端来源，将本地意图写在客户端支持的覆写入口，并确认这些修改在最终运行配置中的位置，而不是只确认编辑器保存成功。

先确定谁拥有最终决定权

不同客户端的处理链并不完全一致，可能经历订阅下载、解析转换、配置级覆写、全局覆写、GUI 设置注入和内核加载等阶段。本页不能为所有客户端给出统一的执行顺序。应在所用客户端中查看预览或运行配置，并通过一个可观察字段验证实际结果。例如只修改日志级别，应用后查看最终值；确认该入口确实参与当前订阅的生成，再迁移较复杂的规则和 DNS 设置。

覆写不是一种固定的 YAML 语义，而是客户端或工具实现的变换过程。标量可能被替换，映射可能递归合并，列表可能整体替换、追加或前置；这些行为由具体实现定义。所谓“深度合并”也不能自动解决规则优先级，因为规则列表本来就有顺序。看见两个 rules 片段不应推断它们会自动拼接，更不能把某个客户端专用的前置键当作内核原生字段复制给其他客户端。

映射与列表应分别检查

# 期望得到的最终片段；不是通用于所有客户端的覆写语法
dns:
  enable: true
  nameserver:
    - https://dns.google/dns-query
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - MATCH,业务出口

上例强调的是最终目标结构。若覆写工具对 dns 整体替换，原有的监听、启动解析和过滤项可能被一起删除；若对 nameserver 追加，又可能留下原本想移除的上游。规则更需要检查插入位置：自定义内网规则应放在会抢先匹配的兜底之前，而不是追加到已有 MATCH 后面。预览最终配置时，应同时看字段值和列表位置，不能只用搜索功能确认字符串存在。

引用稳定性与冲突处理

自定义规则若指向订阅生成的组名，上游改名就会导致引用断开。可以使用名称稳定的本地业务组承担规则目标，再让它引用可更新的节点或提供器；前提是所用覆写机制能可靠创建并保留该组。不要简单建立一个与订阅同名的组来“覆盖”，因为某些合并方式会产生重复名称，而不是替换原项。需要替换时，应明确删除旧对象或使用工具提供的对象变换能力，并在最终列表里确认唯一性。

一份订阅可能为不同平台携带不同默认值，跨设备同步覆写时不能忽略本机差异。DNS 监听地址、局域网网段、TUN 权限和本地文件路径通常属于设备环境，不适合原样共享。建议把自定义内容分成通用业务规则与设备设置两部分，并在注释中说明用途及依赖。这样换电脑或更换客户端时，可以保留业务意图，重新适配入口与权限，而不是把整份旧运行配置当作新的订阅源。

使用脚本覆写时，应将其视为能修改完整配置的代码，而不只是另一种注释格式。脚本异常可能使生成中断，错误的对象访问也可能删除字段或把类型改错。保持变换范围小，明确输入为空、列表不存在和名称未匹配时的处理方式。不要为了添加一条规则而重建全部节点列表；每一次无关重写都会扩大订阅更新后的故障面。脚本与 YAML 分开备份，方便确定问题来自哪一层。

更新后的回归与迁移

完成覆写后，至少执行一次更新测试：先备份，触发订阅刷新，再查看运行配置和连接路径，确认自定义规则、组选择与 DNS 字段仍在。只在手工应用后成功，不能证明自动更新链路也正确。若更新后异常，应先暂时停用本地覆写，判断原订阅是否能运行，再逐层恢复。关于从停止维护客户端迁移的取舍，可阅读迁移到 Clash Verge Rev 的方案对比，重点保留配置意图，而非旧界面的缓存状态。

配置验证、故障定位与维护

验证配置需要分层进行：先确认文本能解析，再确认内核接受字段与引用，随后检查监听入口，最后验证解析、路由和业务行为。能通过配置测试，只说明当前内核能够理解文件，不保证服务器可达、密码正确或目标服务允许访问。网页能打开也只能证明这一条请求成功，不能替代局域网、UDP、后台应用和订阅更新等其他路径的检查。把每次测试的输入、预期和观察结果写清，比笼统记录“正常”更有用。

从离线检查到运行检查

# 已安装 Mihomo 且命令可用时，在配置所在目录执行
mihomo -t -f ./config.yaml

# Windows PowerShell 中，若可执行文件位于当前目录
.\mihomo.exe -t -f .\config.yaml

命令只适用于实际安装了内核程序的环境。GUI 客户端可能使用自己的工作目录、受控路径和生成文件，不能随意用外部内核覆盖正在运行的实例。测试本地提供器时，还要确认相对路径与工作目录一致，否则主文件语法正确也可能因载荷文件不存在而失败。错误信息通常包含字段、名称或行号，应从第一条有意义的错误开始处理，后面的多条错误可能只是同一个层级问题引起的连锁反应。

测试通过后，检查当前客户端是否真的选中并加载了这份配置。观察日志中的加载结果、监听地址和可能的权限错误；端口占用、TUN 创建设备失败与订阅获取失败属于不同阶段，不应统一归结为节点不可用。若配置加载被拒绝，有的客户端可能保留之前的运行状态，所以“网络仍能用”不代表新配置已经生效。对照一个刚修改的可观察字段，可以避免把旧状态当作新结果。

用最小闭环验证请求

# 显式指定 HTTP 代理入口，排除应用是否遵循系统代理的差异
curl -I --proxy http://127.0.0.1:7897 https://example.com/

# SOCKS 入口；h 表示把目标域名交给代理侧处理
curl -I --proxy socks5h://127.0.0.1:7897 https://example.com/

这些命令用于检查明确的代理入口，目标示例服务不承诺始终返回某种状态码。收到 HTTP 错误响应与无法建立代理连接是两类结果：前者说明请求至少已到达某个 HTTP 服务，后者还要检查监听、协议和路径。Windows 环境若 curl 被其他命令别名占用，可确认是否应调用 curl.exe。不要把一条命令的成功直接外推到浏览器，浏览器还可能使用扩展、自带解析或已有连接池。

建立能回退的修改流程

每次只修改一个层面，保留修改前的文件和一段简短说明。备份不仅应包含主配置，还要包含本地提供器、规则载荷和覆写脚本，否则恢复主文件后仍可能引用已经改变的数据。文件名可体现用途与保存日期，但不必把敏感订阅地址写进去。涉及系统代理、DNS 或 TUN 时，同时记录关闭后的恢复方法；远程连接设备上修改默认路由前，尤其需要准备不依赖该代理的恢复通道。

复现问题时，关闭无关代理实例，使用固定测试目标，分别比较直连和显式代理结果。若只在某个应用发生，应记录该应用的接管方式、解析方式和进程路径，而不是立即替换整份订阅。若所有节点同一时间失败，应检查本地网络、解析上游和测试目标；若仅个别节点失败，再深入服务端与协议参数。这样的分支顺序能够减少无关修改，也使日志与实际故障保持对应。

长期维护还应检查已经失效的自定义内容：不再使用的规则集、旧网段、改名后的组引用，以及为一次故障临时添加的例外。每次订阅或客户端升级后，优先核对这些边界，不需要重新测试所有网页。向他人求助时提供脱敏的最小配置、错误文本、接管方式和预期路径即可；常见入口问题可继续查阅疑难解答，首次连接问题则回到使用指南按主线逐步验证。