配置进阶 · MIHOMO

Clash 配置进阶手册

从策略选择到流量接管，按配置层次检查生效结果。

先确认基础连接可用，再调整规则、DNS 和网络接管方式。入门指南负责导入订阅、选择节点与验证连接的快速上手主线；本页用于查阅参数关系、管理长期配置，以及定位修改后的异常。首次使用可先选择 Clash Plus，其他客户端与系统架构选项见客户端下载页。

下文以 mihomo 配置语义为主。客户端界面、内核能力与配置生成流程可能不同，不能把界面名称直接当成 YAML 字段。所有片段均注明演示范围，未提供真实代理节点，不是完整可联网配置。修改前导出当前配置，记录内核类型、接管模式和复现网址；每次只改变一层，避免把几个问题叠在一起。

策略组类型与实战

策略组解决的是“匹配规则以后使用哪个出口”，不是“哪些请求应该代理”。规则把连接交给一个组，组再根据手动选择、健康检查或分配算法决定下一跳。排查时先在连接详情里找命中的规则，再看最终选择的节点；如果请求根本没有进入目标组，继续调整测速间隔没有意义。组名也是配置引用标识，修改名称后必须同时检查规则、嵌套组及客户端保存的选择状态。

按业务目标选择组类型

select适合需要明确控制出口的场景，组中可以放节点，也可以放其他策略组。url-test通过探测结果选择表现较好的候选，但探测只代表访问指定测试地址的情况，不等于所有业务都更快。fallback优先使用列表中靠前且通过检查的候选，适合出口优先级固定的环境。load-balance把不同连接分配给候选，不会把一个下载连接拆开叠加带宽。

类型决策依据主要边界
select用户明确选择所选出口失效时通常需要干预
url-test候选的探测结果测试地址和实际业务可能不一致
fallback列表顺序与可用性优先级比最低探测耗时更重要
load-balance连接分配策略业务可能观察到多个出口地址

先建立可追踪的手动选择层

建议先保留一个顶层手动组，把自动选择组放在其中，而不是让每条业务规则直接引用自动组。这样遇到异常时可以临时固定出口，区分“自动切换造成变化”与“规则写错”。下面只演示引用关系，两个候选都是内置策略，不代表可用代理节点；实际使用时应把候选替换成已导入且能连接的节点或组，并核对名称完全一致。

mode: rule

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - DIRECT
      - 故障阻断
  - name: 故障阻断
    type: select
    proxies:
      - REJECT

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

自动组的关键参数包括测试地址url、检查间隔interval和切换容差tolerance。地址应能稳定响应，且符合当前网络的访问条件；间隔过短会增加探测请求，过长则可能让失效状态停留更久。容差用于减少候选表现接近时的频繁切换，单位与具体字段语义应以所用内核文档为准。不要把健康检查失败直接解释成节点完全离线，测试域名解析、目标站限制和代理链路都可能导致失败。

验证切换是否影响真实连接

切组后应新建一次请求再观察。浏览器连接池、HTTP/2 长连接与持续下载可能继续使用旧连接，因此出口没有马上变化并不必然是切换失效。先关闭测试页面，再建立新连接，核对连接详情里的完整策略链。需要中断旧连接时使用客户端提供的连接管理功能，避免为了刷新状态直接重启整个系统，丢掉有用日志。

登录、支付及长期会话往往更适合固定出口。负载均衡可能让同一服务的不同连接使用不同地址，引起会话校验或地区判断变化；这类业务可单独分到手动组。组间嵌套还必须避免循环引用，例如甲组引用乙组、乙组又引用甲组。配置能否加载只是第一步，仍应检查最终出口、失败时的回退行为和恢复后的优先级。更细的参数对比可阅读自动策略组类型与写法笔记。

规则集订阅化管理

规则集的价值是把频繁变化的匹配内容与相对稳定的出口策略分开维护。主配置只保留规则集声明、引用顺序和最终兜底，域名或网段列表独立保存。这样更新业务域名时不用改动整个策略结构，也更容易审查差异。不过，外部规则集仍是配置输入，应确认来源、格式与更新范围；不能因为能够下载就直接让它覆盖本地规则优先级。

先区分声明、内容与引用

