Clash 进阶配置手册

策略组类型与实战

策略组负责决定一条已匹配规则的连接最终使用哪个出口。它不负责接管系统流量，也不负责把域名解析成地址。排查时先确认连接进入内核，再看命中的规则指向哪个策略组，最后检查组内选择。只在代理页换出口，却没有核对规则目标，可能一直操作着与当前连接无关的组。

先明确手动选择与自动选择

select 是手动选择组，适合需要明确控制出口的业务；url-test 按探测结果自动选择，适合对连通性变化较敏感的常用出口；fallback 按列表顺序使用可用成员，强调优先级而不是每次寻找最快成员。三者的区别是选择逻辑，不代表能够改变节点本身的线路质量。

load-balance 用于在多个出口之间分配连接，并不把一次下载拆成多条线路叠加带宽。不同分配策略可能影响同一服务看到的源地址。如果账号服务要求会话保持，先使用固定出口，或确认一致性分配是否符合需求，不宜把自动轮换当作所有网站都适用的默认方案。

健康检查访问的是组里配置的探测地址，而实际业务可能使用另一套域名、协议与端口。探测成功只说明该测试路径可达，不等于所有站点都能访问。测试频率过高还会产生额外连接与移动端唤醒，应按使用环境设置，不要为了界面持续刷新而把间隔压得很短。

从可解释的小配置开始

下面的组只引用内置的直连与拒绝策略，用来演示命名和引用关系，不会生成代理出口。配置载入后，可在代理页切换选择，再发起新的测试连接，观察放行与拒绝的区别。确认理解这一链路后，再把已有订阅中的真实节点名或下级组名加入列表，名称必须逐字一致。

proxy-groups:
  - name: 手动出口
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,手动出口
  - MATCH,DIRECT

真实使用时可让业务组指向一个自动选择组，也可保留直连作为手动排错入口。但组之间应形成单向引用关系，不能让甲组包含乙组、乙组又包含甲组。节点改名后，规则与组成员中的旧名称不会自动获得新含义；遇到配置加载失败，先检查日志里的不存在目标和循环引用提示。

如果成员来自 proxy-providers，组通常通过 use 引用提供者，而不是把提供者名称写进 proxies 当节点。提供者是节点集合的来源，策略组是集合之上的选择逻辑。将两层职责分开，订阅替换时只需调整来源，业务规则仍可引用稳定的组名。

验证选中结果与连接生命周期

修改组内选择通常作用于之后建立的连接。浏览器复用的连接、正在运行的下载或长连接应用，可能继续使用旧出口。测试前关闭对应连接，再重新发起请求；需要中断业务时先保存工作。不要只刷新页面就认定新出口已经生效，连接页显示的链路比网页是否刷新更有判断价值。

自动组反复切换时，先检查成员是否过多、探测目标是否被特殊处理、测试路径是否受 DNS 影响，再考虑调整容差与间隔。一次只修改一个因素，记录原值和结果。如果所有成员都失败，应优先检查共同依赖，例如本地网络、订阅有效性和节点域名解析，而不是继续叠加自动选择层级。

规则集订阅化管理

规则集把域名、地址或经典规则从主配置中分离，适合维护经常变化的业务清单。主配置只保留来源定义、引用位置和出口选择，内容更新由规则提供者承担。这样可以避免每次增加一个域名都改动整份订阅，也能明确区分“匹配条件变化”和“出口策略变化”这两类操作。

区分规则内容、格式和引用

rule-providers 定义可读取的规则源，RULE-SET 才把规则源放进匹配流程。只声明提供者而没有引用，规则不会主动生效。引用规则中的目标仍需是已存在的策略组或内置策略。规则集本身通常不应该携带业务出口，否则同一份清单就难以在不同配置之间复用。

behavior 描述内容语义：domain 用于域名集合，ipcidr 用于地址段，classical 用于经典规则表达式。format 则描述存储格式。把经典规则文件按域名集合加载，即使文件能够下载，也可能解析失败。选择来源时必须同时核对内容格式与行为类型。

下面使用本地经典规则集，适合先确认路径和引用关系。示例中的相对路径由内核工作目录解释，不是网页所在目录，也不一定是安装目录。请在客户端能管理、且内核具有读取权限的配置目录内建立文件，再从日志确认加载位置。不同客户端对工作目录的安排可能不同。

