Clash 进阶配置手册

策略组类型与分流实战

把规则目标与节点选择分开

策略组是规则和实际出站之间的中间层。规则决定连接应该交给哪个组，组再决定使用哪条出站。把业务规则直接绑定到某个节点名称，会让节点改名、订阅替换和服务商调整同时影响规则。建立稳定的组名后，只需要维护组内成员，规则仍然引用同一个目标，长期维护成本更低。

proxies 定义具体出站，proxy-groups 定义可被选择或自动调度的集合，rules 按顺序引用它们。三个位置的名称必须完全一致，空格、大小写和中文标点都不能随意变化。组可以引用其他组，但不能形成循环依赖；例如业务组指向自动组、自动组再指回业务组，会导致配置无法建立有效的选择路径。

按选择行为确定组类型

select 用于手动选择，适合保留明确出口的场景。url-test 根据探测结果选择出站，适合一组用途相近的线路。fallback 按成员顺序检查可用性，优先维持前面的可用出口。load-balance 按策略分配连接，不等于把多个节点带宽叠加到同一个下载任务，也不保证同一账号的所有连接始终从同一个地址发出。

建立业务组与自动组两层结构

下面示例使用内核内置的直连出站，因此可以展示组之间的真实引用关系，但不会产生代理效果。实际使用时，把自动组中的直连成员替换为现有节点名称，或通过 use 引用已经定义的代理提供者。保留手动入口，便于自动选择不符合业务需求时快速切回固定出口。

proxy-groups:
  - name: 自动出口
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 日常访问
    type: select
    proxies:
      - 自动出口
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,日常访问
  - MATCH,日常访问

interval 的单位是秒，表示检查周期；tolerance 的单位是毫秒，用于减少小幅差异引发的频繁切换。lazy 控制组未使用时的检查行为。探测地址应能稳定访问，并且尽量符合线路用途。只依据一个轻量网页的探测结果，不能判断大文件传输、视频播放或特定地区服务的表现。

有登录状态的业务适合单独建立手动组，并尽量保持出口稳定。将购物、支付或账号管理连接放进不断轮换的出口集合，可能触发服务端的风险判断。需要切换时，先停止相关任务，再选择目标节点并重新建立连接；已经建立的连接通常不会因为组选择变化而自动迁移。

从实际命中反查组链路

排查时先在连接详情确认规则目标，再展开策略组当前选中项，最后确认具体节点。界面显示选择了某个节点，不代表目标网站一定经过这个组：规则可能更早命中直连，或者应用根本没有进入内核。先验证路径，再比较线路，能避免把规则问题当成节点问题。

如果组显示为空，检查成员名称是否存在、代理提供者是否加载成功，以及筛选表达式是否把全部节点排除了。不要通过反复切换全局模式掩盖引用错误。模式含义可回看出站模式教程；理解 YAML 各段的对应关系，可继续阅读配置文件逐段拆解。

规则集订阅化管理

先确定规则顺序，再拆分规则来源

规则从上往下匹配，通常在找到首个符合条件的条目后确定出站目标。更具体的域名规则应放在宽泛的地区规则之前，最终兜底放在末尾。把规则拆成外部文件只是改变维护方式，不改变这个顺序模型。一个维护良好的规则集如果放错位置，仍可能永远没有机会匹配。

rule-providers 用来声明规则资源，RULE-SET 用来把资源接入匹配链路。提供者名称只是引用标识，不会自动决定走代理还是直连；真正的策略目标写在 RULE-SET 后面。相同规则集可以在不同配置里绑定不同策略组，便于把分类数据和个人出站偏好分别维护。

理解 behavior 与 format 的区别

behavior 说明内容如何被解释。domain 用于域名集合，ipcidr 用于地址网段，classical 则保留完整规则类型，例如 DOMAIN-SUFFIX 或 IP-CIDR。format 说明文件编码形式，常见有 YAML、纯文本和 MRS；文件扩展名只是命名习惯，不能代替对实际内容格式的确认。

