Clash 配置进阶手册：策略组、DNS 与 TUN 配置参考

策略选择 / proxy-groups

策略组类型与实际出口

策略组决定流量命中规则之后交给谁处理。规则中的 Proxy 只是一个名称，不代表内核自带代理出口；它必须对应节点或策略组。一个连接可以先命中业务规则，再进入手动选择组，最后落到自动测试组中的某个节点。理解这条引用链，比同时创建很多分组更重要。修改之前，先列出订阅提供的节点名称、现有组名和规则引用，避免同名或悬空引用导致配置加载失败。

手动选择、自动测速与故障转移

select 提供手动选择入口，适合保留明确的出口控制权。url-test 按指定测试地址的探测结果选择候选项，适合日常自动选择；它测量的是特定网络路径，不等于所有网站的访问速度。fallback 按配置顺序使用可用候选项，主要目标是保留优先级并在故障时切换，而不是挑选延迟最低者。三者可以嵌套，但应保持层次简单，不能让两个组相互引用。

load-balance 把不同连接分配给候选节点，不能把单个下载连接的带宽相加。涉及账户会话、出口地区或服务端风控的业务，通常更适合固定出口。负载均衡的具体分配还受 strategy 影响，例如 consistent-hashing 会尽量让同一目标保持相近的出口映射，但候选变化仍可能改变结果。不要把它理解为身份或公网地址长期不变的保证。

config.yaml · 引用已有 provider 的策略组片段

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 自动选择
      - 故障转移
      - DIRECT

  - name: 自动选择
    type: url-test
    use:
      - 订阅源
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 故障转移
    type: fallback
    use:
      - 订阅源
    url: https://www.gstatic.com/generate_204
    interval: 300

节点来源、探测与选择状态

上例要求已有名为“订阅源”的 proxy-providers。use 引入提供器中的节点，proxies 则引用明确的节点名、策略组名或内置策略。订阅增删节点时，使用提供器能减少逐项维护，但仍需确认提供器文件加载成功。若客户端导入的是包含完整分组的订阅，不应直接再粘贴一个同名 proxy-groups 顶层字段；应通过覆写或编辑有效配置合并列表。

interval 是探测间隔，单位为秒；tolerance 是自动选择时允许的延迟差异，单位为毫秒，有助于减少小幅波动引起的频繁切换。测试地址应稳定、可达，并尽量符合实际业务路径。某节点测试成功只说明该探测请求完成，无法证明特定网站、UDP 或所有地区服务均可用。排查时要把测试连接与真实访问分开观察。

提供器的健康检查与策略组的测试属于不同配置位置。前者维护节点可用性信息，后者服务于组内选择逻辑；为了便于定位，初次调整时不要同时改变测试地址、间隔、筛选条件和组类型。先保留一个明确可用的候选出口，再验证自动组是否能引用到它。候选列表为空时，应先检查提供器和筛选表达式，而不是反复切换全局模式。

类型	主要用途	需要注意
`select`	手动固定策略	选中 DIRECT 就会直连
`url-test`	按探测表现自动选择	测试地址影响判断
`fallback`	按顺序故障转移	优先级来自候选顺序
`load-balance`	分散不同连接	不是单连接带宽叠加

确认规则与策略组的连接关系

修改后先查看连接详情中的匹配规则和策略链。如果规则命中了业务组，但最后走了 DIRECT，通常应检查组内选项，而不是改域名规则。若节点确实切换而页面表现不变，先关闭原有长连接再重试；已有 TCP 会话不会因为手动选组就自动迁移到另一出口。浏览器连接池、应用后台连接和缓存都可能使观察滞后，验证时应使用新连接。

实际配置建议保留一个总入口组，再按确有差异的业务拆分少量子组。只有当某类业务需要固定地区、不同传输能力或独立故障策略时，分组才有明确价值。对于节点选择、测试结果和地区判断的区别，可继续阅读代理节点怎么挑；遇到界面操作与内核结果不一致，可先在常见问题中核对代理模式与系统代理的区别。