# 主配置中的片段
rule-providers:
  work-sites:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work-sites.yaml

rules:
  - RULE-SET,work-sites,DIRECT
  - MATCH,DIRECT

# ./rules/work-sites.yaml
payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.org

远程更新需要独立检查下载链路

从本地文件迁移到远程规则源时，需要按来源文档设置 type: http、实际地址、缓存路径和更新间隔。不要把网页介绍页当作原始规则文件地址；返回一段 HTML 的成功响应，对内核而言仍是错误内容。先用浏览器检查内容形态，再看内核日志中的下载与解析结果。

规则更新失败和规则没有命中不是同一个问题。前者应检查远程地址、连接、解析和目录写入权限；后者应检查文件是否包含目标、引用是否存在、是否被更靠前的规则截走。网络失败时可能仍有旧缓存可用，因此“当前能分流”也不能证明最近一次更新已经成功。

更新间隔通常以秒为单位，应根据来源更新频率安排。静态业务清单没有必要高频下载，频繁请求还可能触发服务端限流。多个提供者尽量使用不同缓存路径，避免覆盖。变更来源地址之前保留上一份可用文件，确认新内容能解析后，再移除旧定义，减少错误更新导致的配置中断。

按首次命中原则安排规则顺序

规则按顺序判断，较具体的业务例外一般放在宽泛规则前，兜底 MATCH 放在最后。一个域名同时出现在两个规则集中时，不会自动比较哪个集合更精确，而是先命中的引用决定去向。因此维护多套清单时，除了检查重复内容，还要记录每套清单在主规则列表中的优先级。

地址规则可能需要域名解析才能获得可匹配的地址，no-resolve 可以阻止特定地址规则主动触发这一步，但不是全局关闭 DNS。给所有地址规则机械添加该参数，可能导致原本依赖解析结果的流量落入兜底。应根据应用送入的是域名还是目标地址，以及前序规则是否已匹配来判断。

验证一条规则时，选择一个明确存在于集合中的测试域名，关闭旧连接后重新访问，查看连接页的匹配类型与目标。如果日志没有加载错误，却总落入兜底，继续检查应用是否使用独立 DNS、是否直接连接地址、域名是否已被其他规则接走。不要用“整个网站似乎正常”替代具体连接证据。

DNS 配置优化

DNS 决定域名如何获得地址，但代理连接中的域名解析可能发生在不同位置。系统解析、浏览器加密解析、Mihomo 内置解析以及代理服务器侧解析不能混为一谈。排查 Clash DNS 泄漏或解析异常时，先确认是哪一个程序发起查询、查询发往哪里，再讨论是否需要改动内核 DNS 字段。

分别理解业务解析与引导解析

nameserver 定义常规解析上游；当上游使用域名表示时，还需要能够解析该上游的引导路径。default-nameserver 主要服务于这类引导需求，不是所有业务域名必经的统一入口。如果引导上游与代理出口互相依赖，启动时就可能陷入尚未建立连接却需要先走代理解析的循环。

proxy-server-nameserver 可用于单独处理代理节点域名，避免节点连接又依赖自身才能完成解析。nameserver-policy 则按匹配条件指定业务域名上游，适合内网、企业服务等需要特定解析视图的情况。不同字段解决的问题不同，不应为了增加“备用”而把所有服务器重复填入每个列表。

下面片段启用 Fake-IP，并使用加密上游处理常规查询。它展示的是字段组织关系，不保证在所有网络中都可达。使用前确认这些上游符合本地网络条件；如果客户端已经生成 DNS 配置，应把片段合并到已有映射中，避免同时留下重复的顶层 dns 键造成覆盖歧义。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query

让解析路径与连接路径能够解释

加密 DNS 保护的是查询传输过程，并不自动让查询跟随代理，也不保证其结果适合当前连接出口。直连业务可能需要本地可达的地址，代理业务可能由出口侧处理域名。出现某些网站解析出地址却连接失败时，应同时检查解析结果、规则去向和实际出口，不要只凭上游名字判断配置正确。