rule-providers负责声明来源和解析方式，RULE-SET负责在规则列表中调用它，实际文件负责提供匹配条目。behavior决定按域名、IP 段还是经典规则语法解释内容；format决定文件编码格式。两者不能混为一谈，例如 YAML 文件既可以装域名列表，也可以装经典规则。文件扩展名不是内核判断内容正确性的充分依据。

下面用本地文件建立最小验证链，避免同时引入网络下载问题。把规则文件放在内核工作目录对应位置，再把声明合入已有配置。路径通常相对内核工作目录，不一定相对正在编辑的文件；图形客户端可能使用独立配置目录，应从日志或配置管理页面确认。沙箱与服务运行方式还可能限制可访问路径。

rule-providers:
  本地域名:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,本地域名,DIRECT
  - MATCH,出口选择

对应的rules/local-domains.yaml内容如下。这里使用保留示例域名，目的只是验证文件是否被加载以及规则是否命中；它不会替代业务规则，也不会添加代理节点。

payload:
  - 'example.org'
  - '+.example.net'

规则顺序决定覆盖范围

规则通常自上而下匹配，先命中的条目决定后续处理。精确例外放在广泛分类之前，兜底MATCH放在最后。若把大范围直连集合放到业务代理集合之前，后者可能永远没有机会命中。规则集之间存在重叠很常见，维护重点不是让所有集合互不相交，而是能解释某个目标为什么被前面的规则截获。

域名规则依赖连接上可获得的域名信息，IP 规则则可能触发解析。对于支持该参数的 IP 匹配规则，no-resolve表示不要仅为匹配这条规则主动解析域名，并不表示整个连接从此不会进行 DNS 查询。是否使用它应看规则目的：内网网段例外通常不值得额外解析，而明确依赖目标 IP 地理属性的策略则要考虑解析结果来源。

切换为type: http时，需要补上规则集地址，并明确更新间隔和缓存路径。先在当前可用网络下确认来源能够访问，再决定更新请求的出口；否则容易出现“必须先有规则才能访问规则源”的循环依赖。更新失败时可能继续使用缓存，首次启动却没有缓存可用，因此要分别测试已有缓存和空缓存两种启动条件，不要只看一次更新成功提示。

建立更新失败的检查顺序

先查日志中是下载失败、文件读取失败还是格式解析失败。下载失败检查来源解析、TLS 连接与出口；读取失败检查目录权限和路径；解析失败则检查payload结构、缩进及行为类型。经典规则集中的条目一般不附带最终策略，因为策略由外层RULE-SET指定；把完整主规则直接搬进去，可能造成字段数量错误或语义混乱。

更新后选择一个明确包含的域名与一个明确不包含的域名，新建连接核对命中结果，再检查是否有靠前的规则抢先匹配。客户端连接面板显示的规则名称比“网页能打开”更有判断价值：能打开也可能只是落到了兜底。保留上一份可用规则文件和来源说明，出现误分类时先加入窄范围本地例外，再调查上游变更，不要立刻把整个规则系统改成全局代理。

DNS 配置优化

DNS 排查先分清两个问题：应用向谁查询域名，以及内核向谁查询最终地址。应用可能使用系统 DNS、浏览器加密 DNS或自身解析器；代理节点的服务器域名也需要先被解析。只修改nameserver，不代表所有应用的查询都会经过内核。建议先观察故障是否仅出现在某个应用，再检查查询入口、解析上游与连接出口，避免看到解析报错就同时替换所有地址。

把解析链拆成可检查的环节

default-nameserver主要用于解析 DNS 上游自身的域名，承担引导作用；nameserver是常规解析上游；nameserver-policy可对特定域名指定解析路径。节点服务器域名若需要独立处理，可检查所用内核的proxy-server-nameserver支持情况。不要让节点解析依赖一个尚未建立的代理出口，也不要让加密 DNS 的服务器域名只能通过它自己解析。

下面是在本机回环地址开放测试端口的片段，采用真实 IP 形式的上游，便于先验证链路。它不会自动更改操作系统解析设置，也不会自动开启 DNS 劫持。示例启用redir-host以观察真实地址返回，若现有客户端已管理 DNS，应先检查最终配置，避免重复监听端口。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver-policy:
    'example.org':
      - 223.5.5.5