下面先用内联提供者展示一条完整的接入关系。它不依赖远程下载，适合验证名称、行为类型和规则顺序。classical 内容里的每项规则不再写策略目标，因为目标已经由引用它的 RULE-SET 指定。把策略名称重复塞进条目，容易造成格式不兼容。

rule-providers:
  本地例外:
    type: inline
    behavior: classical
    payload:
      - DOMAIN-SUFFIX,example.com
      - IP-CIDR,192.168.50.0/24,no-resolve

rules:
  - RULE-SET,本地例外,DIRECT
  - MATCH,DIRECT

确认本地结构能加载后，再把需要集中更新的部分改成远程提供者。以下地址用于演示，应用前必须换成真实可访问、内容格式对应的规则文件；不要把它当作现成的规则服务。相对 path 由内核工作目录解析，不一定等于客户端可见的订阅目录。

rule-providers:
  业务域名:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/business.yaml
    path: ./rules/business.yaml
    interval: 86400

rules:
  - RULE-SET,业务域名,DIRECT
  - MATCH,DIRECT

设计更新与离线恢复路径

远程更新要同时考虑首次启动和后续刷新。首次启动没有本地缓存，资源地址又依赖尚未建立的代理链路时，可能陷入启动依赖问题。优先选择当前网络能访问的规则来源；需要指定资源下载出口时，先核对当前内核支持的提供者字段，并保证该出口不反向依赖这个规则集。

更新周期不宜过短。规则分类通常不是秒级变化的数据，频繁拉取会增加网络请求，也让错误更新更快扩散。保留可恢复的上一份配置，观察日志中提供者是否完成加载；已经存在的缓存能否继续使用，取决于缓存状态、客户端目录和失败类型，不能把它当作永久保障。

规则集路径应各自独立，不要让多个提供者写入同一个文件。迁移电脑或重装客户端时，也不要只备份主 YAML 而忘记本地规则文件。移动端应用沙箱与桌面文件目录不同，直接复制绝对路径通常不可移植；长期配置优先采用清晰的相对目录，并记录哪些文件由客户端托管。

处理误匹配与 DNS 副作用

遇到网站误分流，先看实际命中的规则名称，再判断是分类数据错误还是顺序错误。个人例外通常放在公共规则集之前，只写必要的域名或网段。不要为修复单个域名而把整个大类改成直连，否则同一规则集里的其他业务也会一起改变路径。

no-resolve 用于避免某些地址类规则为了判断而触发额外域名解析，不是关闭整个连接的 DNS。若应用已经提供目标 IP，地址规则仍可以正常检查。域名与地址规则混排时，要明确哪一步可能发起解析，否则容易把规则引发的查询误认为 DNS 重复请求。

DNS 配置与解析路径优化

沿查询链路定位解析发生在哪里

DNS 优化首先要弄清查询路径：应用把域名交给谁，系统是否接管，内核是否收到查询，最后由哪个上游返回结果。只修改主 YAML 里的 DNS 地址，不能保证浏览器、系统服务和独立应用全部改走相同路径。浏览器自带的加密 DNS、应用内解析和缓存都可能让测试结果偏离预期。

系统代理主要接管遵守代理设置的应用流量，并不天然接管系统所有 DNS。TUN 可以扩大接管范围，但仍受路由、劫持规则和应用行为影响。验证时应选定一个测试应用、清理必要缓存，并对照内核日志中的域名信息；不要同时切换上游、增强模式和路由设置，否则很难判断哪个调整起作用。

区分引导解析、普通解析与节点解析

default-nameserver 主要解决 DNS 上游自身域名的引导解析问题。nameserver 是常规查询的上游集合。proxy-server-nameserver 专门处理代理节点域名，有助于避免节点解析依赖代理、代理建立又依赖节点解析的循环。这几组字段并不是简单的主备关系，不能只按名称理解为依次失败才切换。

nameserver-policy 用于让指定域名使用特定上游，例如局域网服务或企业内部域名。匹配语法应按当前内核文档确认；对普通后缀可使用 +.example.com 这样的写法。内部域名应交给能识别它的内部 DNS，而不是发送到公共解析器后再期待返回私有服务地址。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.example.com":
      - 192.168.50.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"