当需要让 DNS 连接遵循路由规则时，可以研究 respect-rules，但启用前应先准备独立的节点域名解析路径，并检查 DNS 上游本身会被哪些规则处理。否则 DNS 查询需要代理，代理节点域名又需要同一查询才能解析，配置在启动阶段就会失去可用出口。

企业域名与局域网域名尤其需要谨慎。公共解析器不一定知道内部地址，随意替换系统 DNS 会让办公应用失效。应确认内部后缀、指定解析服务器和访问该服务器所需路由，再通过策略限定范围。不要把所有域名都发送给只服务内网的服务器，也不要把内部查询无意交给外部上游。

按缓存、来源和地址族分层排查

修改 DNS 后，应分别考虑应用缓存、系统缓存和内核缓存。浏览器继续复用已有连接时，清理系统缓存也未必产生新查询。先关闭目标连接，必要时重启测试应用，再观察日志。命令行查询只能证明该工具使用的解析路径，不应直接推断浏览器、游戏和其他应用都走同一条路径。

ipv6: false 在此控制内核 DNS 的相关响应行为，不等同于关闭操作系统的全部 IPv6，也不意味着所有应用都停止尝试 IPv6。若网络具有可用 IPv6，应明确是否接管相应流量；如果只是部分地址族连接失败，应对比同一域名的地址结果与路由，而不是把关闭协议当作长期通用修复。

所谓泄漏检查应先给出预期：哪些应用必须交给内核解析，哪些内网查询保留本地路径，浏览器是否允许独立加密 DNS。检测页面看到某个解析服务名称，只能作为线索。更可靠的判断需要结合系统 DNS 设置、应用配置、连接记录与必要的网络抓取，区分设计中的直连查询和意外绕行。

TUN 与 Fake-IP

TUN 负责通过虚拟网络接口接收流量，Fake-IP 负责以合成地址保留域名映射，两者作用不同。开启 TUN 不代表 DNS 已全部进入内核，启用 Fake-IP 也不代表所有应用已经被接管。配置时需要同时检查虚拟接口、系统路由、DNS 查询路径与规则匹配，缺少任一环节都可能出现局部正常的假象。

先建立能够回退的接管方案

系统代理适用于愿意遵循代理设置的应用；不读取该设置的程序可能需要 TUN。两者不是必须叠加才能使用的固定组合。首次测试时保留当前可用方案，记录系统原有代理和 DNS 设置，再打开服务模式与 TUN。若连基础网络都失效，应先关闭新增接管，恢复连接后分析日志。

Clash Verge Rev 的 TUN 能力依赖服务权限与平台支持。Windows 应确认服务正常、虚拟接口可建立且安全软件没有阻止；macOS 需完成对应权限授权；Linux 要检查运行权限、路由与防火墙环境。相同 YAML 在不同系统上的路由实现不完全相同，不能只看开关显示为开启就认定接管成功。

下面是常见的接管片段，DNS 部分须与上一章已有映射合并。auto-route 请求内核设置路由，auto-detect-interface 用于自动识别出口接口，dns-hijack 将匹配的传统 DNS 请求送入内置解析器。它们都应在具有适当权限且网络结构清晰的环境中验证。

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 返回的合成地址用于内核关联原始域名，不是网站真实服务器地址。应用随后连接这个地址时，内核可以还原域名并使用域名规则。诊断工具看到合成地址，并不直接说明解析错误。真正需要确认的是后续连接是否被同一个内核接收，以及映射是否仍然存在。

如果应用取得合成地址后绕过 TUN 直接连接，或者休眠恢复后仍缓存着旧映射，可能出现连接失败。此时应检查路由和缓存生命周期，不宜立刻把所有域名加入排除列表。对确实依赖真实地址、进行特殊连通性检测或使用局域网发现的应用，再按最小范围设置 fake-ip-filter。

排除列表的含义受过滤模式影响，应先确认当前采用的语义，再添加条目。普通排除模式下，命中的域名返回真实解析结果；改用其他过滤模式后，列表含义可能发生变化。不要从不同教程中复制两套相反语义的片段混用。修改后清理相关缓存，并测试应用的真实业务流程。

处理多网卡、其他隧道与休眠恢复