若系统安装了dig，可以直接查询该监听端口，再与系统默认解析结果比较。这里验证的是内核 DNS 服务入口是否可用，不证明浏览器已经使用它。查询超时先检查服务监听、端口占用与上游可达性；能返回地址但网页失败，则继续查连接规则、TLS 握手与应用代理设置。

dig @127.0.0.1 -p 1053 example.org A
dig @127.0.0.1 -p 1053 example.org AAAA

上游选择与分域名策略

多个上游的执行与结果采用方式由内核实现及字段决定，不应把列表简单理解为主备顺序。选择上游时要看当前网络能否稳定到达、是否适合内网域名，以及返回地址与实际出口是否相容。公司内部域名通常应交给公司解析器，公共解析器不了解内部区域；把内部域名发送出去既可能查询失败，也会扩大域名信息暴露范围。

DoH 或 DoT 可以保护查询传输，但不会自动修复错误的出口或路由，也不会让目标业务绕过分流规则。开启基于规则的 DNS 路由能力前，应理解respect-rules与节点域名解析的依赖关系，并为节点解析建立明确路径。旧配置中的fallback与过滤条件也需要一起审查，不能只粘贴一段上游列表后假设解析选择已改变。

IPv6 应按实际网络能力决定，而不是固定关闭或开启。只有地址可解析、系统存在可用路由、客户端接管方式支持相关流量时，IPv6 才能形成完整链路。若网页偶尔卡住，可分别测试 A 与 AAAA 查询、IPv4 与 IPv6 连接，查看是否一类地址持续失败。仅在 DNS 段关闭 AAAA 返回，也不能保证应用不会利用缓存或独立解析获得 IPv6 地址。

缓存、浏览器解析与故障复测

修改解析策略后，旧结果可能留在内核、操作系统和浏览器三处缓存中。先通过显式查询确认新结果，再按客户端提供的方法清理 DNS 缓存，重启测试应用并建立新连接。不要只反复刷新同一页面；连接池可能根本没有触发新的 DNS 请求。遇到浏览器独有问题时，检查安全 DNS设置和扩展影响，并记录关闭相关功能前后的差异。

测试时保留查询域名、记录类型、返回地址、耗时或超时现象，以及对应连接日志。NXDOMAIN、空结果与请求超时不是同一种故障：前者是不存在的响应，空结果可能只是该记录类型没有数据，超时则通常说明链路或上游响应存在问题。更多应用侧检查见常见问题；只有明确定位解析环节后，才需要继续调整 Fake-IP 或 DNS 接管方式。

TUN 与 Fake-IP

TUN 与 Fake-IP 分别处理流量入口和域名映射，二者常一起使用，但不是同一个开关。TUN 通过虚拟网络接口接收流量，适合接管不主动遵循系统代理的应用；Fake-IP 先返回虚拟地址，再由内核根据映射还原域名并执行连接。系统代理通常由应用主动遵循，TUN 则涉及系统路由、权限和网络栈。是否需要开启，应由未被接管的具体应用决定。

先确认谁在接管流量

同一设备同时运行多个 VPN、加速器、虚拟网卡工具时，路由和 DNS 可能相互覆盖。先记录系统代理状态、已有虚拟接口和默认路由，再只保留一个接管入口做对照。桌面客户端可能通过服务进程获得权限，也可能要求授权；移动系统则通常使用系统提供的 VPN 通道。不同平台的界面不能直接对应到完全相同的底层路由行为。

以下片段只演示 mihomo 中 TUN、DNS 接管与 Fake-IP 的组合，不包含代理节点。客户端可能已经自动生成其中部分字段，应以最终配置为准。开启前确保能从本地界面关闭 TUN，并保留不依赖网络的原配置副本。

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'
  nameserver:
    - 223.5.5.5

auto-route用于建立接管路由，auto-detect-interface帮助选择实际出口接口，stack影响流量处理实现。系统、gVisor 与混合栈的可用性和兼容性取决于平台及内核构建，不应为了追求某个名称直接更换。先用客户端建议的默认值验证基本连通，再对出现问题的协议做单项对照，记录改动前后的日志。

理解虚拟地址的使用边界