规则管理 / rule-providers

规则集订阅化管理与匹配顺序

规则列表回答“这个连接应该进入哪个策略”。在 Rule 模式下，内核通常按 rules 自上而下检查，首个命中的规则决定后续策略，不会继续寻找更精确的另一条。因此，顺序属于配置语义：个人例外应放在大范围规则前，最终兜底放末尾。把所有条目排序得整齐，并不能保证逻辑正确；真正需要维护的是例外、业务分类和兜底之间的优先级。

把维护来源与本地策略分开

rule-providers 用于定义可复用规则集，RULE-SET 在主列表中引用它。规则集负责描述匹配对象，具体走哪个策略仍由引用行决定。这样可以让同一套域名集合在不同设备使用不同出口，不必改上游规则文件。对于体积较大、需要定期更新的列表，这也比把全部内容复制进订阅更容易审阅和回退。

先用本地文件完成闭环，再切到远程来源更容易排错。下面是一套可实际落地的本地规则集：主配置和规则文件都以 mihomo 工作目录为基准放置。实际工作目录由启动方式和客户端管理方式决定，不一定是下载文件夹。路径写错时，即使文件内容完全正确，内核也无法加载对应规则集。

config.yaml · 本地 classical 规则集

mode: rule
rule-providers:
  development:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/development.yaml

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - RULE-SET,development,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

rules/development.yaml

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

behavior 与 format 必须匹配内容

behavior: classical 接受带规则类型的条目，如示例中的 DOMAIN-SUFFIX；条目里不再填写 Proxy，因为策略已经写在 RULE-SET 引用处。domain 用于域名集合，ipcidr 用于地址段集合，内容语法不能与 classical 混用。format 描述载荷编码，例如 YAML 或纯文本；文件扩展名本身不能替代正确的格式声明。

转换为 HTTP 来源时，将 type 改为 http，增加实际可访问的 url 与以秒计的 interval，并为缓存设置独立 path。每个提供器应使用不同文件路径，避免内容互相覆盖。下载来的网页错误提示、访问验证页面或登录页面都不是规则文件；能在浏览器打开链接不代表内核拿到的响应就是预期载荷。

首次部署远程规则时，应确认冷启动也能取得文件。若获取规则的域名恰好依赖这份规则才能访问，就会形成启动依赖。更稳妥的做法是先确保下载通路可用，并保留经过验证的本地缓存。规则提供器下载失败与代理节点不可用是两类问题，应分别看更新日志和连接日志，不宜仅凭网站打不开来判断是哪一层出错。

用小范围请求验证分流

验证新规则时，先选一个确定属于目标集合的域名，建立新连接，在连接详情中读取命中规则、规则载荷和策略链。若命中了更靠前的 DIRECT 条目，应调整优先级；若未出现预期规则集，检查提供器名称、加载状态及文件内容。IP 类规则还依赖解析或目标地址信息，不能假设它们总能替代域名匹配。

对于局域网设备、打印机与本地服务，优先维护明确的直连范围，并确认不会被大范围代理集合提前截获。加入 REJECT 规则前，应评估目标域名是否被多个业务共用；误拒绝内容分发域名可能导致登录、图片或更新异常。排查阶段可以临时把可疑规则改为可观察的策略，并记录结果，避免直接删除整套规则后丢失问题线索。

规则集更新属于外部输入变更，应与订阅节点更新分开管理。更新后如果只有一类网站异常，可先回退该规则文件或暂停对应 RULE-SET，而不是同时重置 DNS 与 TUN。个人例外尽量保存在本地覆写层，注释写明原因和适用目标；上游列表更新时才能保留这些决定。内核与旧版规则能力的差异，参见mihomo 与原版 Clash 内核对照。

解析路径 / dns

DNS 配置优化与解析路径