多网卡环境下，自动检测可能选择与预期不同的默认出口。办公网络、手机热点和其他 VPN 同时存在时，先明确哪条连接承载物理网络、哪条连接服务企业资源。路由不是开关数量越多越完整，多套工具同时改写默认路由和 DNS，反而容易让连接进入循环或被送到错误接口。

strict-route 可以在特定平台上收紧路由行为，但不应作为首次配置时的万能修复项。它可能改变本地网络访问和与其他软件的兼容性。只有在确认普通自动路由存在绕行，并理解对应系统实现之后，再逐项测试。测试应包含网页、局域网服务、企业应用与休眠唤醒。

DNS 劫持主要针对匹配的传统查询，不会把应用内所有加密 DNS 自动变成普通查询。浏览器和应用自己的解析连接仍可能需要单独配置与规则处理。如果某个程序始终不出现于预期记录中，应先检查它的网络权限、代理设置和独立解析，而不是持续增加 DNS 劫持条目。

遇到“开启 TUN 后断网”，依次检查内核是否启动、服务是否可用、接口是否建立、默认路由是否合理、DNS 是否返回结果，再检查代理出口。对照关闭 TUN 的状态可以缩小范围。不要同时更换节点、DNS、网络栈和规则源，否则即使恢复，也无法判断是哪一项改变起作用。

域名嗅探

域名嗅探尝试从连接初期的协议内容中提取主机名，为只有目标地址的连接补充域名信息。它常用于改善域名规则匹配，但不是解密工具，也不是所有连接都能恢复域名。启用之前应先判断缺少的是域名信息、规则内容还是接管路径，避免把不相关的连接故障都归到嗅探开关。

明确能够观察到的信息边界

普通 HTTP 请求可能包含主机字段，TLS 握手在部分情况下能提供服务器名称，QUIC 也有对应的识别方式。可见信息受协议、实现与加密机制影响；使用加密客户端问候等机制时，原本可供识别的名称可能不再直接可用。不能据此承诺对所有 HTTPS 连接都恢复正确域名。

嗅探得到的名称也不一定是应用最终访问的全部业务身份。一个应用可能连接多个服务域名，内容分发平台可能共享地址，连接复用还可能让后续请求不再重复握手。应按具体连接检查，不能用一次嗅探成功来证明该应用之后的所有流量都会进入相同的业务策略组。

下面示例仅在明确的 HTTP 与 TLS 端口范围尝试识别，并保留原目标，不强制改写目的地址。它适合先观察识别是否改善规则判断，再决定是否扩大范围。不同客户端的界面选项与生成配置可能存在差异，保存后应查看运行时配置，而不是假设界面勾选等同于某段完整 YAML。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
      override-destination: false

把识别域名与改写目标分开测试

override-destination 涉及是否使用识别到的域名替代连接目标，影响不仅是显示名称，还可能改变后续解析与实际连接方式。某些服务对原地址、访问地域或专用入口有要求，直接替换目标可能破坏原本正常的行为。应先使用保守设置验证，再针对确有需要的范围调整。

如果应用本来已经通过代理协议传递域名，或者 Fake-IP 映射能够提供域名信息，嗅探未必带来明显收益。为每种协议开启更宽端口范围可能增加处理工作，也会使故障链路更复杂。对于域名信息已经完整的环境，保持有限范围比追求所有协议全部启用更容易维护。

遇到特定站点开启嗅探后失败，应先对该站点建立可重复测试：使用相同出口、同一规则和新连接，比较开启与关闭时的目标、命中规则及错误类型。确认差异来自嗅探之后，再考虑用 skip-domain 缩小例外。不要把整个公共后缀加入跳过范围来掩盖一个局部兼容问题。

与 DNS、规则和日志共同定位

如果连接记录只有地址，先确认是否属于预期协议和端口，再看应用是否复用了旧连接。嗅探通常依赖连接建立初期的信息，中途开启后，不一定能从已经存在的连接恢复名称。关闭目标连接并重新发起请求，比反复切换开关更有助于建立明确的观察条件。