Fake-IP 地址不是目标服务器的真实地址，不能直接拿它做公网可达性判断。应用获得虚拟地址后，后续连接需要再次经过持有映射的内核；若应用绕过 TUN 直连、映射丢失或流量进入另一套代理实例，就可能无法还原目标域名。缓存中残留虚拟地址时，关闭接管后仍可能短暂失败，应清理相关缓存并让应用重新解析。

fake-ip-filter列出的域名通常改为返回真实解析结果，但这不等于自动直连，最终出口仍由规则决定。局域网发现、依赖真实地址校验的应用或特定设备通信，可考虑窄范围排除，再验证是否确实解决问题。不要把所有域名都加入过滤列表来掩盖接管异常，那会改变整个解析模型，也让排障失去对照条件。

示例中的 DNS 接管针对传统目标端口为 53 的请求，不会直接解密应用自己的 DoH 或 DoT。浏览器内置解析、企业 VPN 内部解析及特殊网络接口仍需要分别检查。局域网广播、组播和某些本机服务也不是普通公网连接，不能仅凭一个 TUN 开关就假定全部正确转发。访问路由器或打印机失败时，先检查内网路由与解析，而不是盲目更换代理节点。

按最小影响顺序回滚

出现整机断网时，先关闭 TUN，确认默认路由与系统 DNS 是否恢复，再恢复原配置。若客户端异常退出后路由未恢复，使用客户端的修复功能或重新启停网络接口；不熟悉系统路由命令时，不要照抄批量删除路由的操作。恢复基础网络之后，分别验证系统代理与 TUN，避免在网络已经失控时继续叠加规则。

稳定后用浏览器、命令行与一个原本不遵循系统代理的应用分别测试，核对连接是否进入内核、是否带有域名、规则是否命中。对 UDP 业务还要验证节点协议和服务端是否支持所需传输，TUN 接收到流量并不代表出口支持它。完整机制对照可参考TUN 与系统代理的工作机制，先区分入口覆盖与出口能力，再决定下一项修改。

域名嗅探

域名嗅探用于补充连接上的域名信息，不是解密网页内容的工具。当应用通过独立 DNS、缓存地址或直接 IP 建立连接时，内核可能只看到目标地址，无法使用预期的域名规则。嗅探可以尝试从 HTTP 请求或 TLS、QUIC 握手中提取可见主机信息，再参与后续判断。它只能利用协议中实际暴露的信息，遇到加密客户端问候、非标准协议或纯 IP 服务时不能保证得到域名。

先证明缺失的是域名

在连接面板中找一条可以稳定复现的请求，确认目标只显示 IP，且域名规则没有命中。若面板已经显示正确域名，却仍落到错误规则，优先检查规则顺序和策略引用，开启嗅探通常不会解决。若浏览器采用独立加密 DNS，先了解这条路径是否符合预期，再判断是调整浏览器解析方式，还是让内核通过嗅探补充信息。

下面采用保守端口范围，只演示 HTTP 与 TLS 嗅探。override-destination设为关闭，用来降低把嗅探结果直接用于改写连接目标的影响；具体规则可用信息和行为仍需结合所用内核检查。片段应合入现有配置，不是独立连接配置。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080
    TLS:
      ports:
        - 443
  skip-domain:
    - '+.lan'
    - '+.local'

parse-pure-ip允许尝试处理纯 IP 连接，force-dns-mapping关系到特定 DNS 映射场景中的嗅探行为，它们都不是“所有连接一定得到域名”的保证。端口范围决定尝试覆盖哪些连接，不代表该端口上的流量必然属于对应协议。应用在非常规端口使用 TLS 时，是否扩大范围应根据实际业务判断，避免为了覆盖一个问题把全部端口都纳入检查。

区分规则信息与目标覆盖

嗅探得到域名后，可以帮助恢复业务分类；目标覆盖则可能进一步改变原本准备连接的目标语义。某些服务依赖固定 IP、定制 Host 或特殊反向代理，盲目开启覆盖可能让原本有效的请求失败。排查应把“有没有嗅探出域名”和“是否允许覆盖目标”拆成两个实验，先看日志与命中变化，再测试业务握手是否保持正常。

一个 IP 可能承载许多域名，仅靠地址反查无法准确推断本次请求的主机。TLS 中可见的服务器名称也不一定能代表应用所有后续资源，网页可能还连接内容分发、登录、图片及接口域名。因此不能看到首页命中正确就认定整站都走了同一策略，应在连接列表中按应用或时间范围检查关联请求，特别是登录跳转与资源加载失败的场景。