DNS 配置要先明确三个问题：谁发起查询、查询通过什么出口到达解析器、结果用于哪个连接。系统 DNS、浏览器安全 DNS、应用内置解析和 mihomo DNS 可以同时存在。只修改 nameserver，不能保证所有应用查询都会进入内核；也不能仅凭网页能打开就证明解析符合预期。先画出实际查询路径，再调整字段，比同时填入多个解析器更有效。

启动解析与业务解析分开理解

default-nameserver 用于解析 DNS 服务器自身的域名，解决加密解析器启动时“先知道地址才能发起请求”的问题。nameserver 是常规域名查询使用的上游。proxy-server-nameserver 用于代理节点域名的解析，有助于把建立代理连接所需的基础解析与业务域名解析分开。三个字段服务于不同阶段，不是简单的第一、第二、第三备用顺序。

下面先展示不依赖代理出站的基础片段。它能帮助确认监听地址、上游解析与域名策略是否生效，但不构成所有网络下的隐私或可达性保证。解析器地址应根据实际网络和维护要求选择；某个公共解析器在一个网络可用，并不意味着在所有接入环境中都可用。

config.yaml · 基础 DNS 片段

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:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - https://dns.alidns.com/dns-query

按域名选择上游与按规则选择出口

nameserver-policy 按域名匹配选择上游解析器，示例中的 +.example.com 覆盖该域名及其子域名。它解决的是“问谁”，并不直接等于“网站连接走谁”。连接策略仍由代理模式、规则和策略组决定。企业内部域名通常需要组织内部 DNS，公共解析器可能根本没有对应记录；这类域名应先验证内部解析器在当前网络是否可达。

需要让 DNS 上游连接遵循路由规则时，可评估 respect-rules。启用前必须安排好代理节点域名解析，避免解析代理节点需要先走代理、建立代理又需要先解析节点的循环。不要仅复制一个“防泄漏”开关组合就认为完成配置；应分别验证节点解析、上游连接和普通域名查询，尤其关注第一次启动且缓存为空时的表现。

fallback 与 fallback-filter 有自己的响应筛选语义，不应当作简单的“第一台失败才问第二台”。多个上游也不是数量越多越可靠：它们可能返回不同地址，带来内容分发定位差异和不一致的故障表现。若没有明确筛选需求，先使用少量可解释的上游，记录查询路径后再增加复杂度。

监听、缓存与 IPv6 边界

示例监听在回环地址的 1053 端口，系统不会仅因该端口存在就自动使用它。系统 DNS 设置通常不能直接填写自定义端口，因此需要 TUN 的 DNS 接管、系统解析服务转发，或支持指定端口的测试工具。用 dig 可以直接验证监听端点，但命令结果只代表这次明确发给内核的查询，不代表所有应用都已接入。

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

dns.ipv6 控制内核 DNS 对 AAAA 查询的处理，顶层 ipv6 则涉及内核的 IPv6 支持，两者不是同一个层次。关闭其中一个字段，也不等于操作系统或浏览器完全停止使用 IPv6。若出现只有部分应用绕过预期路径，应检查系统 IPv6 路由、应用安全 DNS、代理接入方式和已有连接，而不是只在 DNS 配置中反复切换一个值。

调整解析策略后，旧缓存可能让测试仍显示修改前的结果。内核缓存、系统缓存与浏览器缓存应分别考虑，必要时关闭原连接并重新查询。看到 Fake-IP 地址时，不能据此判断真实服务器地区；它只是内核分配的映射地址。排查解析污染、接管范围与加密 DNS 路径时，可继续参考DNS 泄漏检测与修复，按检测、修改、复测的顺序逐层确认。

网络接管 / tun

TUN 模式与 Fake-IP 的协作

TUN 通过虚拟网络接口接收系统路由交付的 IP 流量，适合不遵循系统 HTTP 代理的应用。Fake-IP 则是 DNS 的一种工作方式，为域名返回用于映射的地址。两者经常一起配置，但解决的问题不同：TUN 决定流量怎样进入内核，Fake-IP 帮助内核保留域名与连接之间的关联。开启 TUN 不等于自动修复所有 DNS 路径，使用 Fake-IP 也不要求所有场景都必须开启 TUN。