示例中的内网 DNS 地址需要替换为实际路由器或组织提供的解析器。若没有内部域名需求，应删除对应策略，而不是保留一个不可达地址。加密 DNS 改变查询传输方式，不会自动保证查询走代理；它的连接出口仍需要结合内核 DNS 选项、路由和规则判断。

谨慎引入规则跟随与备用解析

respect-rules 可以让 DNS 上游连接遵循路由规则，但它也增加了依赖关系。启用前要为节点域名准备可用的专用解析路径，并确认规则中没有让解析器的连接再次依赖尚未建立的出口。网络已经稳定时，不应只因为字段看起来更完整就开启它。

使用 fallback 与 fallback-filter 时，先理解内核如何判定哪些结果可接受。备用上游并不只是常规上游超时之后才出现的替补；筛选条件可能决定返回哪组结果。把大量地域条件和地址过滤复制进配置，却不知道实际网络环境，容易产生额外查询和不一致的地址选择。

IPv6 需要把 DNS 回答、系统路由、节点能力和目标站点连通性一起评估。dns.ipv6: false 主要影响内核的解析回答，不等于系统层完全禁用 IPv6，也不能阻止应用使用已经缓存的地址。若只在部分网站出现等待，应对照连接详情确认是否先尝试了不可达的 IPv6 路径。

按现象缩小排错范围

域名完全无法解析时，先检查上游地址是否可达，以及上游自身的域名能否完成引导解析。只有节点连接失败时，优先查看节点域名解析。只有内网服务异常时，检查是否错误发送到公共上游。多个无关网站同时卡顿，则需要比较系统原生解析与内核解析，判断问题是否真的来自 DNS。

解析成功不代表目标地址可访问。日志已经拿到地址但后续连接超时，应继续检查规则出口、防火墙和线路，不要无限更换 DNS。浏览器缓存、系统缓存与内核缓存相互独立，修改后要按测试范围清理，并关闭旧连接。关于缓存残留和传输瓶颈的区分，可参阅网速慢的分层排查。

TUN 虚拟网卡与 Fake-IP

先区分流量入口和 DNS 增强模式

TUN 在系统中建立虚拟网络接口，把符合路由条件的流量送进内核。Fake-IP 则是 DNS 增强模式：内核为域名返回虚拟地址，再通过映射关系还原域名并执行后续处理。两者经常一起使用，但不是同一个开关。启用 TUN 不代表已经接管 DNS，启用 Fake-IP 也不代表所有应用都经过虚拟网卡。

系统代理适合浏览器和遵守代理设置的程序；TUN 更适合需要接管系统代理之外流量的场景。切换前先确认原有系统代理链路正常，再单独验证 TUN。若同时安装其他 VPN、虚拟网卡软件或终端安全产品，需要检查默认路由和接口优先级，不要假设多个接管工具能够自动协调。

从最小路由设置开始

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"

auto-route 用于自动配置相关路由，auto-detect-interface 用于自动识别出口接口。stack 决定流量处理栈，不是性能等级开关；不同系统、协议和应用的兼容性不同。先用客户端当前支持的默认值，只有在复现问题并记录对照结果之后，再比较其他可用栈。

dns-hijack 中的常规端口劫持主要针对普通 DNS 流量，不能凭此认定加密 DNS 也被转换成内核查询。实际效果还取决于操作系统和路由行为。应用直连加密解析服务时，可能绕开预期的域名映射，需要检查应用自己的解析设置，而不是不断添加端口规则。

处理权限与平台差异

桌面端应优先通过客户端提供的服务安装和授权流程启用，不建议长期以过高权限运行整个桌面会话。Android 的 VPN 授权由系统管理，常规情况下不能同时运行两个占用同一 VPN 通道的应用。iOS 用户应选择对应客户端入口，不要把桌面 TUN 字段视为各平台完全一致的操作说明。

设备连接企业网络时，内网网段、专用 DNS 和安全软件可能有额外要求。先确认组织允许的接入方式，再配置必要的路由排除。不要直接复制覆盖全部私有地址的排除列表，因为部分业务可能确实需要进入内核；排除范围应与真实网段一致，并避免让远程服务误走局域网出口。