QUIC 通常使用 UDP，若要启用相应嗅探，还需确认内核支持、实际端口和出口 UDP 能力。关闭浏览器 QUIC 后现象变化，只说明协议路径不同，不直接证明 UDP 节点一定不可用。TLS 握手中信息不可见时，嗅探也不会凭空恢复域名。此时更合理的办法可能是让应用 DNS 进入内核、使用已知业务规则，或在必要时按进程分流，而不是无限扩大嗅探范围。

设置排除项并保留复测记录

内网服务、设备管理页面和少数兼容性敏感应用，可以建立明确排除项。排除应尽量具体，先针对一个可复现域名或目标测试，再评估是否扩大。不同内核支持的跳过域名、源地址和目标地址字段可能不同，配置检查出现未知字段时不要继续堆参数；先核对内核身份和支持范围，再决定保留哪些选项。

验证时先停用嗅探访问一次，记录目标域名、规则和出口；再启用嗅探，新建连接比较这三项。若仅在开启后失败，回退后仍需确认应用缓存与旧连接已经清理，避免把残留状态误认为回退无效。日志中若含内部主机名、请求地址或应用身份，分享前应脱敏。嗅探适合作为信息补足层，长期稳定配置仍应优先依靠清楚的 DNS 路径和可解释的规则。

本地覆写与多订阅合并

长期配置应把远程输入与本地意图分开：订阅负责节点和可更新内容，本地覆写负责固定规则、DNS、策略组结构及设备专属设置。直接编辑客户端生成的临时配置，通常会在订阅更新或切换配置时丢失。先确认客户端提供的是持久覆写入口、合并配置还是脚本处理，再观察最终生成文件；只看编辑器里的原文，无法证明运行中的内核已经采用修改。

弄清合并顺序与数组行为

YAML 只是数据格式，本身没有统一的跨文件合并规则。客户端可能对映射递归合并，对数组整体替换，也可能提供前置、后置或按名称更新能力。rules被整体替换和被追加，结果差别很大：前者可能丢掉订阅规则，后者则可能把本地例外放到MATCH之后。应用覆写前先用一条窄范围测试规则检查实际顺序。

下面演示一份本地配置意图，其中策略组只有直连候选，作用是展示稳定名称与规则位置。它不是所有客户端通用的覆写格式；应在客户端说明的合并入口中转换或应用，不能把这段单独当作完整代理订阅导入。

proxy-groups:
  - name: 日常出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,日常出口

实际合并时，应让“日常出口”引用已有节点、节点提供者或下层自动组。主规则只依赖这个稳定入口，节点供应变化时不必重写业务规则。若订阅自己也定义了同名策略组，要明确谁覆盖谁；重复名称不是可靠的合并方案。客户端缓存的旧选择还可能指向已经删除的节点，更新后需要检查组当前值是否有效。

多订阅先隔离来源再组合

多订阅可以通过客户端合并功能，也可以通过proxy-providers等内核机制组织，但节点订阅、完整配置订阅与规则集不是同一种输入。一个节点提供者通常需要符合对应的节点集合结构，不能把包含 DNS、规则与控制器的完整配置地址直接塞进去，再期待所有内容自动合并。先确认订阅返回的内容类型，必要时使用可信且可审查的本地转换流程。

为不同来源使用独立名称、独立缓存路径和可辨认的节点命名。两个来源都叫“香港”的节点，在日志和选择记录中难以区分，也可能触发名称冲突。前缀应表达来源或用途，不要把订阅凭据放进节点名。过滤候选时，先观察过滤结果是否为空；正则表达式、名称变化和地区标签调整都可能让原本正常的组突然没有成员。

远程订阅地址常带访问凭据，应保存在客户端本地配置管理中。截图、问题反馈、同步仓库和在线转换工具都可能扩大其暴露范围。分享配置前同时检查 URL 查询参数、节点密码、控制器密钥及日志中的完整地址；只隐藏节点列表，仍可能泄漏订阅入口。备份包含这些内容时，应选择受控位置，并限制可读取的账户。

把生成、检查、重载分开验证