先确认权限与系统路由

桌面客户端可能通过服务模式或提权操作建立虚拟接口与路由。移动端常通过系统 VPN 接口接入，界面也可能把它称为 VPN 模式，不能直接照抄桌面网络接口设置。Linux 的运行权限、路由管理和解析服务同样取决于部署方式。首次启用时，先确认客户端报告接管成功，再检查路由与 DNS，不要把开关显示为开启当成网络栈已经正常工作。

下面的片段用于说明自动路由与 DNS 劫持的关系，需要合并前一章的 DNS 配置。stack 可以根据系统与内核支持情况选择，mixed 不是对所有机器都更快的保证。若已有其他 VPN、容器网络或企业隧道，自动路由可能产生竞争，应先在可恢复的本机环境逐项测试。

config.yaml · TUN 与 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-filter:
    - '*.lan'
    - '*.local'

DNS 劫持不是所有解析协议的总开关

dns-hijack 中的 any:53 针对进入接管路径的普通 DNS 流量。应用通过 HTTPS 或其他加密协议访问解析服务时，流量不会因为内容是 DNS 就自动变成端口 53 查询。浏览器安全 DNS 和应用自带解析仍需要单独识别。若目标是统一解析路径，应优先让应用使用系统解析，再确认系统查询确实进入内核。

auto-detect-interface 帮助选择实际出站网卡，但多网卡、热点共享、网络切换和已有隧道可能使自动判断不符合需求。典型症状是启用 TUN 后所有连接都超时，而关闭立即恢复。此时先确认真实默认出口和路由是否回环，再检查内核连接日志；继续换节点通常无法修复出口选错的问题。远程维护服务器时尤其要保留独立恢复路径。

部分系统支持通过 strict-route 加强路由约束，但它也可能影响局域网访问或与其他网络组件冲突。这个字段不适合在尚未定位问题时盲目开启。应先建立最小可用配置，记录直连、代理和本地网络的行为，再按明确需求增加限制。不同平台的防火墙与路由实现有差别，同一片段不代表同一效果。

Fake-IP 例外与本地服务

部分设备发现、局域网服务或要求真实地址的应用不适合 Fake-IP 映射，可通过 fake-ip-filter 设置例外。示例使用通常需要本地解析的域名后缀，但具体例外应以实际应用为依据。加入例外意味着该域名按相应模式返回真实解析结果，不代表它的业务流量必然直连；后续规则仍可能把真实地址连接送入代理。

切换 Fake-IP 模式或映射范围后，应用可能仍持有旧地址。旧映射与新内核运行状态不一致时，会出现 DNS 看似成功但连接失败的情况。先关闭相关应用连接，刷新对应层的 DNS 缓存，再重新请求。不要把整个保留地址范围当成远端服务地址添加到常规代理规则中；这里的地址用于本地映射，实际目标由内核关联信息恢复。

排错顺序建议固定为：先检查虚拟接口与权限，再检查普通 DNS 是否被接管，随后查看连接是否进入内核，最后验证规则和策略组。只有 UDP 应用异常时，应继续确认节点协议、服务端和网络路径是否支持所需 UDP，而不是仅切换 TUN 栈。若局域网共享代理才是目标，通常还需要单独理解监听地址、防火墙与接入范围，参见mixed-port 与 allow-lan 设置；开启 TUN 本身并不会自动给其他设备配置代理。

域名关联 / sniffer

域名嗅探的用途与边界

域名嗅探用于在连接只呈现目标 IP、缺少可靠域名关联时，从部分协议的握手或请求信息中尝试取得域名，再辅助规则判断。它与 DNS 不同：DNS 负责名称解析，嗅探观察已经进入内核的连接。它也不是解密代理，不会因为开启就能读取所有 HTTPS 正文。先确认流量已经到达内核，才能讨论嗅探是否有效；未被接管的连接不在它的处理范围内。