维护 Fake-IP 映射与兼容例外

Fake-IP 返回的虚拟地址不是节点地址，也不是目标服务器真实地址。应用把连接发往该地址后，内核依据映射恢复域名。配置切换或内核重启后，如果系统仍缓存旧的虚拟地址，而内核映射已经变化，可能出现短暂失败。应先清理相关缓存并重建连接，再考虑是否需要持久化映射。

fake-ip-filter 让匹配的域名回到真实地址解析，适合确实依赖真实地址的局域网发现或特定应用。不要为了排错一次加入整个互联网的大范围过滤，否则会失去 Fake-IP 带来的域名关联能力。过滤后仍需检查真实地址是否正确、访问规则是否合理，过滤本身不会修复不可达的服务器。

判断接管成功，应在连接页看到测试应用的新连接，并确认命中规则和出口，而不只是看到 TUN 开关处于开启态。关闭 TUN 后也应检查网络是否恢复、系统是否残留手动代理。安装与权限问题可先回到教程；需要更换客户端时，在下载中心按平台选择，不要同时运行多个代理入口做对照。

域名嗅探与规则命中

理解嗅探能够补充的信息

有些连接进入内核时只携带目标 IP，缺少可直接用于域名规则的信息。域名嗅探尝试从协议握手或请求内容中提取主机名，例如 HTTP 的 Host、TLS 握手中可见的服务器名称，或受支持的 QUIC 握手信息。它补充的是路由线索，不是把加密网页正文解密，也不能保证每条连接都有可识别的域名。

在 Fake-IP 映射完整的情况下，内核通常已经知道对应域名，嗅探的作用可能较小。应用自行解析、直接使用真实 IP，或者查询没有经过内核时，嗅探才更可能改善域名规则命中。先确认缺失信息发生在哪一步，再决定是否开启；已经稳定的链路不需要为了配置齐全而增加额外判断。

限制协议与端口范围

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "+.example.com"

示例把范围限制在常见网页端口。parse-pure-ip 允许对纯 IP 目标尝试嗅探，force-dns-mapping 用于扩展部分 DNS 映射场景下的嗅探处理；它们不会凭空生成应用没有发送的主机名。端口范围越宽，需要判断的流量越多，非网页协议被误当作候选的可能性也越高。

override-destination 决定是否用嗅探结果改写连接目标，而不仅是补充匹配信息。改写可能触发新的域名解析，导致连接到与应用原先选择不同的地址。对于依赖特定入口、地址亲和或局域网解析的服务，这种变化需要谨慎评估；初次测试可以先保持关闭，观察路由信息是否已经足够。

给兼容问题建立精确例外

skip-domain 用于跳过已知不适合嗅探的域名。示例后缀只是说明格式，实际应写出现问题的服务。加入例外之前，先比较关闭嗅探与开启嗅探时的连接日志、目标地址和规则。只有能够稳定复现的差异，才适合形成长期例外，否则容易把暂时的线路问题固化成不必要的配置。

如果应用使用固定 IP，握手又不包含域名，域名规则就没有可靠依据。此时可以考虑明确的 IP 规则，或者在客户端和平台支持的范围内使用进程规则。不要为了让某条域名规则命中而虚构映射；一个地址可能承载多个服务，用反向解析得到的名称也不等于应用真正访问的主机名。

加密客户端问候等技术可能减少可见的握手信息，非标准协议也可能无法识别。QUIC 能否被正确解析还受内核能力和实际握手结构影响。嗅探没有得出域名不一定是配置错误；需要回到入口和 DNS 链路，判断是否应让应用查询先经过内核，而不是无限扩大嗅探端口。

用同一条连接验证规则变化

对照测试时，先关闭测试应用的既有连接，再打开单个目标页面。在连接详情记录原始目标、识别域名、命中规则与最终出站。之后只改变嗅探开关或一个参数，重复同样步骤。旧的长连接不会自动重新完成握手，直接刷新页面有时仍会复用原连接，导致测试看起来没有变化。