修改后先查看最终配置，确认规则排列、组成员和 DNS 字段，再执行内核配置检查。命令行环境可使用下方检查方式，其中config.yaml应是待运行的最终文件；图形客户端优先使用内置检查功能，避免在不同工作目录下得到不一致的文件路径结果。检查通过意味着结构和引用基本可接受，不等于代理节点能够访问目标业务。

mihomo -t -f config.yaml

重载后分别测试本地例外、常规代理与最终兜底，并检查订阅再次更新后这些设置是否仍存在。若更新后回到旧行为，说明覆写没有进入持久生成链，或执行顺序被后续层覆盖。回滚时恢复本地覆写与对应订阅快照，不要仅复制一份临时生成文件作为永久方案。复杂合并故障应先减到单订阅、单顶层组，再逐个恢复来源，直到找到造成差异的那一层。

外部控制面板

外部控制面板通过内核控制接口读取状态、切换策略和管理连接，本身不负责转发业务流量。面板打不开与代理不能联网可能是两个独立问题，应先确认内核仍在运行，再检查控制接口、认证和页面来源。多数日常操作可以直接使用客户端内置界面；只有确实需要独立观察或远程管理时，才需要额外开放控制能力，避免无意扩大设备的管理入口。

先限制到本机访问

external-controller指定控制接口监听地址，secret用于接口认证，external-ui指定本地静态面板目录。下面只展示本机管理配置。示例密钥是教学用假值，实际部署必须替换为本机生成的高强度随机值，并避免写入公开文件。静态面板文件需要事先准备在受信任的本地目录，配置该字段不会凭空生成页面。

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

回环监听仅供本机使用，不能因为另一台设备连接不上就直接改为所有接口并关闭认证。若确需跨设备管理，应先设计认证、访问控制和安全传输方式，再限制允许访问的来源。系统防火墙、容器端口映射与客户端设置可能共同影响实际暴露范围，检查时应以监听状态和实测访问为准，而不是只看配置文本。

区分代理端口与管理端口

mixed-port等代理入口用于接收应用流量，控制接口用于管理内核，二者不能互换。浏览器把代理服务器设置为控制端口，不会形成正常代理连接；面板把 API 地址填成代理端口，也无法读取策略组。面板中的 API 地址应包含正确协议、主机和端口，密钥应与当前运行实例一致，尤其要警惕设备上有多个内核进程的情况。

可以先通过本机 API 检查接口是否有响应。以下命令使用与示例相同的假密钥，只用于本地演示；实际操作时要注意终端历史和屏幕共享，不要公开认证头。请求返回未授权说明接口已响应但认证不匹配，连接被拒绝通常说明地址、端口或进程状态有问题，超时则还需检查访问路径和防火墙。

curl --fail --silent --show-error \
  -H 'Authorization: Bearer your-controller-secret' \
  http://127.0.0.1:9090/proxies

API 正常而页面空白时，再检查静态文件是否完整、目录路径是否正确，以及浏览器控制台中的请求错误。使用安全页面访问明文 API 可能触发混合内容限制，页面与 API 来源不同还可能涉及跨域策略。不要为了消除浏览器报错就允许任意来源或移除认证；优先让本地面板与受控 API 使用匹配的访问方式。

用面板形成完整排障记录

连接页面应同时查看目标、规则、策略链与连接状态。只看最终节点名称，无法判断它是被业务规则选择，还是偶然落到兜底。切换策略后新建连接，必要时在确认影响范围后关闭指定旧连接；不要一次清空所有连接再观察，因为登录会话、下载任务和远程终端都可能被中断，也会丢失故障现场。

日志级别以能够解释问题为准，临时提高详细程度后应在复测结束时恢复。详细日志可能包含内部域名、目的地址、进程信息和请求路径，提交反馈前只保留与故障有关的时间段并脱敏。面板显示的数据来自所连接的实例；如果客户端运行正常而面板规则列表明显不同，先核对控制地址和进程，不要立即认定订阅没有更新。

最终应把排查记录收敛为一条可复现链：哪个应用发起请求，是否进入内核，域名如何获得，命中哪条规则，策略组选了什么出口，失败发生在解析、连接还是业务响应阶段。浏览器和终端表现不同，可继续阅读系统代理与终端排查清单。若只是首次配置尚未完成，返回入门指南走完主线，比继续增加高级选项更容易得到可靠结论。