先使用明确的协议与端口范围

mihomo 可以配置 HTTP、TLS 与 QUIC 等嗅探对象。HTTP 可能提供 Host 信息，TLS 通常可从握手中的服务器名称获得线索，QUIC 也有相应处理路径。但协议演进、加密握手方式、客户端实现和流量形态都会影响结果，不能承诺每个连接都有可见域名。对于直接使用 IP 或非支持协议的应用，最终仍可能只能使用 IP 类规则与兜底策略。

初次使用建议限制在确有需要的端口，先观察规则命中是否改善，再决定是否扩大范围。端口只是一种筛选条件，并不能证明流量一定使用对应协议；把所有端口全部纳入不会自动增加可解释性。下面的示例先启用域名提取，不覆盖实际连接目标，适合把“识别到什么”与“是否改写目标”分开测试。

config.yaml · 保守的嗅探起点

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

区分识别域名与覆盖连接目标

parse-pure-ip 允许对没有域名信息的纯 IP 连接尝试嗅探；force-dns-mapping 与 DNS 映射场景有关，用于扩大相关连接的处理范围。它们都不意味着一定成功，更不意味着可以忽略 DNS 配置。override-destination 决定是否用嗅探结果覆盖连接目标，行为影响比单纯识别更大，应在理解目标服务特点后再评估。

例如，应用可能先通过自身调度选定某个服务 IP，再通过 TLS 握手携带域名。如果覆盖目标后重新按域名建立连接，实际地址选择可能变化，影响原有调度或可达性。因此，遇到“开启嗅探后部分站点异常”时，应先区分是域名规则变化还是目标覆盖变化。保留连接日志，对同一请求分别关闭覆盖和关闭嗅探，比同时重置全部配置更有诊断价值。

skip-domain 可让指定域名跳过嗅探处理。上例的 example.com 是语法演示，不是通用必要例外；部署时只保留确有需求的目标。例外范围过大可能让原本依赖嗅探的域名分流失去依据，范围过小又可能遗漏关联子域名。添加例外后需要重新建立连接，并确认实际识别到的名称与预期一致。

把嗅探放在可验证的分流链中

验证时选取一个可重复的目标，先记录不开嗅探时的目标地址、规则和策略，再启用嗅探建立新连接。若规则从 IP 类变成 DOMAIN-SUFFIX，说明域名信息参与了匹配；若完全没有变化，不应立即判断功能失效，连接可能原本已有 DNS 映射，或嗅探没有取得可用名称。对于页面加载涉及多个域名的情况，要查看具体失败连接，而不是只看首页主域名。

嗅探取得的名称也不一定与用户地址栏完全相同，重定向、内容分发、资源域名和后台服务都可能使用不同名称。若业务需要稳定地区或固定出口，应维护实际连接域名集合，而不是依赖一个主域名推断所有资源。规则命中后仍由策略组选择节点，嗅探不会修复节点不可达、账户失效或服务端限制。

生产使用应保留最小必要范围，避免把嗅探当成配置错误的补丁。优先保证系统解析、Fake-IP 映射与 TUN 接管各自正确，再用嗅探补足缺少域名的连接。当问题只出现在某类应用时，可为其保留明确的例外并写下注释；确认原因后再决定长期方案。相关基础概念可到术语表对照，若只是首次导入后不能上网，应先按教程主线验证代理接入与节点，而不是直接扩大嗅探范围。

配置生命周期 / merge

本地覆写与多订阅合并

订阅文件是外部输入，本地覆写是用户自己的配置层，实际运行配置是两者经过客户端处理后的结果。三者不能混为一谈。直接编辑下载后的订阅文件，下一次更新可能被覆盖；只编辑覆写模板，却没有应用到当前配置，也不会改变内核行为。开始修改前，应在客户端确认当前启用的配置、覆写作用范围和最终生成文件，避免对错误对象反复操作。

先定义配置层的所有权