域名嗅探与规则优先级是两个不同问题。即使已经识别到正确域名，前面更早命中的地址规则或进程规则仍可能先决定出站。看到不符合预期的结果，应先读命中规则，再调整顺序。全局模式下看到代理连接，也不能用来证明某条域名规则已经工作。

若启用后只是少数应用首包变慢，检查嗅探范围是否过宽、目标协议是否受支持，以及是否开启了不必要的目标改写。不要立刻归因于节点质量。可以先收窄到一个协议和端口，保留最小复现，再阅读日志页常见报错区分握手失败、解析失败和连接超时。

本地覆写与多订阅合并

保留订阅原文，明确最终生效配置

订阅是外部输入，客户端保存的 Profile 是配置容器，内核读取的则是最终有效配置。这三者可能并不完全相同：客户端可能追加端口设置、TUN 选项和本地覆写，也可能在重新加载时重新生成文件。直接修改缓存中的订阅原文，下一次更新后通常难以保留，因此不适合作为长期维护方案。

先在配置页确认当前启用的是哪一份 Profile，再查看客户端是否提供覆写、扩展或配置编辑能力。不同客户端对入口名称与合并行为的处理不同；FlClash 中应以当前界面和实际生成结果为准。界面里没有对应功能时，可以维护独立的本地完整配置，不要假设任意 YAML 片段都能被自动合并。

本地覆写适合保存个人规则、DNS 偏好和控制器限制；订阅提供者继续负责节点信息。把两者拆开后，更新线路不必重写个人规则，更换设备也能看清哪些内容属于自身环境。基础概念可参阅Profile 与多配置管理，订阅首次导入仍按教程主线操作。

分别处理映射、列表与引用

YAML 映射和列表不能用同一种直觉处理。映射可能逐键合并，也可能整个对象替换；列表可能追加、前插或完全覆盖，具体由客户端覆写机制决定。尤其是 rules，追加到已有 MATCH 后面的规则通常不会命中。写完片段后必须检查最终顺序，而不是只确认编辑器成功保存。

下面的内核字段可用于记录选择和映射状态，但是否由客户端接管、配置切换后是否沿用，仍需结合实际行为验证。它们不是多个订阅内容的合并指令，也不会修复重名节点。对于工作网络与家庭网络等环境差异较大的场景，保留独立 Profile 往往比不断叠加条件更容易维护。

profile:
  store-selected: true
  store-fake-ip: true

如果需要把不同来源节点放到同一套策略组，可以使用 proxy-providers，但来源必须输出内核支持的代理提供者内容。完整 Clash 配置、普通节点链接列表和其他订阅格式不一定能直接作为提供者文件使用。先检查内容结构，确认它是以 proxies 为主体的有效节点集合。

用代理提供者连接多个来源

proxy-providers:
  线路甲:
    type: http
    url: https://example.com/provider-a.yaml
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  线路乙:
    type: http
    url: https://example.com/provider-b.yaml
    path: ./providers/b.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 合并选择
    type: select
    use:
      - 线路甲
      - 线路乙

rules:
  - MATCH,合并选择

示例地址需要换成真实提供者地址，两个缓存路径必须不同。不要把订阅凭据写进公开截图、博客或共享仓库。真实配置备份也应按敏感文件处理，因为节点口令、订阅链接和控制器口令可能同时存在其中。提交排错材料时，只保留结构和已经脱敏的示例值。

多来源容易出现同名节点。名称既用于界面展示，也可能参与持久化选择和规则引用，重名会使判断变得模糊。若当前内核支持提供者命名覆写，可按文档给来源添加前缀；不支持时应在可控的数据处理环节改名，或拆开使用。不要用简单文本替换修改整个 YAML，以免同时破坏规则目标和组名。

建立可以回滚的更新流程

更新前保留上一份可用配置及本地覆写，更新后依次确认提供者加载、组成员、规则顺序和 DNS 设置。必要时用内核的配置测试功能检查语法，例如在对应二进制目录运行 mihomo -t -f ./config.yaml。这只能证明配置能够解析，不能证明节点可达或规则符合业务预期。