当显示了域名却仍走错出口，应回到规则顺序检查，而不是继续扩大嗅探范围。域名恢复解决的是信息缺失，不能让不存在的规则自动出现。若域名规则已命中而业务仍失败，则进一步检查所选节点、DNS 和目标连通性；把“识别成功”与“连接成功”作为两个独立结果记录。

QUIC 使用 UDP，排查时还要确认出口和接管链路支持相关流量。应用可能在失败后回退其他协议，造成一次能开、一次不能开的表象。不要为了证明嗅探生效而全局禁止某种协议；应先收集连接证据，再决定是需要协议级策略、应用设置调整，还是仅对特定服务保留例外。

日志级别应按诊断需要临时提高，复现后恢复正常水平。日志和连接信息可能包含访问域名、进程路径与业务地址，共享截图前先移除不必要的信息。记录配置差异时保留字段和错误类型即可，不必附上完整订阅、节点认证信息或与问题无关的访问记录。

本地覆写与多订阅合并

订阅负责提供远程内容，本地覆写负责保留设备与个人使用需求。直接编辑远程订阅文件，下一次更新可能重新写入原内容；直接编辑运行时配置，也可能在客户端重新生成时丢失。长期维护应先区分源订阅、覆写输入与运行时结果，明确每个修改由哪一层负责保存。

先核对覆写入口与应用范围

Clash Verge Rev 中应通过订阅关联的扩展或全局扩展入口管理本地调整，界面名称以实际客户端为准。全局覆写适合设备级公共设置，订阅级覆写适合仅对某个来源生效的业务例外。两层同时修改同一字段时，需要检查实际执行顺序，不能只凭编辑器里最后一次保存的位置判断最终结果。

Merge 覆写使用的是客户端约定，不能把所有扩展字段都当成 Mihomo 原生配置。下面的 prepend-rules 表示在对应 Merge 机制中前置规则，处理后应在最终 rules 中看到结果。若把它直接放入普通内核配置，它不会自动获得同样的合并语义。

# 放入支持这些字段的 Merge 覆写入口
prepend-rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

dns:
  ipv6: false

示例只增加一条业务规则并调整已有 DNS 映射中的字段，没有定义完整解析方案。保存后查看运行时配置，确认其他 DNS 上游没有意外丢失，并确认前置规则位于预期位置。若客户端的合并行为与预期不同，应先缩小到单个字段测试，而不是继续向同一覆写添加更多设置。

列表与映射需要不同的合并判断

YAML 映射可以按键理解，列表却涉及顺序、重复和整体替换。规则列表的前置与后置直接影响首次命中结果；策略组列表如果被整体替换，可能让远程规则引用的组名消失。不同扩展机制对列表的处理并不完全一致，所以“合并成功”必须由最终配置与内核载入结果共同确认。

扩展脚本适合需要重命名、去重、筛选与结构转换的情况，但复杂度也更高。先明确输入对象与返回对象的约定，并保留未修改字段。若只需要一条固定规则或一个布尔设置，优先选择可直接审阅的 Merge 片段，不必引入脚本。脚本能执行不代表输出结构符合内核要求。

订阅更新后应检查自定义组是否仍能引用成员。提供者可能改名、删除节点或调整组结构，依赖具体节点名的本地覆写会因此失效。更稳妥的设计是让业务规则引用稳定的本地组，再在组内部管理来源变化，但仍需防止空组与名称冲突，不存在一次配置永久适配所有来源的方案。

多订阅不是简单拼接多个文件

客户端列表中存在多个订阅，不表示它们默认同时进入一份运行配置。常见用法是选中其中一个作为当前配置；若需要同时使用多个来源，可研究节点提供者或明确的聚合机制。应先确定客户端是否支持这种输入，再考虑合并，不能把两份完整 YAML 直接粘贴在一起就期望自动协调。

多源合并至少要处理节点重名、策略组重名、规则优先级与全局字段冲突。两个来源都定义了 DNS、监听端口和兜底规则时，只能有明确的最终决定。实践中宜保留一份主结构，让其他来源仅贡献节点集合，并通过不同提供者名称引用，这比混合两套完整业务规则更容易审阅。