不同客户端的覆写界面和合并机制并不统一，不存在适用于所有图形客户端的通用 override YAML 顶层字段。应使用当前客户端明确提供的覆写、合并或脚本入口，并核对它如何处理映射、列表和空值。下载页提供 Clash Plus、Clash Verge Rev、FlClash 等平台选项，但不能据此假定它们的配置编辑界面完全相同。

比较稳妥的划分是：订阅负责节点信息，本地层负责策略组、规则、DNS 和控制接口。若订阅本身已经包含整套分流，应先决定继续沿用上游结构，还是仅提取节点再由本地管理。两套结构同时生效容易造成同名组、重复 MATCH 和前后覆盖。长期维护的关键不是把文件拼得更大，而是明确每一类字段由哪个来源决定。

用 provider 隔离多个节点来源

下面的片段使用两个本地节点提供器演示结构，不含远程订阅地址。每个提供器文件都需要合法的 proxies 列表和真实可用节点；主配置通过 use 引入。先用客户端导出的有效提供器文件完成验证，再考虑 HTTP 来源，可以把来源下载故障与节点配置故障分开处理。

config.yaml · 双来源组合片段

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 来源甲
      - 来源乙
      - DIRECT
  - name: 来源甲
    type: select
    use:
      - source-a
  - name: 来源乙
    type: select
    use:
      - source-b

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

完整订阅与节点提供器文件的结构不同。含有 rules、proxy-groups 和其他顶层字段的完整配置，不能仅因下载地址可用就视为合格的节点提供器载荷。若客户端提供订阅转换或提取功能，应确认转换后的输出格式；涉及私人订阅链接时，优先使用受控的本地处理流程，不要把访问凭据交给来源不明的转换服务。

映射、列表与名称冲突的处理

YAML 映射可以按键合并，但列表没有天然统一的合并语义。客户端可能替换、前置或追加整个 rules 列表，必须查看实际生成结果。若本地例外追加在上游 MATCH 后面，它们即使出现在文件里也无法生效；若替换了全部 proxy-groups，上游规则引用的旧组名又可能失效。配置检查通过只能说明结构与引用基本可接受，不代表分流意图正确。

不要在同一个 YAML 映射中重复填写 dns 或 rules，期望解析器自动拼接。重复键可能被拒绝，也可能被后者覆盖，结果依赖解析实现。应在一个确定的键下整理完整内容，并保留缩进层级。制表符不适合 YAML 缩进，冒号后的空格、列表前的短横线和字符串引号也要保持正确；复杂域名模式和含特殊字符的值宜明确加引号。

多个来源的节点可能同名。若直接合并为平面列表，容易出现引用歧义或被客户端重命名。使用分开的来源组能帮助辨认，但仍需检查有效配置里的节点标识和显示名称。不要把“能在界面看到两个来源”当成它们已经完全隔离；健康检查、缓存文件和持久化选中状态也需要分别验证。

应用、检查与回退

修改前保存上一份可工作的配置，并单独记录本地覆写。可在具备 mihomo 命令行的环境使用下面的语法检查；命令需要实际存在的配置文件与可解析的引用资源。图形客户端托管内核时，优先使用客户端的检查与应用入口，不要在同一端口再启动第二个内核。

mihomo -t -f ./config.yaml

按 DNS、策略组、规则、TUN 的顺序一次只调整一类内容，应用后核对有效配置与新连接。失败时回退最近一层修改，不必删除所有订阅重装客户端。更新订阅后再次检查个人例外是否保留、来源是否刷新、规则兜底是否仍在末尾。分享配置时还应删除订阅地址、节点凭据与控制口令；排错材料通常只需字段结构和脱敏日志，不需要完整私人配置。

运行状态 / external-controller

外部控制面板与运行验证