重载后先建立一个新连接，确认出站与预期一致，再恢复其他应用任务。若失败，先撤销最近的一层覆写，不要立即删除全部 Profile。排错记录应写清原配置、修改片段、最终生成结果和错误日志。逐层回退比反复重新导入订阅更容易找到问题，也能保留已经验证有效的个人设置。

外部控制面板与维护流程

区分代理入口和管理入口

mixed-port 等代理端口负责接收业务连接，external-controller 负责管理接口。控制面板通过管理接口读取连接、切换策略组或调整运行状态，它本身不是新的代理节点。开放允许局域网连接的代理选项，也不意味着管理接口就应该一起对外开放，两者必须分别评估。

桌面客户端通常已经使用内部控制接口管理内核。手动修改监听地址、端口或口令，可能导致客户端界面无法连接自己的内核。先检查客户端是否允许自定义这些字段，以及它是否会在启动时重新生成值。遇到界面显示断开但业务仍可访问，应优先检查控制接口，而不是立即判断代理内核已经停止。

默认只监听本机

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui

这里的口令是教学假值，实际使用时必须替换为独立的高强度口令。external-ui 指向已准备好的面板静态文件目录，填写路径不会自动生成页面。相对目录按照内核工作目录解析，客户端沙箱、服务运行账户和文件权限都可能影响能否读取。配置后先确认本机接口可达，再检查面板文件。

如果不需要网页面板，可以省略 external-ui，保留客户端自身的管理方式。确实需要面板时，应使用与当前内核接口兼容的静态资源，并通过受信任的渠道准备文件。不要因为面板显示字段缺失，就随意开启更多监听地址；先判断是面板兼容性、接口鉴权还是内核返回内容的问题。

检查浏览器连接与鉴权

面板能够打开，只说明静态页面可访问，不代表它已经成功连接控制接口。需要分别检查 API 地址、口令和事件连接。浏览器控制台里，连接被拒绝通常指向端口或监听问题；鉴权失败应检查口令；页面来自另一来源时，还可能受到跨来源策略限制。每种错误的修复位置不同。

HTTPS 页面请求 HTTP 控制接口可能被浏览器按混合内容限制，即使两端网络实际可达。跨来源许可也不应直接设为允许任意网站携带凭据访问；先明确面板部署来源，再按内核支持的设置最小化授权。口令不应放在公开链接的查询参数里，以免进入浏览器历史、截图或访问日志。

远程管理优先通过受控的本地转发或可信网络访问本机接口。必须监听局域网时，配合防火墙限制来源地址，并确认网络环境是否可信。不要直接把控制端口映射到公共网络。接口可以改变策略甚至影响现有连接，其权限边界比只读状态页面更大，不能当作普通展示端口处理。

从只读信息开始排查

首次连接面板后，先查看运行模式、策略组和连接记录，不要立即修改全局设置。对照客户端界面确认两者管理的是同一个内核实例。机器上同时启动独立 mihomo 与桌面客户端时，端口不同的实例可能使用完全不同的配置；面板里切换成功，却不影响实际业务，往往是连错了实例。

排查顺序可以固定为：确认内核运行，确认接口监听，确认鉴权，通过面板读取配置，再观察新连接。每一步只解决当前层的问题。业务连接正常但面板空白，应查静态资源和浏览器；面板正常但业务失败，应回到代理入口、规则、DNS 和节点，不要让管理界面的表现取代真实连接测试。

整理长期维护与恢复清单

每次较大调整都保留变更说明：修改了哪些字段、对应什么现象、怎样验证、如何撤回。备份主配置时，同时记录本地规则目录、提供者缓存路径和由客户端管理的覆写内容。迁移后先恢复最小可用链路，再逐项恢复 TUN、DNS 策略与控制面板，避免把旧系统的路径和权限问题一起复制过去。

客户端更新与内核更新不一定同时发生。遇到未知字段、配置测试失败或面板功能不一致，应核对当前实际运行的内核能力，不要凭界面外观推断支持情况。需要重新选择客户端，可到下载中心查看平台入口；从头恢复连接时，返回订阅导入与连接教程，先完成主线，再逐章恢复本页的进阶设置。