迁移旧客户端时，先导入订阅确认基础连接，再搬迁端口、规则和 DNS，最后处理脚本逻辑。旧 Parsers 的字段与执行环境不能直接等同于 Merge。可结合Clash for Windows 迁移方案逐项核对，不要把失效的历史配置整体覆盖到新客户端。

每次修改保存一份本地差异记录，至少写明目的、作用范围和撤销方法。出现问题时先停用新增覆写，再载入原订阅验证，确认恢复后逐条启用。备份文件应保存在受控位置，订阅地址和认证信息不应进入公开仓库；共享示例只保留与结构有关的字段。

外部控制面板

外部控制面板通过 Mihomo 控制接口读取状态、切换策略并执行部分管理操作。它与混合代理端口不同，也不是让应用上网的入口。配置时应把数据代理和管理访问分开考虑：应用连接代理端口，面板连接控制接口。把两种地址互填，通常只会得到连接错误或无法解析的响应。

优先使用本机接口与明确认证

external-controller 定义监听地址，绑定 127.0.0.1 表示仅接受本机 IPv4 回环访问。secret 用于接口认证，应设置足够强且独立的实际值。下面的密码只是教学示例，不能作为部署值；客户端可能已经代为管理这些字段，覆盖前先确认内置界面是否依赖当前接口。

external-controller: 127.0.0.1:9090
secret: "your-password"

不要为了解决面板连接失败，直接把监听地址改成所有接口并移除认证。这样会把策略切换和运行状态暴露到更大的网络范围。确有跨设备管理需要时，应先建立受控的访问通道，结合防火墙限定来源；普通桌面用户优先保留本机管理，不需要为日常代理使用开放远程控制。

控制接口地址通常由协议、主机和端口组成，面板中的认证字段应与内核当前值一致。端口被其他程序占用、内核未运行、客户端重启后更新了认证值，都可能造成面板断连。排查时先检查内核启动日志与监听状态，再检查面板保存的旧设置，避免把管理连接失败误认为代理线路失效。

区分面板文件、接口与浏览器限制

external-ui 指向本地面板静态文件目录，而不是任意网页地址。目录中需要包含实际入口与资源文件，并且内核有读取权限。只填写一个目录名不会自动生成面板。若使用客户端自带界面已经能够完成管理，可以不额外配置静态面板，减少文件更新和接口暴露的维护工作。

使用独立浏览器面板时，还可能遇到跨源访问、混合内容或浏览器对本地网络的访问限制。HTTPS 页面请求本地 HTTP 接口不一定会被允许，这与密码是否正确是两类问题。应先看浏览器错误属于网络拒绝、跨源拦截还是认证失败，不要通过全面放宽来源限制来碰运气。

面板来源也属于信任边界。能够读取管理凭据的页面可能对接口发起操作，不应向不明页面输入控制密码。需要跨源授权时，按所用内核支持的配置限定准确来源，并检查浏览器实际使用的协议和端口。来源匹配错误应修正具体值，而不是把所有站点一并授权。

把临时控制与持久配置分开

面板改变的是当前运行状态，其中部分设置可能被客户端持久化，也可能在重新载入配置后恢复。需要长期保留的 DNS、规则和接管设置，应回到客户端配置或覆写入口管理。不要把面板中的临时修改当作源文件已经改变，尤其在重启、切换订阅和自动更新之后，应再次检查结果。

共享截图或导出连接记录时，注意域名、进程路径、设备地址和接口认证信息。故障报告通常只需错误类型、相关字段与复现步骤。可以保留结构、删除具体业务内容；不要发送完整订阅文件来证明某条规则没有命中，也不要把控制接口开放给他人作为常规协助方式。

客户端选型与内核配置需要分开判断。跨平台选择可先从 Clash Plus 查看，再按桌面覆写需求比较 Clash Verge Rev 等客户端；各客户端界面和扩展机制不完全相同，不能假设同一操作位置通用。安装与平台信息统一见下载中心，已有配置则按当前内核支持情况逐项迁移。

完整排错链路应能回答四个问题：流量是否进入内核，域名如何获得，规则为何命中，最终出口是什么。控制面板提供观察窗口，不替代这条推理顺序。回到稳定配置后，恢复日常日志级别，关闭临时开放的管理入口，并保留经过验证的覆写差异，便于下一次更新时复查。