外部控制面板通过 mihomo 的控制 API 查看状态、切换策略或执行相关管理操作。它不是新的代理协议，也不是业务流量的入口。external-controller 定义管理接口，mixed-port 定义 HTTP 与 SOCKS 混合代理监听，两者用途不同。把浏览器代理指向控制端口不会建立正确代理连接，把控制面板指向混合端口也不会取得运行状态。

从本机回环地址开始

本机使用应优先监听 127.0.0.1，避免把管理能力暴露给局域网或公网。下面的口令是明确的教学假值，实际部署必须通过本机受控配置另行设置。external-ui 指向已准备好的本地静态面板目录；只有路径存在且内容完整时，内核才能提供相应页面。没有面板文件时，API 仍可用于检查，不能把页面缺失误判为控制接口未启动。

config.yaml · 本机管理接口片段

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./dashboard

本地面板通常通过 http://127.0.0.1:9090/ui/ 访问，并在连接设置中填写控制端点与口令。具体面板的字段名称可能不同，应以它实际提供的配置项为准。图形客户端也可能自己管理控制接口并覆盖文件设置；如果手动编辑后端口不变，先看有效配置与启动日志，不要同时启动另一份内核争抢端口。

用 API 区分连接、鉴权与界面故障

下面的请求仅演示查询策略信息，认证值与上面的教学假值对应。实际排查不要把真实口令写进公开截图、共享命令或工单。请求应从运行内核的设备执行；另一台电脑的 127.0.0.1 指向另一台电脑自身，不会自动连接到代理主机。

curl --noproxy '*' \
  -H 'Authorization: Bearer your-password' \
  http://127.0.0.1:9090/proxies

连接被拒绝通常应检查监听地址、端口占用和内核是否运行；收到认证失败响应时应核对口令与请求头；API 返回正常而页面无法显示时，再检查面板文件、浏览器控制台和前端连接设置。这个顺序能把网络层、鉴权层与界面层分开，不必一开始就修改代理规则。浏览器报告跨源限制时，也应确认面板与 API 的来源关系，而不是直接允许所有网站访问控制口。

远程管理需要额外设计身份验证、传输加密和访问范围。最小方案通常是保留本机监听，再通过受控的安全通道访问，而不是把监听地址改成所有接口后开放公网端口。若确需经过反向代理，应同步评估 WebSocket、跨源策略和服务端访问控制。控制 API 能改变运行状态，风险不能按普通只读网页对待。

面板状态不等于持久化配置

面板中切换策略组主要影响运行状态，是否在重启后保留还取决于内核持久化设置与客户端管理方式。通过 API 临时修改的字段，也可能在重新应用订阅或覆写后恢复。因此，长期规则和网络设置应写回受管理的本地配置层；面板适合观察和验证，不应成为唯一的配置记录。修改后应主动重载并检查，确认预期行为能够复现。

查看连接时，把目标域名、目标地址、命中规则、策略链和错误日志关联起来。若没有任何相关连接进入内核，先排查系统代理、TUN 或应用自己的接入方式；若进入内核却命中错误规则，回到规则顺序；若规则正确但出口不符，检查策略组选项；若出口正确仍失败，再检查节点能力、DNS 结果和目标服务。这样可以避免在所有字段之间来回试错。

观察结果	优先检查	下一步验证
没有目标连接	流量接入与系统路由	确认应用实际使用的网络路径
命中规则不符	顺序、规则集与域名信息	重新建立连接并读取规则详情
策略链落到直连	组内选择与嵌套引用	固定一个已验证的候选出口
控制 API 可用但页面异常	面板文件与连接设置	检查页面请求和认证响应

完成一次可重复的配置验证

最后建立一组固定测试：一个应直连的目标、一个应代理的目标、一个局域网服务，以及实际需要的 UDP 应用。每次修改只比较这组测试的新连接，并记录有效配置与日志。确认重启、订阅刷新和网络切换之后仍能得到同样结果，才能认为调整完成。普通连通问题可转到常见问题与故障排查；需要重新核对导入流程时回到快速上手教程。保存能解释清楚的配置，比保留更多尚未验证的开关更有维护价值。